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

["Ulf Wiger (TN/EAB)" <ulf.wiger@ericsson.com>]

Jon Harrop skrev:
> On Friday 09 May 2008 19:17:30 Ulf Wiger wrote:
>> Jon Harrop skrev:
>>>
>>> Erlang is uniformly slow.
>> I don't see how you can say that. If you introduce the
>> restriction that there can be only one CPU, then this
>> might be true.
> 
> 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 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 can only assume that you are perfectly happy with
OCaml staying focused on scientific computation and
applications that have the same characteristics.


 > 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, 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.

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.

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.


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.

(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.

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? I know a number of companies that
consider it extremely relevant /today/ - in market
segments worth many billions of dollars.

BR,
Ulf W