On Friday 09 May 2008 08:58:26 you wrote: > On Fri, 2008-05-09 at 01:39 +0100, Jon Harrop wrote: > > 9. Deforestation: Brian says "Haskell has introduced a very interesting > > and (to my knowledge) unique layer of optimization, called > > deforrestation". True, of course, but useless theoretical piffle because > > we know that Haskell is slow in practice and prohibitively difficult to > > optimize to-boot. Deforesting is really easy to do by hand. > > Are you sure or is that just a troll?
My point is that actual performance on real code is what matters and not the number of optimizations that might theoretically apply. From the measurements I have seen and done, Haskell is substantially slower despite its many extra optimizations. Also, the Haskell community are very quick to cite useless superfluous academic piffle that is of no practical use. They have a lot of very fast Fibonacci number generators, for example. We investigated alternative languages to diversify into last year and Haskell was one of them. The single biggest problem with Haskell is that it is wildly unpredictable in terms of performance and memory consumption. I asked many specialists what they thought of Haskell for Scientists and they all advised me to forget the idea. The next biggest problem is that it is as commerce unfriendly as OCaml (e.g. no DLLs). At last year's CUFP, a Haskell user from industry explained how they had to drop to C/C++ whenever performance was relevant. I received dozens of Haskell implementations of our ray tracer benchmark and performance varied enormously but only one person managed to write an implementation that gets within 3x the performance of OCaml, and he had spent his life writing optimizing Haskell compilers. I asked why his code was fast and he said it is too difficult to explain why. And that is a tiny program. The Haskell mailing lists are full of people asking why their programs run so slowly. The response is generally to litter the code with strictness annotations and then resort to unsafe operations. There is virtually no usable information explaining how to optimize Haskell code. In contrast, OCaml is easy to optimize by following simple well-documented rules and can achieve excellent performance. > Supero seems to improve enormously Haskell's performances and the Shootout > already shows Haskell beating OCaml in several tests. The shootout is completely flawed by design. Just ignore it. Also, they are running legacy hardware and OCaml does much better on modern 64-bit machines. For example, they claim that Haskell is 50% faster on binary trees but running the test here, OCaml is 40% faster. They claim Haskell is 60% faster on nbody by here OCaml is 60% faster. > > 10. Limited standard library: I agree but this is only an issue because > > we are not able to fix the problem by contributing to the OCaml > > distribution. > > That's the whole idea of Community Caml / Batteries Included. Really, feel > free to contribute. I thought Community OCaml was about tacking things on externally using macros and extra libraries. > > . Pattern matching over lazy values. > > Have you looked at the Patterns project on Google ? It provides > pattern-matching over lazy values. I've used it in conjunction with my own > lazy list module [1] to port Graham Hutton's Countdown problem from > Haskell, and it works. I had not seen that. I'll check it out, thanks. > > I believe these can be fixed by creating a new open source functional > > language for Linux based upon LLVM. However, the lack of a suitable GC is > > a complete show stopper. The JVM is the only thing that comes close and > > it is unable to support tail calls without a catastrophic performance > > cost, i.e. so bad that you might as well write an interpreter. > > Why a full new language? I may understand the interest of writing a new > compiler for OCaml (or whichever other language) and gradually improving > the forked compiler, but that's a different story altogether. A concurrent GC is the only major issue. Everything else is comparatively easy. -- Dr Jon D Harrop, Flying Frog Consultancy Ltd. http://www.ffconsultancy.com/products/?e _______________________________________________ Caml-list mailing list. Subscription management: http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list Archives: http://caml.inria.fr Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
