Re: [Caml-list] Re: Why OCaml rocks

[Jon Harrop <jon@ffconsultancy.com>]

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