Performance on amd64

[Seth Kurtzberg]

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 at haskell.org
>http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>  
>