English version
Accueil     À propos     Téléchargement     Ressources     Contactez-nous    

Ce site est rarement mis à jour. Pour les informations les plus récentes, rendez-vous sur le nouveau site OCaml à l'adresse ocaml.org.

Browse thread
Re: Why OCaml sucks
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: 2008-05-12 (18:12)
From: Jon Harrop <jon@f...>
Subject: Re: [Caml-list] Re: Why OCaml rocks
On Monday 12 May 2008 14:22:24 Richard Jones wrote:
> This is just barely faster than Jon's OCaml version using message
> passing (12% faster on my test machine[0]).

On this machine, the Ancient-based implementation is 30-40% faster than the 
message passing OCaml.

The important question is: how many operations must we be doing for 
parallelism to be worthwhile? The answer is of fundamental importance.

Plotting the graphs, we find that parallelism is faster in F# for n>32 and in 
OCaml for n>150 for this O(n^3) task. Therefore, OCaml is two orders of 
magnitude slower than F# at spawning parallel computations. Moreover, to get 
this performance from OCaml you had to sacrifice safety.

> Which just seems to show that the overhead of message passing _isn't_ the
> problem here[1].

Well, OCaml currently offers several different approaches to parallelism that 
are all extremely inefficient. The parallel GC implementation being funded by 
Jane St. will completely remove this performance problem with OCaml in this 
context but it will not scale as well as Microsoft's concurrent GC and will 
suffer from the same stalling.

This is why I believe that project is of incredible importance.

> Perhaps it's the bounds checking in the assignment back to the matrix?

Actually it was the polymorphic array maps and copies rather than the bounds 
checking within them. So I hand rolled optimized float array array copying 
code into both of the new parallel OCaml implementations to get the best 
possible performance out of OCaml for the above comparison.

> Anyhow, in real life situations we'd all be using a super-optimized
> hand-coded-in-assembly matrix multiplication library (LAPACK?), so
> this is all very academic.

If you ignore the impedance mismatch between the data structures, the 
performance overhead of invoking external functions and all applications that 
require different functionality that has not already been written, optimized 
and packaged by someone else, yes.

The fact is, this is hugely important to the vast majority of the software 
industry and companies are investing massive amounts of time and effort into 
parallelizing their software. Developers are flocking to .NET because it 
makes parallelism easy and OCaml has the potential to provide these benefits 
if the parallel GC project flies.

Dr Jon D Harrop, Flying Frog Consultancy Ltd.