| Dave Butenhof 2006-08-25, 7:00 pm |
| qazmlp1209@rediffmail.com wrote:
> Assume the processing-1 takes 10 ms and processing-2 takes 10 ms.
> Processing-1 and processing-2 can be done independantly.
> If I have a process with only a main thread, it takes 20 ms to finish
> the processing-1 and processing-2 in sequence. Now, I want to switch it
> to a multithreaded process, where the thread-1(i.e. the main thread)
> will do the processing-1 and thread-2 will perform the processing-2.
> How much time now the process is expected to take?
> Will it be 10 ms, or slightly more than in the range of 11-19
> ms(considering the time required for context-switching between
> threads)?
>
> I understand that this depends on various factors like the number of
> CPUs etc.. But, I would like to know the typical time that we can
> expect.
It depends on far more than the number of CPUs. Principally, in fact, it
depends on YOU -- and the exact nature of your "processing", how you
code the coordination between threads, the layout of data in memory, and
so forth. Secondarily, it depends on the independent load on processors,
memory, and so forth, because your threads can use a CPU only when
nothing "more important" is using it, because other processes/threads
compete for memory, cache, and bus bandwidth... and all sorts of other
factors.
If your threads are completely independent, if they don't compete for
memory or other resources with each other or any other processes, then
you may be able to complete your entire task in 10ms plus the time
required to create the second thread -- which depends on the OS and
processor you're using. If you have two processors, then there's no
context switching involved -- unless one or both are competing for a
processor with other jobs. If I/O is involved, the mere fact that you've
created a second thread may provoke some additional synchronization
overhead within the kernel and process runtime -- for FDs, malloc, etc.
What's affected, and by how much, again depends on the specific OS and
hardware involved.
The best way to tell -- the only way to REALLY know -- is to try it. And
if it doesn't live up to your expectations (or hopes), the next step is
to find tools to analyze where your time is really going so you can try
to improve it. Or you may simply find that your sequential tasks really
can't run in parallel, and trying is only going to cost more because of
the synchronization required to make them run serially. (Or you may find
that your code is actually making completely independent tasks run
serially because they share too many resources unnecessarily; a really
common beginners' error.)
|