Re: [Caml-list] Re: Why OCaml **cks

[Jon Harrop <jon@ffconsultancy.com>]

On Saturday 10 May 2008 15:51:20 Ulf Wiger wrote:
> Jon Harrop skrev:
> > On 1 CPU Erlang is currently ~5x slower in this context.
>
> I thought "this context" for this thread was a blog article
> that discussed OCaml's weaknesses in general terms.
>
> Just looking at the default weighting of the shootout
> benchmarks, the Erlang/OCaml ratio is 3.17; excluding
> the only concurrency-related benchmark, where Erlang
> is 10.6x faster than OCaml, it's 4.0.
> (Not that I consider the shootout representative to the
> products we build...)

So we agree that Erlang is not in the same league as OCaml for CPU-intensive 
tasks on <6 cores?

> > So even if we ignore the cost of message passing we know
> > Erlang cannot be competitive for <6 cores.
>
> [...]
>
> > This is why Erlang has not (and will not) penetrate the
> > market of scientists programming shared memory
> > supercomputers.
>
> The problem with your argumentation is that you make
> sweeping general statements and later, when challenged
> justify them by claiming them to be true in a very
> specific context - presumably your favourite problem.

I specifically said "For CPU intensive tasks...". I was not making a "sweeping 
general statement".

I do not believe that not-massively-concurrent applications are a niche 
either. They constitute the vast majority of programs.

> > For the same reason, Erlang is not relevant for exploiting
> > multicore: its remit is massive concurrency which is
> > a completely different problem.
>
> Perhaps we live on different planets...?
> In my world, products are never this black and white.
>
> There are constant tradeoffs, where a high degree of
> concurrency is almost always a factor,

In the specific context of your products, yes. Few general programs require a 
high degree of concurrency though.

> but also fairly 
> big chunks of sequential processing where raw performance
> is important. The problem is that we can't find one
> language that does it all. Erlang is admittedly slow on 
> things like text parsing, math, etc., but jumping out of
> the shared memory space and executing the code in something
> like C or OCaml, we pay so much for heavyweight
> communication that it's usually not worth the effort - never
> mind the fact that debugging becomes much, much harder.

Perhaps. Comparing debugging is apples and oranges though. F# inherited great 
debugging facilities from .NET but I never use them because static type 
checking catches my errors instead. I believe a parallel debugger for OCaml 
would be equally useless (if OCaml supported parallelism).

> So on total system performance, we usually do very well,
> even though it is pretty slow on some specific parts of
> the problem. And we get superior robustness and
> maintenance cost, which for our customers is far more
> important than raw performance.

I don't doubt that but I do not believe that Erlang's success with massively 
concurrent applications has anything to do with adding better multicore 
support to OCaml.

> Right now, the main language that I see as an interesting
> contender for our type of products is Haskell, because it
> combines very good performance with very good support for
> lightweight concurrency /and/ offers very high productivity.

I'm surprised. When I studied Haskell I felt that it was an academic language 
with the same implementation problems as OCaml. There are no decent 
development environments (Haskell did not even have type throwback). 
Performance and memory consumption are wildly unpredictable, even between 
compiler versions. Virtually nobody uses it outside academia (unlike OCaml, 
which has been seeing substantial penetration in industry for many years).

Moreover, the paper describing Haskell's parallel GC gives performance figures 
showing some applications degrading in performance when moving from 4 to 8 
cores. So I think the Haskell community's claim that it is "good for 
parallelism" is a triumph of hope over reality.

Haskell is also commerce unfriendly. Nobody sells Haskell DLLs for other 
Haskell programmers (same with OCaml). There is a book market but only for 
academics. Maybe "Real World Haskell" will change that but I won't hold my 
breath, not least because I cringe at the idea of a product with "real world" 
in the title.

> OCaml, sadly, cannot even be considered for anything but
> specialized tasks, since it has no credible support for
> concurrency. I don't really see why it'd have to stay 
> that way, except that interest in message-passing
> concurrency seems to have been very low so far on this
> mailing list.

If that were true you would expect to see OCaml's use being restricted to 
certain domains when, in fact, it appears to be much more broadly used than 
Erlang.

> (Actually, I'd rank Felix higher, if it could ever rise
> from obscurity, since it was designed to run safely as
> a dynamically linked component. It could work as a very
> nice complement to Erlang.)
>
> And as for exploiting multicore, we simply cannot get
> our hands on enough cores quickly enough (mainly because
> we need them in compact NEBS-compliant embedded systems).
> But we ship dual-core systems today, and got a 1.7x
> speedup without even recompiling the code. Very soon, 
> we'll move to quad-cores, and expect corresponding
> speedups again. 8-core boards are on the horizon.

Dell's eight core desktops are now only £1,080! :-)

> Just recently, we noted that an Erlang-based product may
> well surpass what's been the undisputed market leader on
> performance using an 8-core machine, since that product
> (hand-written C++) cannot use more than 1 core due to
> timing issues. And the Erlang product in question wasn't
> even designed for raw performance, but for maximum
> convenience.
>
> Perhaps this is all irrelevant to your particular
> consultancy company?

Without knowing what problem was being solved I cannot say whether or not it 
is relevant to our work. I suspect it is another massively concurrent 
application, in which case it is irrelevant for us, yes.

-- 
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/products/?e