[Haskell-cafe] ANNOUNCE: Sun Microsystems and Haskell.org joint
project on OpenSPARC
Ben.Lippmeier at anu.edu.au
Fri Jul 25 00:19:13 EDT 2008
On 25/07/2008, at 12:42 PM, Duncan Coutts wrote:
> Of course then it means we need to have enough work to do. Indeed we
> need quite a bit just to break even because each core is relatively
> stripped down without all the out-of-order execution etc.
I don't think that will hurt too much. The code that GHC emits is very
regular and the basic blocks tend to be small. A good proportion of it
is just for copying data between the stack and the heap. On the
upside, it's all very clean and amenable to some simple peephole
optimization / compile time reordering.
I remember someone telling me that one of the outcomes of the Itanium
project was that they didn't get the (low level) compile-time
optimizations to perform as well as they had hoped. The reasoning was
that a highly speculative/out-of-order processor with all the
trimmings had a lot more dynamic information about the state of the
program, and could make decisions on the fly which were better than
what you could ever get statically at compile time. -- does anyone
have a reference for this?
Anyway, this problem is moot with GHC code. There's barely any
instruction level parallelism to exploit anyway, but adding an extra
hardware thread is just a `par` away.
To quote a talk from that paper earlier: "GHC programs turn an Athlon
into a 486 with a high clock speed!"
More information about the Haskell-Cafe