11–20 of 50 posts
and then there was that just two days ago: https://news.ycombinator.com/item?id=22165193
Haha I think that's the point of OP's post IMO, and people were even discussing this dichotomy in that thread as well. Total gold, nothing in this world is clean or definitive.
Worth noting this is from 2003. The performance concerns of event-based servers have been greatly alleviated by both hardware and software advancements. The test setup used for this paper was a "2x2000 MHz Xeon SMP with 1 GB of RAM running Linux 2.4.20". Solid PC server iron for 2003, but basically equivalent to a $5/month server from Digital Ocean today. If you're looking to squeeze 100,000 concurrent tasks from tha…
> The performance concerns of event-based servers have been greatly alleviated by both hardware and software advancements. Threads haven't exactly stood still in that time either, especially if you include green threads, fibers, coroutines, etc. > If you're looking to squeeze 100,000 concurrent tasks from that $5 server, this paper is relevant to you. It's relevant regardless, as part of a long-running back and forth…
I guess I’m somewhat used to the asynchronous I/O model that things like Win16 and JavaScript use. You have to think a bit more about the unpredictable order that things happen in, but not about preemption race conditions and data corruption.
The only threading model I have seen that I care for is Erlang’s. The C ... Java model is a data corruption death trap.
At that, Erlang kind of straddles the gap between independent execution and communicating sequential processes.
I guess it depends. I guess I’m somewhat used to the asynchronous I/O model that things like Win16 and JavaScript use. You have to think a bit more about the unpredictable order that things happen in, but not about preemption race conditions and data corruption. The only threading model I have seen that I care for is Erlang’s. The C ... Java model is a data corruption death trap. At that, Erlang kind of straddles the…
Meh.
Earlier quoted context omitted.
> The performance concerns of event-based servers have been greatly alleviated by both hardware and software advancements. Threads haven't exactly stood still in that time either, especially if you include green threads, fibers, coroutines, etc. > If you're looking to squeeze 100,000 concurrent tasks from that $5 server, this paper is relevant to you. It's relevant regardless, as part of a long-running back and forth…
I don't think there is back and forth anymore. Actual high performance research (e.g. when the cost of a single mutex is more than the whole CPU budget for processing something, like say a packet) has been devoid of threads since they got into the mainstream, so like for almost two decades already. They are still used, because this is what hardware and OS provide to do something on each core, but not for concurrency…
If it's a web server then obviously you want more cores, and an event driven server would make a lot of sense.
Basically if you need concurrency then you want events, if you're compute bound than you don't want that overhead.
EDIT: Instead of i7 just imagine any high end (high frequency and IPC) consumer chip
Worth noting this is from 2003. The performance concerns of event-based servers have been greatly alleviated by both hardware and software advancements. The test setup used for this paper was a "2x2000 MHz Xeon SMP with 1 GB of RAM running Linux 2.4.20". Solid PC server iron for 2003, but basically equivalent to a $5/month server from Digital Ocean today. If you're looking to squeeze 100,000 concurrent tasks from tha…
It's really quite simple: threads encourage the use of implicit program state via function calls, with attendant state expansion (stack allocation), whereas evented I/O encourages explicit program state, which means the programmer can make it as small as possible.
Smaller server program state == more concurrent clients for any given amount of memory. Evented I/O wins on this score.
But it gets better too! Smaller program state == less memory, L1/2/3 cache, and TLB pressure, which means the server can take care of each client in less time than an equivalent thread-per-client server.
So evented I/O also wins in terms of performance.
Can you write high-performance thread-per-client code? Probably, but mostly by allocating small stacks and making program state explicit just as in evented I/O, so then you might as well have done that. Indeed, async/await is a mechanism for getting thread-per-client-like sequential programming with less overhead: "context switching" becomes as cheap as a function call, while thread-per-client's context switches can never be that cheap.
The only real questions are:
- async/await, or hand-coded CPS callback hell?
- for non-essential services, do you start with
thread-per-client because it's simpler?
Worth noting this is from 2003. The performance concerns of event-based servers have been greatly alleviated by both hardware and software advancements. The test setup used for this paper was a "2x2000 MHz Xeon SMP with 1 GB of RAM running Linux 2.4.20". Solid PC server iron for 2003, but basically equivalent to a $5/month server from Digital Ocean today. If you're looking to squeeze 100,000 concurrent tasks from tha…
C10K is another name for evented I/O, and it's from the 90s . By 2003 thread-per-client was already obsolete and known to be very bad. It's really quite simple: threads encourage the use of implicit program state via function calls, with attendant state expansion (stack allocation), whereas evented I/O encourages explicit program state, which means the programmer can make it as small as possible. Smaller server progr…
* J. K. Ousterhout. "Why Threads Are A Bad Idea (for mostpurposes)". (http://web.stanford.edu/~ouster/cgi-bin/papers/threads.pdf)
* V. S. Pai, P. Druschel, and W. Zwaenepoel. "Flash: An Efficientand Portable Web Server". (https://www.usenix.org/legacy/events/usenix99/full_papers/pa...)
* M. Welsh, D. E. Culler, and E. A. Brewer. "SEDA: An architecturefor well-conditioned, scalable Internet services". (http://www.sosp.org/2001/papers/welsh.pdf)
Those are some of the more influential papers in the development of event-driven designs.