Re: [Haskell] [Fwd: Re: Computer Language Shootout]
The examples I pointed to seem to share strong and relatively consistent logic of a program. In case of large GA (e.g. Royal Road Problem) and IFP (e.g. ADATE) SML was exhaustively proved to predict this logic much better. In case of Algebraic Dynamic Programming C compiler seems to address specific properties of a program more adequately which leads to substantial improvements in optimization. It is important to stress that we deal in ADP with strong logic of the domain application. Handcrafting C code for regular applications does not show that kind of advantage, so it wouldn't leave Haskell in the dust. In general declarative nature has the edge over C craftsmanship (see: http://www.clip.dia.fi.upm.es/papers/carro06:stream-interpreter-TR.pdf).
Thanks for the answers Bulat and Andrzej, so it seems that I was a little to naive, I think that I have understood what Andrzej wanted to say, but I still don't buy it all. With google I could find only something on Algebraic Dynamic Programming (links to the others?), there 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. Sincerely Fawzi
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.
ADP was conceived in Haskell and the research is done by very brainy people, so I suggest to buy this stuff:-) My intention was to signal facts and hope for experts attention. I would rather not bore anybody with my own explanations. Regards, --Andrzej
On Tuesday 27 February 2007 02:13, Andrzej Jaworski wrote:
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.
ADP was conceived in Haskell and the research is done by very brainy people, so I suggest to buy this stuff:-) [...]
A classic invalid technique of proof: http://www.maths.uwa.edu.au/~berwin/humour/invalid.proofs.html#1.10Proofbyem... ;-) Cheers, S.
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;-)
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. Cheers, S.
I think that we should follow the advice of Kristen Chevalier, and redirect this discussion to haskell-cafe Fawzi 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.
Cheers, S. _______________________________________________ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
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,
To be honest I suspect that in ADP case it is exactly that, particularly as software is in fact a component of their language in which they think doing bioinformatics. Then C on multcore looks like hit against a brick wall. Nevertheless my point is still valid: when on compiler side the heap is stretched and on program side you need Ockham's Razor in action Haskell chokes. I hoped at least to stimulate interest in repeating GP experiment with latest GHC version. This could make a hot publication and save nice people from reappearance of this thread:-) (the experiment: http://www.dcs.ed.ac.uk/home/stg/sfpw/book/Garmendia-Doval/cameraready.ps) Cheers, -Andrzej
Andrzej Jaworski wrote:
Nevertheless my point is still valid: when on compiler side the heap is stretched and on program side you need Ockham's Razor in action Haskell chokes. I hoped at least to stimulate interest in repeating GP experiment with latest GHC version. This could make a hot publication and save nice people from reappearance of this thread:-)
(the experiment: http://www.dcs.ed.ac.uk/home/stg/sfpw/book/Garmendia-Doval/cameraready.ps)
It's no wonder that code like Prelude.foldl (f) (k, False, 0.0) (BoolVector.assocs bs) chokes. Here, bs is an immutable array, Also, the SML version uses Vectors, "polymorphic vectors, immutable sequences with constant-time access". I wonder how immutable these are. I suspect that changing elements does updates in place with history tracking? Regards, apfelmus
Also, the SML version uses Vectors, "polymorphic vectors, immutable sequences with constant-time access". I wonder how immutable these are. I suspect that changing elements does updates in place with history tracking?
SML vectors in the standard basis library are truly immutable, and no history tracking for updates is available. The full source code of their experiment is not contained in the paper, so it's hard to tell what they were doing (and if the speed difference would be as pronounced today).
participants (5)
-
Andrzej Jaworski -
apfelmus＠quantentunnel.de -
Fawzi Mohamed -
Florian Weimer -
Sven Panne