RE: [Haskell-cafe]Re: Hugsvs GHC (again)was: Re: Somerandomnewbiequestions
On 20 January 2005 11:30, Keean Schupke wrote:
Simon Marlow wrote:
Yes, except that you forgot that not all foreign calls can run
concurrently with Haskell code. Only the "safe" ones can.
Okay, now I understand what is going on. Why is there extra overhead for a 'safe' call?
A safe call must - save its state on the Haskell stack - save its thread state object on a queue, so GC can find it - tidy up the stack so GC can take place - release the RTS lock - possibly start a new OS thread if the pool is empty of these, releasing the RTS lock is probably the most expensive. Also, if another OS thread gets scheduled before the call returns, we have an expensive context switch on return. In contrast, an unsafe call is just an inline C call. Cheers, Simon
But does it matter... If the select says the read will block you schedule another haskell thread, if select says the read will not block, you do the read. I don't see the problem... (Okay, I can see that if select lies, and the read takes a long time you might miss the next scheduling timeslot - but as far as I am aware select doesn't lie, and read will return immediately if select says there is data ready)... So I guess technically other Haskell threads cannot be scheduled during the read, but as read returns immediately they don't need to... It seems to me this is why calling read sequentially and with 'unsafe' is faster than calling it with 'safe' and allowing haskell-thread-scheduling to occur during the read syscall. Is that about right? Keean. Simon Marlow wrote:
A safe call must
- save its state on the Haskell stack - save its thread state object on a queue, so GC can find it - tidy up the stack so GC can take place - release the RTS lock - possibly start a new OS thread if the pool is empty
of these, releasing the RTS lock is probably the most expensive. Also, if another OS thread gets scheduled before the call returns, we have an expensive context switch on return.
In contrast, an unsafe call is just an inline C call.
Cheers, Simon
read. I don't see the problem... (Okay, I can see that if select lies, and the read takes a long time you might miss the next scheduling timeslot - but as far as I am aware select doesn't lie, and read will return immediately if select says there is data ready)...
select() _does_ lie for "ordinary files", e.g., disk files. It assumes the data is immediately readable, even if it hasn't pulled it off disk yet. If the "ordinary" file actually resides on an NFS volume, or CD, or something else slow, then you have a problem. --KW 8-)
Keith Wansbrough wrote:
read. I don't see the problem... (Okay, I can see that if select lies, and the read takes a long time you might miss the next scheduling timeslot - but as far as I am aware select doesn't lie, and read will return immediately if select says there is data ready)...
select() _does_ lie for "ordinary files", e.g., disk files. It assumes the data is immediately readable, even if it hasn't pulled it off disk yet. If the "ordinary" file actually resides on an NFS volume, or CD, or something else slow, then you have a problem.
--KW 8-)
But the kernel does read-ahead so this data should just be a buffer copy. Keean.
Keean Schupke wrote:
read. I don't see the problem... (Okay, I can see that if select lies, and the read takes a long time you might miss the next scheduling timeslot - but as far as I am aware select doesn't lie, and read will return immediately if select says there is data ready)...
select() _does_ lie for "ordinary files", e.g., disk files. It assumes the data is immediately readable, even if it hasn't pulled it off disk yet. If the "ordinary" file actually resides on an NFS volume, or CD, or something else slow, then you have a problem.
But the kernel does read-ahead so this data should just be a buffer copy.
You can't rely upon the kernel always having read the data already.
E.g. a program which performs trivial operations on large files may
well be able to consume the data faster than the kernel can obtain it.
--
Glynn Clements
participants (4)
-
Glynn Clements -
Keean Schupke -
Keith Wansbrough -
Simon Marlow