RE: [Haskell-cafe] Re: Hugsvs GHC (again)was: Re: Somerandomnewbiequestions
On 19 January 2005 13:50, William Lee Irwin III wrote:
On 19 January 2005 09:45, Ben Rudiak-Gould wrote:
Okay, my ignorance of Posix is showing again. Is it currently the case, then, that every GHC thread will stop running while a disk read is in progress in any thread? Is this true on all platforms?
On Wed, Jan 19, 2005 at 01:39:05PM -0000, Simon Marlow wrote:
It's true on Unix-like systems, I believe. Even with -threaded. It might not be true on Win32.
How does forkOS fit into this picture? It's described in the documentation as allowing concurrent execution of system calls and other activity by other threads.
forkOS doesn't fix this. It forks another OS thread which can be used to make concurrent foreign calls, if they are not marked "unsafe". However, the standard I/O library, in -threaded mode, does read like this: - non-blocking, "unsafe", read() to see what's there - if read() would block, then hand off to another Haskell thread which does select() on all the outstanding IO requests. This scheme is just for efficiency. We could (and used to) just call "safe" read() for every read - that would give you the right concurrency with -threaded, but unfortunately you'd really notice the difference if you had 1000s of threads all doing IO, because each one would need its own OS thread. The current scheme is rather snappy (even snappier than non-threaded, as it happens). You can always do System.Posix.fileRead to get around it. Cheers, Simon
Why not use a thread-pool, and a "safe" call to read, provided there is an OS thread available, defaulting to "unsafe" if no thread is available... You could make the thread pool size an argument... Keean. Simon Marlow wrote:
On 19 January 2005 13:50, William Lee Irwin III wrote:
On 19 January 2005 09:45, Ben Rudiak-Gould wrote:
Okay, my ignorance of Posix is showing again. Is it currently the case, then, that every GHC thread will stop running while a disk read is in progress in any thread? Is this true on all platforms?
On Wed, Jan 19, 2005 at 01:39:05PM -0000, Simon Marlow wrote:
It's true on Unix-like systems, I believe. Even with -threaded. It might not be true on Win32.
How does forkOS fit into this picture? It's described in the documentation as allowing concurrent execution of system calls and other activity by other threads.
forkOS doesn't fix this. It forks another OS thread which can be used to make concurrent foreign calls, if they are not marked "unsafe". However, the standard I/O library, in -threaded mode, does read like this:
- non-blocking, "unsafe", read() to see what's there - if read() would block, then hand off to another Haskell thread which does select() on all the outstanding IO requests.
This scheme is just for efficiency. We could (and used to) just call "safe" read() for every read - that would give you the right concurrency with -threaded, but unfortunately you'd really notice the difference if you had 1000s of threads all doing IO, because each one would need its own OS thread. The current scheme is rather snappy (even snappier than non-threaded, as it happens).
You can always do System.Posix.fileRead to get around it.
Cheers, Simon _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
On Wed, 2005-01-19 at 15:06 +0000, Keean Schupke wrote:
Why not use a thread-pool, and a "safe" call to read, provided there is an OS thread available, defaulting to "unsafe" if no thread is available... You could make the thread pool size an argument...
If it's just a question of speed then the fastest IO system is the variety that GHC uses now: a single OS thread that multiplexes all IO requests using a select loop. The fastest network servers work this way too. Hundreds of network clients with a single OS thread using multiplexed non-blocking IO and using epoll (or an equivalent). I don't think there are many that use many threads to do async IO. Probably the only servers that use the thread pool IO style seriously are things like Oracle. If you have more than one CPU you would want more than one OS thread. The number of threads should scale with the number of CPUs not the number of Haskell threads that want to do IO. Duncan
Duncan Coutts wrote:
If it's just a question of speed then the fastest IO system is the variety that GHC uses now: a single OS thread that multiplexes all IO requests using a select loop.
But what about the continuing computation... we do not want the fastest IO system, but we want the program to comlete the fastest... So ideally we want 2 threads! One runs the Haskell code that is not waiting for IO. (IE other Haskell threads)... The other runs a select loop as you suggest! This way the number of threads is fixed (2) and execution never 'blocks' for IO. (Simon, what about this scheme?)
If you have more than one CPU you would want more than one OS thread. The number of threads should scale with the number of CPUs not the number of Haskell threads that want to do IO.
I completely agree with this, but obviously I would suggest 1 thread per CPU, (maybe 2 including a garbage collector) plus an additional thread on the CPU attached to the IO bus to do IO. Keean.
participants (3)
-
Duncan Coutts -
Keean Schupke -
Simon Marlow