[Haskell-cafe] Re: [Haskell] [Fwd: Re: Computer Language Shootout]

[Fawzi Mohamed]

On Feb 27, 2007, at 1:59 PM, Sven Panne wrote:

> On Tuesday 27 February 2007 13:44, Andrzej Jaworski wrote:
>> I have learned logic from much deeper sources;-)
>> My statement was:
>> Guys started in Haskell and got to conclusion that for performance  
>> reasons
>> it is better to move to C.  The guys know what they are doing.
>>
>> I hope that helps;-)
>
> Hmmm, is there any paper/blog/etc. describing exactly what the  
> performance
> problems were? If something is too slow, usually either the language
> implementor or the language user can learn something. Furthermore,  
> when
> moving from programming language X to Y and seeing performance  
> improvements,
> it is more often than not the case that the reason for this is not  
> that Y is
> faster than X, but that one has learned a lot about the problem when
> implementing in X. So in general you see an improvement even when X  
> == Y,
> i.e. dump your old Haskell code and start from scratch.

I could not find references for the other stuff, but for Algebraic  
Dynamic Programming I found this

http://bibiserv.techfak.uni-bielefeld.de/adp/adplit.html

and citing my previous message ;)

>>> they went from an embedded haskell implementation to a direct  
>>> compiler implementation.
>>>
>>> From what I understood I believe that mis-performance in that  
>>> case came from the embedded nature of the DSL
>>> 1) not having a specialized parsing step (making the usage more  
>>> difficult)
>>> 2) no abstract representation of the program that could be  
>>> optimized with special transformations relative to the DSL
>>> 3) not fully optimized kernel methods
>>>
>>> writing a real compiler for that language made sense, and also  
>>> the choice of c as language for it, but I think that it would  
>>> have been possible to write it in haskell without a big  
>>> performance hit. I haven't seen that haskell compiler  
>>> significantly worse than others except in really low level    
>>> computational code, which (with more effort than with C) can be  
>>> optimized so that it is not really so terribly worse.
>>