[gargoiler00]

> The idea that threads or processes are intrinsically slow was sheer unmitigated propaganda, and probably not only failed to contain a grain of truth, but are actively false.

Threads / processes:

  * Run some code from A
  * Save state, context switch
  * Run some code from B
  * Save state, context switch

  * Deal with locking, synchronisation, etc

vs

  * Run some code.

There is absolutely no instances where [num threads] > [num cores] is as efficient as not using more threads than cores.

[jerf]

Funny, then, you'd think the benchmarks would show that, if it's so obvious, instead of showing the opposite.

The problem is that once you understand what lies behind your glib "run some code", you understand what the problem is. I mean, for one thing, the idea that in a busy server switching to a different event handler which has neither its code nor its data in any processor cache is not itself a "context switch" is a use of the term not necessarily connected to any reality, even if one might pass Computer Science 302 with that answer. Alas, we can not convince our CPUs or RAM to go any faster by arguing at them that they aren't making a "context switch".

But, you know, it's an open benchmark, and the benchmarks themselves aren't all that complicated. Do feel free to submit your event-based handlers that blow the socks off the competition. Bearing in mind that is the standard you've set here. Merely competitive means you've still lost. Nor do I see any "but benchmarks don't mean anything" wiggle room in your statements, because what you're talking about is exactly what is being benchmarked.