John Skaller wrote:
On Tue, 2005-07-05 at 17:08 +0100, Simon Marlow wrote:
Thanks, downloading it now.. will try. What exactly is a 'registered' build?
An "unregisterised" build generates plain C which is compiled with a C compiler. The term "registerised" refers to a set of optimisations which require post-processing the assembly generated by the C compiler using a Perl script (affectionately known as the Evil Mangler). In particular, registerised code does real tail-calls and uses real machine registers to store the Hsakell stack and heap pointers.
Ah! So 'register' refers to machine registers .. not some certification by some kind of authority, which is what I guessed .. ?
Sure, it's good to look at these small benchmarks to improve aspects of our compilers, but we should never claim that results on microbenchmarks are in any way an indicator of performance on programs that people actually write.
One can also argue that 'programmer performance' is important, not just machine performance.
Absolutely. In some limited testing, I found that the penalty for poor programmer performance (I think I'll adopt that phrase) is much higher for Haskell code than for C code. ghc can mitigate, but not eliminate, this problem. Of course the compiler for an imperative language has much less work to do, and the path to machine code from the high level language source code in a language such as C is more evident. When the final product of a compiler has a less obvious relationship to the input to the compiler, it is correspondingly more difficult for the programmer to discover better compiler input. I measured performance differences due to the discovery (or lack of discovery) of an optimization as high as an order of magnitude with ghc. C (I tested with gcc and with Microsoft's compiler) has a much lower penalty for poor coding. In an age of cheap hardware, one can throw money at a poorly coded C program and "fix" its performance; in fact a good argument can often be made that this is the correct decision as the total cost (of hardware plus software development and maintenance) may be lower, compared with the costs of putting more time and effort into coding. With Haskell the same tradeoff has a much different result. Program performance is unlikely to be acceptable if programmer performance is poor. You can throw hardware at a poorly written program when the program runs half as fast as it "should"; you can't compensate (at least not cost effectively) for a program that runs an order of magnitude more slowly because of poor programmer performance.
The shootout has lots of good benchmarks, for sure.
I'm not so sure ;(
Don't restrict yourself to the small programs, though.
Of course, larger more complex programs may give interesting performance results, but have one significant drawback: a lot more work is required to write them.
It's still hard to get a big picture from the results - there are too many variables. I believe many of the Haskell programs in the suite can go several times faster with the right tweaks, and using the right libraries (such as a decent PackedString library).
Maybe I'm asking the wrong question. Can you think of a computation which you believe Haskell would be the best at?
.. and while you're at it: a computation GHC does NOT handle well -- IMHO these are actually most useful to compiler writers.
If programmer performance is the most significant factor (as I believe it is), then it isn't quite accurate to say that ghc can't handle a particular computation. What ghc cannot handle well is poor code. It isn't clear that any optimizer is capable of compensating for seriously stupid coding. It's not clear to me that the compiler should even try, although you can certainly make an argument that Haskell would be more widely used if poor programmer performance were well tolerated.
------------------------------------------------------------------------
_______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users