On 05 July 2005 16:25, John Skaller wrote:
On Tue, 2005-07-05 at 12:39 +0100, Simon Marlow wrote:
On 05 July 2005 10:38, John Skaller wrote:
Can someone comment on the Debian package for Ubuntu Hoary providing ghc-6.2.2 with binary for amd64?
You're probably running an unregisterised build, which is going to be generating code at least a factor of 2 slower than a registerised build. You can get an up to date snapshot of 6.4.1 for Linux/x86_64 here:
http://www.haskell.org/ghc/dist/stable/dist/ghc-6.4.1.20050704-x86_64-un
known-linux.tar.bz2
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. An "unregisterised" build is usually the first step when porting GHC to a new architecture, before support for the "registerised" optimisations is added. GHC's native code generators also generate "registerised" code.
This build is registerised, but doesn't have the native code generator.
Which would generate the best code?
-fvia-C has traditionally produced slightly better code than -fasm, at least on x86. On other platforms it might be the other way around.
I hope you're not going to conclude *anything* based on the performance of ackermann and tak! :-)
Ackermann is a good test of optimisation of a recursive function, which primarily require the smallest possible stack frame. Of course it is only one function, more need to be tested.
In fact, this one test has been very good helping me get the Felix optimiser to work well -- the raw code generated without optimisation creates a heap closure for every function, including ones synthesised for conditionals and matches, etc. If I remember rightly, it took 2 hours to calculate Ack(3,6), and I needed a friend to use a big PPC to get the result in two hours for Ack(3,7).
So ... you could say the Felix optimiser has improved a bit... :)
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.
If you would like to suggest other tests I'd be quite interested. At the moment I'm using code from the Alioth Shootout, simply because I can -- saves writing things in languages I don't know (which includes Haskell unfortunately).
The shootout has lots of good benchmarks, for sure. Don't restrict yourself to the small programs, though. 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). Cheers, Simon
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.
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. -- John Skaller <skaller at users dot sourceforge dot net> Download Felix: http://felix.sf.net
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
participants (3)
-
John Skaller -
Seth Kurtzberg -
Simon Marlow