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
using
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
exist.
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.
James
Learn to argue with your brain, not your balls.
Ha!
_______________________________________________
libev mailing list
[email protected]
http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev
