From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on yquem.inria.fr X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=AWL autolearn=disabled version=3.1.3 Received: from mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82]) by yquem.inria.fr (Postfix) with ESMTP id 540BFBBCA for ; Sat, 10 May 2008 20:24:35 +0200 (CEST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlUDAFqFJUjUnw6Gb2dsb2JhbACCMY9ZAQwFAgQHEwOYCA X-IronPort-AV: E=Sophos;i="4.27,466,1204498800"; d="scan'208";a="12074600" Received: from pih-relay08.plus.net ([212.159.14.134]) by mail1-smtp-roc.national.inria.fr with ESMTP; 10 May 2008 20:24:35 +0200 Received: from [80.229.56.224] (helo=beast.local) by pih-relay08.plus.net with esmtp (Exim) id 1JutkH-000500-K3; Sat, 10 May 2008 19:24:33 +0100 From: Jon Harrop Organization: Flying Frog Consultancy Ltd. To: "Ulf Wiger (TN/EAB)" Subject: Re: [Caml-list] Re: Why OCaml **cks Date: Sat, 10 May 2008 19:19:33 +0100 User-Agent: KMail/1.9.9 References: <200805090139.54870.jon@ffconsultancy.com> <200805100229.02201.jon@ffconsultancy.com> <4825B668.40903@ericsson.com> In-Reply-To: <4825B668.40903@ericsson.com> MIME-Version: 1.0 Content-Disposition: inline Cc: caml-list@yquem.inria.fr Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: quoted-printable Message-Id: <200805101919.34030.jon@ffconsultancy.com> X-Plusnet-Relay: 9e00793853620256bc6c0e433bf21361 X-Spam: no; 0.00; ocaml:01 erlang:01 ocaml's:01 erlang:01 ocaml:01 chunks:01 admittedly:01 debugger:01 parallelism:01 haskell:01 haskell:01 compiler:01 haskell's:01 parallelism:01 ocaml's:01 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-intensiv= e=20 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 "sweep= ing=20 general statement". I do not believe that not-massively-concurrent applications are a niche=20 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=20 high degree of concurrency though. > but also fairly=20 > 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=20 > 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 gre= at=20 debugging facilities from .NET but I never use them because static type=20 checking catches my errors instead. I believe a parallel debugger for OCaml= =20 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 massivel= y=20 concurrent applications has anything to do with adding better multicore=20 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 langua= ge=20 with the same implementation problems as OCaml. There are no decent=20 development environments (Haskell did not even have type throwback).=20 Performance and memory consumption are wildly unpredictable, even between=20 compiler versions. Virtually nobody uses it outside academia (unlike OCaml,= =20 which has been seeing substantial penetration in industry for many years). Moreover, the paper describing Haskell's parallel GC gives performance figu= res=20 showing some applications degrading in performance when moving from 4 to 8= =20 cores. So I think the Haskell community's claim that it is "good for=20 parallelism" is a triumph of hope over reality. Haskell is also commerce unfriendly. Nobody sells Haskell DLLs for other=20 Haskell programmers (same with OCaml). There is a book market but only for= =20 academics. Maybe "Real World Haskell" will change that but I won't hold my= =20 breath, not least because I cringe at the idea of a product with "real worl= d"=20 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=20 > 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=20 certain domains when, in fact, it appears to be much more broadly used than= =20 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,=20 > 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 =A31,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 i= t=20 is relevant to our work. I suspect it is another massively concurrent=20 application, in which case it is irrelevant for us, yes. =2D-=20 Dr Jon D Harrop, Flying Frog Consultancy Ltd. http://www.ffconsultancy.com/products/?e