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.2 required=5.0 tests=AWL autolearn=disabled version=3.1.3 Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by yquem.inria.fr (Postfix) with ESMTP id CB4E4BBCA for ; Sat, 10 May 2008 23:58:30 +0200 (CEST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: As0AAIy3JUjBtPs+mmdsb2JhbACSCQEBAQEBBgcIBxGXdw X-IronPort-AV: E=Sophos;i="4.27,466,1204498800"; d="scan'208";a="12455233" Received: from mailgw4.ericsson.se ([193.180.251.62]) by mail3-smtp-sop.national.inria.fr with ESMTP; 10 May 2008 23:58:30 +0200 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id E634920068; Sat, 10 May 2008 23:58:28 +0200 (CEST) X-AuditID: c1b4fb3e-ab993bb000004ec0-b4-48261a84b854 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id C0B0D20271; Sat, 10 May 2008 23:58:28 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Sat, 10 May 2008 23:58:28 +0200 Received: from ws73032.uab.ericsson.se ([130.100.73.32]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Sat, 10 May 2008 23:58:28 +0200 Received: from [153.88.12.153] by ws73032.uab.ericsson.se (8.11.7p2+Sun/client-1.3uab4) id m4ALwRa06057; Sat, 10 May 2008 23:58:27 +0200 (MEST) Message-ID: <48261A82.9020506@ericsson.com> Date: Sat, 10 May 2008 23:58:26 +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> <200805100229.02201.jon@ffconsultancy.com> <4825B668.40903@ericsson.com> <200805101919.34030.jon@ffconsultancy.com> In-Reply-To: <200805101919.34030.jon@ffconsultancy.com> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 10 May 2008 21:58:28.0237 (UTC) FILETIME=[FA5943D0:01C8B2E8] X-Brightmail-Tracker: AAAAAA== X-Spam: no; 0.00; ocaml:01 erlang:01 ocaml:01 marshaling:01 unmarshaling:01 erlang:01 model:01 parallelism:01 jocaml:01 haskell:01 haskell's:01 haskell:01 parallelism:01 speedup:01 speedups:01 Jon Harrop skrev: > On Saturday 10 May 2008 15:51:20 Ulf Wiger wrote: >> Jon Harrop skrev: > > So we agree that Erlang is not in the same league > as OCaml for CPU-intensive tasks on <6 cores? For compute-intensive tasks that don't require coordination with other tasks, sure. > I specifically said "For CPU intensive tasks...". > I was not making a "sweeping general statement". Perhaps we simply read different things into the word "CPU-intensive". If a program is able to make full use of the CPU and is limited by available CPU capacity, I will call it CPU-intensive. In another post you compared an F# program with an OCaml program, where the OCaml program had to do marshaling and unmarshaling in order to achieve cooperation between tasks. This is of course also CPU-intensive, and if a significant amount of this is required, OCaml will lose against Erlang big time, just as it did against F#. > In the specific context of your products, yes. Few > general programs require a high degree of > concurrency though. One of the things you quickly notice when programming in a language that really encourages you to explore the concurrency patterns in your problem, is that there is much more concurrency than you'd think, even in conventional programs. It's just that we've grown so accustomed to mapping problems onto a sequential model, simply because dealing with concurrency is a nightmare in most conventional programming languages. Here's another way of looking at it: While programming so far has been very much about automating singleton tasks that would otherwise take a long time to perform manually (e.g. scientific computing), there is a huge number of problems that are normally solved by groups of people cooperating. These can be automated too, but without mirroring the concurrency patterns used by people when solving these problems manually, it gets very difficult. We'll see a great number of web-based applications where you not only need to handle hundreds or thousands of simultaneous visitors, but each session will require (real-time) interaction with other systems, as well as perhaps other sessions within the system. I think the term "massive concurrency" tends to lead to misunderstandings. The key characteristic of a concurrency- oriented language is that it's so easy and cheap to create processes and coordinate between tasks, that you don't think twice about creating just as many processes as you need in order to solve the problem neatly. If this means creating 10,000 processes, that shouldn't be an issue, just like creating 10,000 objects shouldn't be for an OO language. But to fully utilize 4 or 8 cores, you don't need thousands of processes. >> 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. I simply meant that combining different languages and execution environments makes debugging much more difficult than using just one. >> 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 massively concurrent applications has anything to do > with adding better multicore support to OCaml. I agree that this is something very different from trying to speed up scientific calculations using shared-memory parallelism. But I would encourage a look at how lightweight message passing concurrency can be used to build very complex and robust systems. Jocaml is a very interesting start. >> 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. [...] > Moreover, the paper describing Haskell's parallel GC gives > performance figures showing some applications degrading > in performance when moving from 4 to 8 cores. So I > think the Haskell community's claim that it is "good for > parallelism" is a triumph of hope over reality. I'm not into shared-memory parallelism. For me, it's much more important that the language be good at coordination between tasks - since failure in that area means death by complexity in my domain. There was a project comparing Erlang and C++ for telecoms software, which also looked at Glasgow Distributed Haskell for the same tasks. While it came to some fairly concrete conclusions re. Erlang vs C++, the work on Haskell was not exhaustive enough to be directly comparable. Still, I would view the preliminary results as very interesting. F# could also potentially be interesting (if the underlying concurrency support would improve substantially in terms of thread creation, number of threads, scheduling cost, etc., and I have reason to believe it will). The main obstacle is that we are extremely wary of vendor lock-in, both in terms of programming language and operating system. >> 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. > > Dell's eight core desktops are now only £1,080! :-) Well, a single-core NEBS-compliant rack-mountable Dell server with 128 MB RAM is over $5,000! (: (Not that we could use those either. We need Micro TCA form factor.) BR, Ulf W