On Jan 3, 2006, at 2:30 PM, Simon Marlow wrote:
The default context switch interval in GHC is 0.02 seconds,
measured in CPU time by default. GHC's scheduler is stricly round-
robin, so therefore with 100 threads in the system it can be 2
seconds between a thread being descheduled and scheduled again.
I measured the time taken to unpickle those large 50k packets as
0.3 seconds on my amd64 box (program compiled *without*
optimisation), so the thread can get descheduled twice during while
unpickling a large packet, giving a >4s delay with 100 threads
running.
Is it impractical then to implement this type of app in Haskell?
Based on the nature of Haskell scheduling I would be inclined to say
yes. I'm including information on the Erlang scheduler below.
I think it's possible to emulate the workings of the Erlang scheduler
in Haskell by using delimited continuations a-la Zipper File Server/
OS. A single delimited continuation (request in Zipper FS parlance?)
would be a scheduling unit and a programmer could then tune the
"scheduler" to their hearts content.
Apart from putting a lot of burden on the programmer this becomes
quite troublesome when multiple sockets or file descriptors are
concerned. There's no easy way to plug into the select facility of
the Haskell runtime to receive notifications of input available. You
will notice the Zipper FS spending quite a few lines of code to roll
its own select facility.
The Erlang scheduler is based on reduction count where one reduction
is roughly equivalent to a function call. See http://www.erlang.org/
ml-archive/erlang-questions/200104/msg00072.html for more detail.
There's also this helpful bit of information:
--
erlang:bump_reductions(Reductions) -> void()
Types Reductions = int()
This implementation-dependent function increments the reduction
counter for the calling process. In the Beam emulator, the
reduction counter is normally incremented by one for each func-
tion and BIF call, and a context switch is forced when the
counter reaches 1000.
--
Regarding the issue of why a logger process in Erlang does not get
overwhelved, this is the reply I got from Raimo Niskanen (Erlang team
at Ericsson):
There is a small fix in the scheduler for the standard
producer/consumer problem: A process that sends to a
receiver having a large receive queue gets punished
with a large reduction (number of function calls)
count for the send operation, and will therefore
get smaller scheduling slots.
Thanks, Joel
--
http://wagerlabs.com/
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
