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 mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by yquem.inria.fr (Postfix) with ESMTP id 44E2FBBCA for ; Fri, 9 May 2008 07:14:49 +0200 (CEST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AroCADt6I0jUnw7XcGdsb2JhbACCMY9VAQwFAgQHE5kX X-IronPort-AV: E=Sophos;i="4.27,458,1204498800"; d="scan'208";a="12405049" Received: from fhw-relay07.plus.net ([212.159.14.215]) by mail3-smtp-sop.national.inria.fr with ESMTP; 09 May 2008 07:14:48 +0200 Received: from [80.229.56.224] (helo=beast.local) by fhw-relay07.plus.net with esmtp (Exim) id 1JuKwP-0006HW-LL for caml-list@yquem.inria.fr; Fri, 09 May 2008 06:14:45 +0100 From: Jon Harrop Organization: Flying Frog Consultancy Ltd. To: caml-list@yquem.inria.fr Subject: Re: [Caml-list] Re: Why OCaml sucks Date: Fri, 9 May 2008 06:09:35 +0100 User-Agent: KMail/1.9.9 References: <200805090139.54870.jon@ffconsultancy.com> <74cabd9e0805082145p120ce487h6c1194d87f3f8396@mail.gmail.com> In-Reply-To: <74cabd9e0805082145p120ce487h6c1194d87f3f8396@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200805090609.36123.jon@ffconsultancy.com> X-Plusnet-Relay: 868a29e26ae6e9ee33c36850f59c7e8f X-Spam: no; 0.00; ocaml:01 parallelism:01 scalable:01 jocaml:01 haskell:01 haskell's:01 parallelism:01 mutable:01 ocaml:01 ocaml's:01 arrays:01 inlining:01 compiler:01 uniformly:01 inlining:01 On Friday 09 May 2008 05:45:53 you wrote: > On Thu, May 8, 2008 at 5:39 PM, Jon Harrop wrote: > > 1. Lack of Parallelism: Yes, this is already a complete show stopper. > > Exploiting multicores requires a scalable concurrent GC and message > > passing (like JoCaml) is not a substitute. Unfortunately, this is now > > true of all functional languages available for Linux, which is why we > > have now migrated entirely to Windows and F#. I find it particularly > > ironic that the Haskell community keep hyping the multicore capabilities > > of pure code when the rudimentary GC in Haskell's only usable > > implementation already stopped scaling. > > Fork? For something like a raytracer, I do not see how threads would be > any more useful than fork. There are two problems with that: . You go back to manual memory management between parallel threads/processes. . Parallelism is for performance and performance requires mutable data structures. Then you almost always end up copying data unnecessarily because you cannot collect it otherwise, which increases memory consumption and massively degrades performance that, in turn, completely undermines the original point of parallelism. The cost of interthread communication is then so high in OCaml that you will rarely be able to obtain any performance improvement for the number of cores desktop machines are going to see over the next ten years, by which time OCaml will be 10-100x slower than the competition. > When was the last time you heard of a cool new windows app anyway? The last time we released a product. :-) > > . No 16Mb limit. > > What do you mean by 16mb limit? OCaml's strings and arrays are limited to 16Mb in 32-bit. > > . Inlining. > > isn't it best for the compiler to handle that? I wouldn't mind hearing > another perspective on this, but I thought that compilers were smarter > these days. Definitely not. Compilers uniformly suck at inlining. For example, agressive inlining is often beneficial in numerical code and often damaging in symbolic code. Compilers cannot tell the difference. This is very similar to "unboxed data structures are always better", which also isn't generally true. I've got more gripes to add: . Missing types, like float32 and int16. . DLLs. -- Dr Jon D Harrop, Flying Frog Consultancy Ltd. http://www.ffconsultancy.com/products/?e