If I really *need* to parallelize a computation, I usually need to do it bigtime (100x, 1000x), and I use a compute farm. If I'm going to do the nontrivial legwork of parallelization, I'd rather do it in such a way that it can immediately scale to the compute farm when I find the multicore speedup to be underwhelming - basically coarse-grain parallelization with RPCs.
The multicore situation might be more interesting to me if/when, as predicted, we see dozens or hundreds of cores on a single chip. But it seems to me like coordinating shared-memory computations in that scenario is still a rather active research area, from both hardware and software perspectives, and whatever designs are out there at the moment for concurrent GCs etc. might well end up being irrelevant. Similarly, except for a handful of major products, scientific code doesn't have a very long shelf-life (you're just trying to pump out data for your next paper), and anything I write now will be vastly obsoleted and long forgotten in 4-5 years. So I really don't worry about this right now.
Now, if it were not only possible but really easy for me to do fine-grain parallelization, like with OpenMP, Task Parallel Library, Cilk, etc., then there'd be little reason for me not to take advantage of current multicores. But again, it's not like this would enable me to attack all these problems that I can't now. I don't doubt such problems exist, but they don't for me (or really anyone I know). So, to me, OCaml's lack of shared-memory concurrency is a shame but not a show-stopper.
-Mike Lin
PS. Apologies in advance, but I can never resist the urge to good-naturedly hoist one by his own petard,
"I'm hard pressed to find a practically-important application that
will be better off with a concurrent GC..."
-Jon Harrop, 11 months ago
http://groups.google.com/group/comp.lang.functional/browse_thread/thread/a288a989c5cd6acb/50b6ca2607173c91
On Sat, May 10, 2008 at 10:51 AM, Ulf Wiger (TN/EAB) <
ulf.wiger@ericsson.com> wrote:
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