I'll chip in here and say that as someone who does a lot of numerical scientific computation (CRFs and M^3 networks for genome sequence analysis), it would be really hard for me to justify structuring all my computations to make them amenable to shared-memory parallelization in order to get a measly 2-8x speedup. In my field, I don't feel there are many major questions we can't attack with a single core but we could if we could only do it 4x faster. 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) <[EMAIL PROTECTED]> 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 > > > _______________________________________________ > Caml-list mailing list. Subscription management: > http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list > Archives: http://caml.inria.fr > Beginner's list: http://groups.yahoo.com/group/ocaml_beginners > Bug reports: http://caml.inria.fr/bin/caml-bugs >
_______________________________________________ Caml-list mailing list. Subscription management: http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list Archives: http://caml.inria.fr Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
