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.9 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 mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by yquem.inria.fr (Postfix) with ESMTP id C8666BBAF for ; Fri, 19 Dec 2008 23:28:36 +0100 (CET) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqYBAFyuS0nUnw4UkWdsb2JhbACCO5EqAQEBAQkLCgcRA6oVWJBpgwM X-IronPort-AV: E=Sophos;i="4.36,250,1228086000"; d="scan'208";a="18714996" Received: from pih-relay08.plus.net ([212.159.14.20]) by mail2-smtp-roc.national.inria.fr with ESMTP/TLS/AES256-SHA; 19 Dec 2008 23:28:36 +0100 Received: from [87.114.38.62] (helo=leper.local) by pih-relay08.plus.net with esmtp (Exim) id 1LDnpj-0005wg-G7 for caml-list@yquem.inria.fr; Fri, 19 Dec 2008 22:28:35 +0000 From: Jon Harrop Organization: Flying Frog Consultancy Ltd. To: caml-list@yquem.inria.fr Subject: Re: [Caml-list] More cores Date: Fri, 19 Dec 2008 22:31:33 +0000 User-Agent: KMail/1.9.9 References: <157727.93194.qm@web111508.mail.gq1.yahoo.com> In-Reply-To: <157727.93194.qm@web111508.mail.gq1.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200812192231.33131.jon@ffconsultancy.com> X-Plusnet-Relay: e5373a438272403ff461c00bfe47ac89 X-Spam: no; 0.00; ocaml:01 ocaml:01 mutexes:01 xavier's:01 parallelism:01 gerd:01 parallelism:01 jocaml:01 mutation:01 compiler:01 ocamlopt:01 ocaml's:01 devil:98 acb:98 15.:98 On Friday 19 December 2008 14:04:22 Dario Teixeira wrote: > Hi, > > > Is it time to start rethinking concurrency in OCaml? > > (...) > > That's a recurrent topic in this list. I'll summarise the arguments > and save us all some time: > > i) Someone raises the issue that it's time for Ocaml to go multicore. > > ii) A few voices go "yeah!" and state that with a concurrent GC, > Ocaml can take over the world. Their argument is as follows: > > 1) Ocaml gets a concurrent GC; > 2) ... > 3) Profit! Or: ii) People used to choose OCaml because it was fast but lack of support for multicores means that OCaml is no longer competitively performant for many tasks on today's computers. > iii) A voice of reason notes that the devil is in step 2) above. > If your programming paradigm for concurrency is Threads+Mutexes, > then you are exposing yourself to a world of pain in race > conditions. At this point someone usually links to Xavier's > standard speech on concurrency (which is a few years old, but > as poignant now as it was then). iii) Your "voice of reason" also said that multicore computers "have never really taken off, at least in the general public": http://caml.inria.fr/pub/ml-archives/caml-list/2002/11/64c14acb90cb14bedb2cacb73338fb15.en.html > ... > While I tend to agree with viewpoints iii) and v), I do think a healthy > discussion on the subject of multicore is in order. Though I suggest we > focus the discussion on concurrency models that will allow us to take > advantage of those multicores in a safe, sane manner: At this point, you need to distinguish between concurrency and parallelism. OCaml can already handle concurrency reasonably well, particularly when CPU usage is low. Perhaps OCaml has a future in that specific domain but it is not my remit so I am not the best person to comment on this (ask Gerd). OCaml is extremely bad at parallelism, even embarassingly parallel tasks because OCaml still has to marshall all the data in a gather operation or resort to manual memory management. However, the problems are entirely with the current implementation and not with the language at all. So a new implementation could address this problem. > a) Could Jocaml be the future of Ocaml? For concurrency perhaps but not for parallelism. > b) How do we handle the global mutability issue? Avoid mutation when it is likely to get out of control (e.g. Erlang-style concurrent applications) but keep it available because it gives huge performance improvements in many parallel applications. F# already has good solutions in both cases so we can just copy them. I spent a lot of time thinking about the future of the ML family of languages in the open source world recently. I believe I have an another way forward that some people might find interesting. I think ML has proven its worth and it is time to begin developing a completely new open source ML implementation. There are various different ways to accomplish this and the goals are quite obvious (IMHO). However, finding a route that is likely to lead to those goals that is socially acceptable (i.e. not a fork) and technically feasible (i.e. incrementally adding useful features and garnering users) was not easy. I believe the best course of action is to develop an embedded DSL for OCaml (e.g. for higher-performance numerics) and evolve it into a completely new ML implementation. I have actually already started this using the excellent LLVM project and I just obtained the first promising results yesterday: a simple benchmark where my compiler runs OCaml code 3x faster than ocamlopt does. There are a *lot* of low hanging fruit here. So I think it should be relatively easy to create a tool that is useful for a significant number of people. The most interesting aspect is that developing this project as a DLL that is entirely accessible from within OCaml makes it possible to address many of OCaml's own problems for existing OCaml programmers. If anyone has any ideas about this I'd love to hear them. -- Dr Jon Harrop, Flying Frog Consultancy Ltd. http://www.ffconsultancy.com/?e