Christopher Layne wrote:
> On Sun, Nov 04, 2007 at 04:23:01PM -0800, Scott Lamb wrote:
>>> It wasn't what I expected; I was fully confident at first that the
>>> thread-pool, work-queue model would be the way to go, since it's one
>>> I've implemented in many applications in the past. But the numbers said
>>> otherwise.
>> Thanks for the case study. To rephrase (hopefully correctly), you tried
>> these two models:
>> 1) one thread polls and puts events on a queue; a bunch of other threads
>> pull from the queue. (resulted in high latency, and I'm not too
>> extra context switch before handling any events.)
> So back to this..
>> 2) a bunch of threads read and handle events independently. (your
>> current model.)
> BTW: How does this model somehow exempt itself from said context switching
> issue of the former?

Hmm, William Ahern says that at least on Linux, they only wake one
thread per event. That would explain it.

>> Did you also tried the so-called "leader/follower" model, in which the
>> thread which does the polling handles the first event and puts the rest
>> on a queue; another thread takes over polling if otherwise idle while
>> the first thread is still working. My impression this was a widely
>> favored model, though I don't know the details of where each performs best.
> Something about this just seems like smoke and mirrors to me. At the end of
> the day we still only have a finite amount of CPU cores available to us and
> any amount of playing with the order of things is not going to extract any
> magical *more* throughput out of a given box. Yes, some of these methods
> influence recv/send buffers and have a cascading effect on overall throughput,
> but efficient code and algorithms are going to make the real difference - not
> goofy thread games.
> (and this is coming from someone who *likes* comp.programming.threads)

Oh, I don't know, there is something to be said for not making a handoff
between threads if you can avoid it. You're not going to get more
throughput than n_cores times what you got with one processor, but I'd
expect avoiding context switches and cache bouncing to help you get
closer to that.
Libevent-users mailing list

Reply via email to