On Tue, Dec 20, 2011 at 09:26:28PM +0100, Hongli Lai <hon...@phusion.nl> wrote:
> I would like to know more about this claim. It's not that I don't
> believe you, but I'm genuinely interested in this area and I hear all
> kinds of (often contradicting) information about threads vs processes.
> What is it about processes that are more efficient than threads? For
> the sake of simplicity let's limit ourselves to x86 Linux and x86_64
> Linux. I don't really care about other platforms.
Well, threads were originally invented because single cpus only had a single
set of registers, and swapping these can be costly (especially with vm
state).
With multiple cpus, this is no concern, because each cpu has it's own
set of registers, so there is no benefit in keeping register values
in-sync. In fact, having to keep state in sync is now a major problem, as
ipmi's are quite costly.
Also, sharing memory is a speed problem, as hardware doesn't share
memory in the way threads normally need it (every cpu has it's own cache
for example), and bouncing cache lines between cpus is a very common
phenomenon. The more cpus, the more costly this gets.
In addition, your cpu has a mmu, that allows programs to have different
state without extra pointer indirection. With threads, you cannot use the MMU
for this task anymore, which replaces a whole block of optimised silicon in
your cpu by a software mmu implementation, because everything that cannot be
shared requires extra indirection _somewhere_.
What threads have in favour is improved context switch performance on
single-cpu systems, a lot of library support (posix semaphores and shared
memory are not so commonly implemented, but pthreads are often available),
and a lot of hype - a lot of people think (and claim) that threads are
needed for good performance on multi-core chips. I suspect thats because
threads are the only viable mechanism for multiprocessing on windows.
There are often interesting facts coming to light when you actually
measure things, for example, the people behind dthreads (which I
think decribes itself as a deterministic deadlock-free ngptl drop-in
replacement) found that implementing pthreads via processes can improve
performance substantially, because memory is no longer force-shared.
In any case, tis is a summary, some of these points have been discussed in
the past here.
> > Even if true (I am a bit doubtful) thats a difference between message
> > passing and shared memory, not between processes and threads, Processes
> > would still be more efficient overall.
>
> I know it's not a strict difference between processes and threads, but
> in my case using processes would pretty much force me to use message
> passing.
Ok, but kepe in mind that libeio doesn't force you to do message passing
or use processes, you can still use threads.
> I know that shared memory exists, however inter-process
Yes, pthreads are hyped much more than scalable, efficient and performant
solutions, that is really sad, but doesn't make pthreads any more
efficient or scalable.
> > Whether context switching flushes the TLB depends on the architecture,
> > not so much on Linux (which presumably suppreses it if unnecessary). Note
> > that threads incur extra overheads on multiple cpu cores as well, where
> > processes are more efficient.
>
> More efficient in what way?
Well, most notably mmu state must be kept synchronised, memory must be
unshared manually and shared memory cannot be efficiently cached.
> >> Manipulating a shared data structure through message passing *always*
> >> involves a context switch, even in the uncontended case, while mutexes
> >> do not impose such overhead in the uncontended case.
> >
> > Thats not true either, where did you pick this up?
>
> See above. With all due respect, I'm actually wondering why you don't
> think what I said is true.
libeio uses message passing for all requests and certainly doesn't require
a context switch for each passed message.
if libeio used a second process (or thread) and a socket, then it still
wouldn't need a context switch.
in fact, I would be hard pressed to imagine any form of message passing
that requires a context switch. The whole point of message passing is not
requiring a context switch.
> It's true that *conceptual* message passing necessarily doesn't
> require kernel system calls or context switches, but I'm talking about
> OS-level message passing and OS-level processes.
Me too - do you have an actual example of a message-passing system that
_always_ involve context switches? :)
Even many rpc systems (corba, d-bus etc.) don't require a context switch.
--
The choice of a Deliantra, the free code+content MORPG
-----==- _GNU_ http://www.deliantra.net
----==-- _ generation
---==---(_)__ __ ____ __ Marc Lehmann
--==---/ / _ \/ // /\ \/ / schm...@schmorp.de
-=====/_/_//_/\_,_/ /_/\_\
_______________________________________________
libev mailing list
libev@lists.schmorp.de
http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev
