"Finally, we’ll assume single-core servers"... isn't that rather like working out mathematically that the best gait for horses is hopping, provided you assume a one legged horse?
I think I agree. Perhaps if it was titled "Thread versus Evented single core servers" it would make much more sense. Having said that, there are ways to scale out to fill the cores for event based, and in some cases (ie nothing needs to be shared, would suit event based as IO bound) works just fine. There was an interesting article which I to me looked like it was uncovering that: http://dosync.posterous.com/clojure-nodejs-and-why-messaging...
No, while this is a wonderful analogy, I don't think this is actually a problem. It's more like assuming horses weigh 1000 kg --- wrong for all but the biggest draft horses, but a nice round number to work with.
For the level of analysis in the article, there's really no difference between a 4 core machine and a processor with a 4x clock speed. His point is that the threaded model makes the most sense when each request is CPU intensive, and the event model works best when the work is light but the delays are long. All that would change for a multi-core processor is the definition of when the works starts to be CPU 'intensive'.
Moore's law is no longer in effect, it is cheaper to add more cores these days then add more speed.
Edit: My point is that, since we live in a real tangible world, where CPU power is being expanded by parallelism rather then increasing single pipeline throughput, we have to deal with that reality. To dismiss it to prove your point, seems a tad bit naive.
An evented server (at least, until they get a lot fancier and make you program with locks and such) only gets to use one of the cores, while a threaded server gets all four.
Using a single core just means that the threaded server doesn't get any advantage from being threaded, while the evented server gets everything it can use.
It is pretty easy to build a round robin load scheduler that queries for x amount of cores on a system, spawns a thread for x cores and then schedules request to the least burdened core. This reduces the amount of threads the server uses while still taking advantage of evented co-routine based processes. (this stuff is not new, Node just kicked off interest again due to its growing popularity). If evented servers catch on, I think you will eventually see this as a hybrid solution. But yes you will certainly need threads or different processes, to take advantage of multi-core systems, it just a question of whether or not you need a thread per request. There are also a lot of security implication that are getting glossed over in the talks about evented servers.