Brandon Black wrote:
However, the thread model as typically used scales poorly across
multiple CPUs as compared to distinct processes, especially as one
scales up from simple SMP to the ccNUMA style we're seeing with
This is just not true.
large-core-count Opteron and Xeon -based machines
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,
On Tue, Mar 16, 2010 at 12:15 AM, James Mansion
ja...@mansionfamily.plus.com wrote:
Brandon Black wrote:
However, the thread model as typically used scales poorly across
multiple CPUs as compared to distinct processes, especially as one
scales up from simple SMP to the ccNUMA style we're
Hello,
sorry to have woken the thread troll. It sounds like a very passionate
discussion topic.
My rationale is to favor code simplicity and clarity at the cost of some
potential performance penalty. This led me to the leader/follower
pattern with worker threads handling each request
Regarding the threads vs. processes discussion I see a use case which
hasn't been discussed yet.
Consider the C10K application with many cold links and a context (i.e.
authentication, data structures, ...) associated to each connection.
With threads we can easily set up a pool of worker
On 16 Mar 2010, at 4:40 PM, Christophe Meessen wrote:
Regarding the threads vs. processes discussion I see a use case
which hasn't been discussed yet.
Consider the C10K application with many cold links and a context
(i.e. authentication, data structures, ...) associated to each
Brandon Black a écrit :
The thing we all seem to agree on is that eventloops
beat threads within one process, but the thing we disagree on is
whether it's better to have the top-level processes be processes or
threads.
I'm really not so sure about the former. The ICE system developers
On Tue, Mar 16, 2010 at 9:51 AM, Christophe Meessen
christo...@meessen.net wrote:
Brandon Black a écrit :
The thing we all seem to agree on is that eventloops
beat threads within one process, but the thing we disagree on is
whether it's better to have the top-level processes be processes or
On 16/03/10 02:23 +0100, Marc Lehmann wrote:
On Mon, Mar 15, 2010 at 11:07:53PM +, James Mansion
ja...@mansionfamily.plus.com wrote:
Yes, threads were not meant for these kinds of workloads, and their
overheads are enourmous even on systems that are very fast (such as
GNU/Linux).
That
On Tue, Mar 16, 2010 at 03:24:32PM +0100, Christophe Meessen
christo...@meessen.net wrote:
My rationale is to favor code simplicity and clarity at the cost of some
potential performance penalty. This led me to the leader/follower
pattern with worker threads handling each request
On Tue, Mar 16, 2010 at 03:40:46PM +0100, Christophe Meessen
christo...@meessen.net wrote:
With threads we can easily set up a pool of worker threads that easily
and efficiently pick up the context associated to the connection
becoming active. I don't see how an equivalent model can be
On Tue, Mar 16, 2010 at 05:32:42PM -0500, Dan White dwh...@olp.net wrote:
userspace thread switching is 10-100 times faster than kernel thread
switching on my GNU/Linux box - and processes don't need to communicate
with themselves via slow main memory (they can use cache).
Marc,
Can you
On Tue, Mar 16, 2010 at 04:51:49PM +0100, Christophe Meessen
christo...@meessen.net wrote:
The thing we all seem to agree on is that eventloops
beat threads within one process, but the thing we disagree on is
whether it's better to have the top-level processes be processes or
threads.
13 matches
Mail list logo
