On 03 January 2006 15:13, Joel Reymont wrote:
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.
Absolutely not! Apart from the problem you have with a space leak caused by the input buffer of the logging thread overflowing, which is easily fixed by using a bounded channel, I don't know why you want priorities. Is there something else? We could easily add Erlang-style priorities (though without the overhead of counting function calls, I'd do it by counting allocations), but I'd rather not if we can avoid it. Cheers, Simon
On Tue, Jan 03, 2006 at 04:36:37PM -0000, Simon Marlow wrote:
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.
Absolutely not!
Apart from the problem you have with a space leak caused by the input buffer of the logging thread overflowing, which is easily fixed by using a bounded channel, I don't know why you want priorities. Is there something else?
We could easily add Erlang-style priorities (though without the overhead of counting function calls, I'd do it by counting allocations), but I'd rather not if we can avoid it.
You could also achieve a similar effect without hacking the RTS, for example: track the number of elements in a Chan and on writeChan invoke yield with probability based on the number of elements in Chan - the more elements the higher the probability. You could experiment with different probability distributions. This is assuming that yield will make the thread wait for the next round. Best regards Tomasz -- I am searching for programmers who are good at least in (Haskell || ML) && (math || Linux || FreeBSD) for work in Warsaw, Poland
participants (2)
-
Simon Marlow -
Tomasz Zielonka