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.4 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 mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by yquem.inria.fr (Postfix) with ESMTP id E8C06BC37 for ; Fri, 12 Jun 2009 02:23:48 +0200 (CEST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmsEAJU8MUrUnwcjbmdsb2JhbACCHpYhDQgLCRAGtjyCQYFJBQ X-IronPort-AV: E=Sophos;i="4.42,205,1243807200"; d="scan'208";a="29358723" Received: from relay.ptn-ipout01.plus.net ([212.159.7.35]) by mail3-smtp-sop.national.inria.fr with ESMTP/TLS/RC4-SHA; 12 Jun 2009 02:23:48 +0200 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArUEAHY9MUrUnw6S/2dsb2JhbACCHs0igkGBSQU Received: from ptb-relay02.plus.net ([212.159.14.146]) by relay.ptn-ipout01.plus.net with ESMTP; 12 Jun 2009 01:23:43 +0100 Received: from [87.115.156.101] (helo=[192.168.2.7]) by ptb-relay02.plus.net with esmtp (Exim) id 1MEuYZ-0006ML-4d for caml-list@yquem.inria.fr; Fri, 12 Jun 2009 01:23:43 +0100 From: Jon Harrop Organization: Flying Frog Consultancy Ltd. To: caml-list@yquem.inria.fr Subject: Re: [Caml-list] The state of ML: multi-threaded, saved state and support platforms Date: Fri, 12 Jun 2009 01:28:58 +0100 User-Agent: KMail/1.9.9 References: <4A310EE5.7070704@inf.ed.ac.uk> <20090611154910.GA27827@annexia.org> <4A317AA8.40209@inf.ed.ac.uk> In-Reply-To: <4A317AA8.40209@inf.ed.ac.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200906120128.58163.jon@ffconsultancy.com> X-Plusnet-Relay: adb9901681c16b62203df62a056c5ff4 X-Spam: no; 0.00; ocaml:01 ocaml:01 parallelism:01 parallelism:01 speedup:01 vastly:01 afaik:01 bug:01 implements:01 iirc:01 model:01 stdlib:01 sockets:01 parsers:01 stubs:01 On Thursday 11 June 2009 22:44:08 Lucas Dixon wrote: > Richard Jones wrote: > > OCaml has native threads with shared memory, _but_ OCaml threads > > nevertheless cannot run simultaneously because there's a lock > > protecting the garbage collector. The standard solution is to use > > fork-based parallelism or MPI (which will work better on new multicore > > machines which are all NUMA nowadays, and in any case is simpler to > > program). See extensive discussions on this list about garbage > > collectors with threads. > > Thanks, I just found an old post: > > http://caml.inria.fr/pub/ml-archives/caml-list/2002/11/64c14acb90cb14bedb2c >acb73338fb15.en.html > > So PolyML is the only version of ML that supports SMP? (although it > locks all threads on a major collection - it does support parallelism on > shared-memory multiprocessors - so you really can max out 4 processor > machines - but the speedup tails off only 5 times faster for 8 core > machines) Wow! Virtually none of the surviving open source standalone FPL implementations are able to leverage multicores effectively. There is an obscure Scheme implementation called Ypsilon that is also theoretically capable of leveraging multicores but it is apparently too slow to be useful as such. A 2008 Jane St. Summer Project funded Emmanuel Chailloux's team to build a parallel GC (not state-of-the-art but vastly better than anything available from OCaml today). They do occasionally make noises about it but, AFAIK, nothing has been released. > >> 3. Lastly, can you help me get a good picture of the state of support > >> for ML systems: > >> > >> OCaml: is this still supported by INRIA? what is the level of support? > > > > What level of support are you looking for? > > I was wondering who pays for the documentation to be kept up to date, > bug fixes, and implements new features. I saw that there is an OCaml > Consortium: http://caml.inria.fr/consortium/index.en.html > Is this INRIA or something else? Is this the source of funding that > supports OCaml? or is there INRIA backing also? Does anyone know how > many people are employed? I don't know about the earlier questions but, IIRC, the money from the consortium funds one half-time developer. > I'm interested in how to support functional programming environments. What > level of financial support is needed? That depends entirely upon your goals. You might be able to develop FPL implementations from an academic position but it is insecure and restricted in terms of not being able to devote a lot of time to polishing practically important features because they do not constitute research. On the other hand, you might copy Stephen Wolfram's business model with Mathematica: productize an FPL implementation with useful features, a decent stdlib and a next generation user interface. That earned him about $1bn and he can now cover his own support costs. Personally, I would opt for the latter. However, I cannot see how to do that without expending a six figure sum developing a viable first version. Hence I am not gambling my own money on that (yet). There is also the problem that going cross platform is hard, Windows opens you up to strong competition (like F#) and the non-Windows market has little money. > > OCaml users will give you > > support through the ocaml-beginners mailing list which is active and > > most questions are answered within a few hours. If you want "call > > someone on the phone and drop everything" support then you'll have to > > pay (a lot). > > Are there organisations that offer OCaml support over the phone? Or > would that be consultancy rates for academics who specialise in OCaml? There are several OCaml consultants including myself. > >> F#: Miscrosoft > > > > Are you sure about this one? > > no idea :) > I just saw that there is a MSDN F# Developer Center, and assume > Microsoft field the responsibility to fix bugs etc. Any experience with > this? Microsoft have provided me with excellent F# support since we started using it commercially over 2 years ago. > >> 4. I'm also interested in interoperability: what systems can OCaml > >> easily interoperate with? What about the other systems? > > > > This question is very unclear. OCaml offers lots of opportunities for > > interoperating, eg. RPC mechanisms, web services, direct linking, > > passing structures through data files (XML, sexprs etc), pipes, > > databases. What are you looking for? What other systems? > > Sorry, I will try to clarify: > I was taking for granted the ability to open sockets, have pipes, and > read files. Web-services, links to databases, parsers, and anything else > at that level are not what I meant. > > I meant things at the level of linking compiled code/modules. OCaml can interoperate easily via file formats and benefits from some great parsing tools. There are also some RPC libraries of mixed quality, e.g. the most popular XML library for OCaml is far from standards compliant and most OCaml libraries do not support unicode. OCaml can interoperate with C but it requires stubs to be written and compiled separately. Consequently, most of OCaml's C bindings are buggy. Interoperability with other languages like C++ is prohibitively difficult, e.g. see OCaml's (lack of) Qt bindings. Interoperating with other high-level languages either introduces problems with GCs or is very inefficient because there is no CLR. > F# website > says it has "a cross-compiling core shared with the popular OCaml > language", so I presume that modules written in one can be used in the > other. Only if they are written in the (tiny) intersection of the two language. Also, F# is diverging from OCaml as it drops legacy features in preparation for its first full product release in 2010. > This is the level of interoperability I was wondering about. Is > there similar things for libraries writtin in Haskell, or MLton, or > MLKit, or something similar for OCaml with SML/NJ? Are you asking if OCaml code can interoperate with libraries written in SML and Haskell, and vice-versa? If so, I believe it is not at all easy. I recall one person asking for advice about this and my advice was to use the loosest bindings possible (e.g. XMLRPC) because tight bindings are just too fragile in these kinds of languages. > I know the HLVM project is hoping to provide some of these features. I > was wondering what the current situation is. HLVM is a hobby project of mine and the recession is currently forcing me to devote my time to profit-making activities. If my new book "F# for technical computing" sells as well as I hope, I'll get back to HLVM development. -- Dr Jon Harrop, Flying Frog Consultancy Ltd. http://www.ffconsultancy.com/?e