Scheduling overheads (was haskell httpd)

[Jan-Willem Maessen]

Peter Simons <simons at cryp.to> replies:
> Paul Graunke writes:
> 
>  > [...] event driven servers (which are supposedly oh so
>  > much faster.)
> 
> At least in my experience, multiplexing servers _are_
> significantly faster than those relying on the OS (or
> whatever library) to do the scheduling. They also tend to be
> much more efficient in terms of memory consumption, thus
> allowing for more simultaneous connections than a fork()ing
> or pthread_xxx()ing server would. (Not a big surprise, if
> you think about it.)

For a somewhat-contrary opinion, see the recent SOSP paper "Capriccio:
Scalable Threads for Internet Services" by Rob von Behren, Jeremy
Condit, Feng Zhou, George Necula, and Eric Brewer:
    http://www.cs.berkeley.edu/~jcondit/capriccio-sosp-2003.pdf

In a nutshell: they wrote a user-level threads package that wrapped
the usual library functions and did them all using asynchronous I/O.
All the scheduling takes places at user level.  The whole system is
currently uniprocessor.

The threads package they describe is virtually identical to the way
threading is implemented in GHC.  The overheads?  Virtually none
compared to writing the program explicitly in an event-driven style
(sometimes they're even faster).  That said, they were quite a bit
more careful about tracking resource demands of various sorts and
using them to make clever scheduling decisions.  GHC is a bit more
naive, but there's nothing ruling out a more clever implementation,
and GHC programs written using forkIO would certainly benefit from
such optimizations.

-Jan-Willem Maessen
Resource-aware scheduling freak
jmaessen at alum.mit.edu