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.1 required=5.0 tests=AWL autolearn=disabled version=3.1.3 X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr 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 9EF8BBBCA for ; Mon, 12 May 2008 15:31:06 +0200 (CEST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqsDADfjJ0hDWxLCbmdsb2JhbACBU5A7Npd6 X-IronPort-AV: E=Sophos;i="4.27,473,1204498800"; d="scan'208";a="12130603" Received: from ip67-91-18-194.z18-91-67.customer.algx.net (HELO server1.bertec.net) ([67.91.18.194]) by mail1-smtp-roc.national.inria.fr with ESMTP; 12 May 2008 15:31:06 +0200 Received: from kuba.bertec.net (kuba.bertec.net [192.168.2.16]) by server1.bertec.net (Postfix) with ESMTP id 63D87CDFB6 for ; Mon, 12 May 2008 09:31:05 -0400 (EDT) From: Kuba Ober To: caml-list@yquem.inria.fr Subject: Re: [Caml-list] Re: Why OCaml sucks Date: Mon, 12 May 2008 09:31:04 -0400 User-Agent: KMail/1.9.9 References: <200805090139.54870.jon@ffconsultancy.com> <200805091846.32238.jon@ffconsultancy.com> <4824953A.4000207@ericsson.com> In-Reply-To: <4824953A.4000207@ericsson.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200805120931.04704.ober.14@osu.edu> X-Spam: no; 0.00; ocaml:01 parallelism:01 mutable:01 erlang:01 mutable:01 achieves:01 erlang:01 uniformly:01 inherently:01 scalable:01 parallelism:01 scalable:01 ocaml:01 cheers:01 -fold:98 On Friday 09 May 2008, Ulf Wiger (TN/EAB) wrote: > Jon Harrop skrev: > > On Friday 09 May 2008 14:00:52 you wrote: > >> Jon Harrop skrev: > >>> . Parallelism is for performance and performance > >>> > >> > requires mutable data structures. > >> > >> I disagree. SMP Erlang has no mutable data structures, > >> but achieves very good scalability anyway. > > > > Scalability != performance. For CPU intensive tasks, > > > > 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. Some applications are very difficult to > scale to multiple CPUs, but others are inherently > scalable. For some problems, mutable data structures > make all the difference, and in others, they just make > a mess of things. > > If you say "parallelism is for performance", you imply > that the program is scalable, and that it actually makes > a difference to add more CPUs. In this case, mutable > the presence of data structures will make scaling more > difficult. Most problems involved in utilizing multicore > boil down to the widespread use of mutable data structures. > > If the problem isn't scalable, then other tricks are needed > to achieve performance, and mutable data structures may > be indispensable. I think people forget Jon's background/interests: numerical methods. Think of working with large amounts of numbers, where the cost of some operations is on par with copying a few words of memory, and good non-algorithmic (!) optimizations can increase performance 10-fold (see Mersenne project, for example). Moreover, a lot of numerical methods are applied in real-time applications, and there a 50% loss in performance simply means that the game becomes unplayable, or that the phone connection sounds like excrement dropping into the hole. For web applications (generally speaking), a 50% loss of performance means you pay 2x more money for servers and power. Up to a certain point, this is small compared to the costs of maintaining the software. Where numerical methods are widely applied, a 50% performance loss may mean you're out of the market. I'm no F# fanboy; I use Ocaml exclusively for most of my numerical work (some FEM, all numerical methods courses I take), but as a language for packaged application development (bread-and-butter stuff that sells in boxes or via downloads) it's simply not there yet for me. F# would be more like it, if I weren't wary of .net platform lock-in. Give Mono a few more years and it won't be an issue anymore... For server-side use Ocaml is probably fine, but so is a number of languages that for me pack way more punch (Lisp, for one). In any event, these days I see little reason to develop web-facing stuff on non-google platforms (at least if you're a startup), so I'm in Python lock-in in that area anyway now. Cheers, Kuba