MR K P SCHUPKE
Well I have to say the dataflow style of lazy programming made me think Haskell would be ideal for multi-processor use (and now HyperThreading is common most PCs have more than one processor from the code's point of view)...
I was disappointed to find GHC only uses one thread, and therefore will only use one CPU.
I'm sure somebody, somewhere, is working on speculative execution of Haskell code. Now that Sun is building Niagara with IIRC 8 cores on a chip, Intel is rumoured to put up to 16 cores on the post-Montecito Tukwila, Sony/IBM's Cell is said to be some kind of parallel design, and every self-respecting chip vendor is putting at least two cores on a chip and/or adding multithreaded cores. Even if there's a lot of rumor-mongering going on, it seems fairly clear that you can only go on for so long, adding more cache to your old designs, and the bottleneck then becomes the inherent parallelism in your code. One would expect a lazy and pure language to be excellent for parallelization, since the programmer is generally removed from the actual flow of execution anyway. At some point (for some n), being able to spawn n threads will gain you more than a factor c constant overhead, and Haskell programs, with a run-time system that can evaluate expressions in paralllel, will outperform single threaded C code. (But it probably isn't that simple, or we would have it already :-) -kzm -- If I haven't seen further, it is by standing in the footprints of giants