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.3 required=5.0 tests=ADVANCE_FEE_1,AWL autolearn=disabled version=3.1.3 Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by yquem.inria.fr (Postfix) with ESMTP id 61ED9BBCA for ; Sat, 10 May 2008 16:51:23 +0200 (CEST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: As0AAABTJUjBtPs+mmdsb2JhbACSCgEBAQEBBgcIBxGYNw X-IronPort-AV: E=Sophos;i="4.27,465,1204498800"; d="scan'208";a="10579284" Received: from mailgw4.ericsson.se ([193.180.251.62]) by mail2-smtp-roc.national.inria.fr with ESMTP; 10 May 2008 16:51:23 +0200 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 54B5220434; Sat, 10 May 2008 16:51:22 +0200 (CEST) X-AuditID: c1b4fb3e-ae999bb000004ec0-5f-4825b66a3934 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 2FF67201C4; Sat, 10 May 2008 16:51:22 +0200 (CEST) Received: from esealmw128.eemea.ericsson.se ([153.88.254.176]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Sat, 10 May 2008 16:51:21 +0200 Received: from ws73032.uab.ericsson.se ([130.100.73.32]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Sat, 10 May 2008 16:51:21 +0200 Received: from [153.88.12.153] by ws73032.uab.ericsson.se (8.11.7p2+Sun/client-1.3uab4) id m4AEpLa06024; Sat, 10 May 2008 16:51:21 +0200 (MEST) Message-ID: <4825B668.40903@ericsson.com> Date: Sat, 10 May 2008 16:51:20 +0200 From: "Ulf Wiger (TN/EAB)" User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Jon Harrop Cc: caml-list@yquem.inria.fr Subject: Re: [Caml-list] Re: Why OCaml **cks References: <200805090139.54870.jon@ffconsultancy.com> <200805091846.32238.jon@ffconsultancy.com> <4824953A.4000207@ericsson.com> <200805100229.02201.jon@ffconsultancy.com> In-Reply-To: <200805100229.02201.jon@ffconsultancy.com> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 10 May 2008 14:51:21.0646 (UTC) FILETIME=[4FB5CCE0:01C8B2AD] X-Brightmail-Tracker: AAAAAA== X-Spam: no; 0.00; ocaml:01 erlang:01 uniformly:01 erlang:01 ocaml's:01 ocaml:01 chunks:01 admittedly:01 haskell:01 speedup:01 speedups:01 hand-written:01 blog:98 penetrate:98 wrote:01 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