Optimal multithread model

James Mansion james at mansionfamily.plus.com
Tue Mar 16 07:55:07 CET 2010

Marc Lehmann wrote:
> The precise problem they were designed to solve is slow context switching
> times due to reloading of cpu registers.
You have to reload the registers when you context switch between threads 
*or* processes. Its
the VM and security context switch that hurt.

> With threads, often you are when you want performance - the
> synchronisation between cpus when using threads can be very costly, and is
> usually unnecessary (why not use the extra hardware you got?).
And the synchronisation when sharing data between proceses is cheaper in 
what way?

> Threads force memory/cpu state synchronisation among multiple cores (when
> they actually run on multiple cores), which often requires cache flushes, tlb
> flushes, synchronous IPIs and so on.
And so does sharing state between processes.  The amount of sharing is 
the key thing. The heap
is shared and that can be good, or bad, depending on what you need and 
how you use it.
> Processes were designed for parallel processing - they don't force these
> kinds of synchronisation between cpus, and naturally scale even over host
> boundaries, making them both more efficient and more scalable in general.
Only when the state that is shared is minimal.

> That of course is a limitation in those APIs - you don't argue that
> threads are more efficient in general because some APIs force you to use
> them? That wouldn't make sense.
Oh great, I'll just forget about my database then. And libmemcached. And 
doing any crypto
or signature stuff.  No monte-carlo or XSLT for me.  I'd better not read 
from disk, and
as for NFS ...

Yes, I am arguing that threads are *more practical* and something that 
is theoretically
very efficient (hey - shared nothing!) but so impractical for real-world 
problems as
to be useless is 'less efficient' in reality.

> You keep repeating it, but it doesn't make it true :-) Processes spread
> their load evenly over cpus, threads cannot by design.
I must have completely imagined it then. Those auto-parallelising 
compilers are just
smoke and mirrors too.
> Keep in mind that if a malloc or a free often result in costly IPIs,
> copying between CPUs and so on.
You think accessing disparate bits of memory that are not actively 
contended slows
everything?  Have you looked at the thread-aware allocators?  Or perhaps 
splintered (and possibly thread local) object pools?

> Also keep in mind that threads share all memory by default, even when it
> makes little sense, performance-wise.
Yes, I know.
> Of course threads can be convinient (although many people would disagree,
> as thread programming is very difficult), and inter-process communication
> doesn't have so nice standardised APIs, but again, we are talking about
> efficiency here, not about how to slow down everything so it is convinient
> (the C language is a bad choice for this...).
Efficiency that is too hard to apply to real problems might as well not 

> Counterexamples disprove the general case how?
Overgeneralisation is easy to disprove.

> The fact that you a) don't even know the very basics of threads b) didn't
> bother to read my e-mail and c) think you need to behave like an asshole
I think I do, but others can judge, and they can see how you behave to 
people who disagree with
you in the archives.


> Learn to argue with your brain, not your balls.

More information about the libev mailing list