From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Original-To: caml-list@sympa.inria.fr Delivered-To: caml-list@sympa.inria.fr Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by sympa.inria.fr (Postfix) with ESMTPS id 107E47EE80 for ; Tue, 19 Mar 2013 02:37:25 +0100 (CET) Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of berenger@riken.jp) identity=pra; client-ip=134.160.33.162; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="berenger@riken.jp"; x-sender="berenger@riken.jp"; x-conformance=sidf_compatible Received-SPF: Pass (mail2-smtp-roc.national.inria.fr: domain of berenger@riken.jp designates 134.160.33.162 as permitted sender) identity=mailfrom; client-ip=134.160.33.162; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="berenger@riken.jp"; x-sender="berenger@riken.jp"; x-conformance=sidf_compatible; x-record-type="v=spf1" Received-SPF: Pass (mail2-smtp-roc.national.inria.fr: domain of postmaster@postman.riken.jp designates 134.160.33.162 as permitted sender) identity=helo; client-ip=134.160.33.162; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="berenger@riken.jp"; x-sender="postmaster@postman.riken.jp"; x-conformance=sidf_compatible; x-record-type="v=spf1" X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtsAAH6/R1GGoCGimWdsb2JhbABDsyeSGYF2DgEBAQEBEwsHFCiCJAEBBAE4HRkKEQsRBAEBAQkEEggHCQMCAQIBDyQBCQgTBgIBAQ6HcAMJBgyyJYYuAwqJW4xHgRqBNgaDOgOIc4dyhBmBYIEfhF6Fa4gz X-IPAS-Result: AtsAAH6/R1GGoCGimWdsb2JhbABDsyeSGYF2DgEBAQEBEwsHFCiCJAEBBAE4HRkKEQsRBAEBAQkEEggHCQMCAQIBDyQBCQgTBgIBAQ6HcAMJBgyyJYYuAwqJW4xHgRqBNgaDOgOIc4dyhBmBYIEfhF6Fa4gz X-IronPort-AV: E=Sophos;i="4.84,868,1355094000"; d="scan'208";a="8210856" Received: from postman2.riken.jp (HELO postman.riken.jp) ([134.160.33.162]) by mail2-smtp-roc.national.inria.fr with ESMTP; 19 Mar 2013 02:37:23 +0100 Received: from postman.riken.jp (postman2.riken.jp [127.0.0.1]) by postman.riken.jp (Postfix) with SMTP id 6D0511260327 for ; Tue, 19 Mar 2013 10:37:21 +0900 (JST) Received: from [172.27.98.103] (rikad98.riken.jp [134.160.214.98]) by postman.riken.jp (Postfix) with ESMTPA id D893A1270063 for ; Tue, 19 Mar 2013 10:37:19 +0900 (JST) Message-ID: <5147C14F.1010102@riken.jp> Date: Tue, 19 Mar 2013 10:37:19 +0900 From: Francois Berenger User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: caml-list@inria.fr References: <00ba01ce200c$d23f1910$76bd4b30$@ffconsultancy.com> <010801ce201f$afd6ad80$0f840880$@ffconsultancy.com> In-Reply-To: <010801ce201f$afd6ad80$0f840880$@ffconsultancy.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PMX-Version: 5.6.0.2009776, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.3.19.13018 Subject: Re: [Caml-list] Case study in optimization: porting a compiler from OCaml to F# On 03/14/2013 04:19 AM, Jon Harrop wrote: > Julien wrote: >> Thanks for sharing this case-study with us! > > No problem. I found it in my drafts folder. :-) > >> Have you tried parallelizing the OCaml version? > > No. I didn't touch the OCaml code at all. > >> I am thinking pre-forked processes communicating with pipes? > > That would work but it would be a lot of effort compared to > Array.Parallel.map in F#. There is such a function in the Parmap library for OCaml. >> We write a lot of large-scale static-analysis in OCaml here at Facebook. > > Good to hear. :-) > >> Parallelizing them with pre-forked processes gave us very good > performances. > > I'm not sure how much message passing would be required in this case and > don't have time to investigate. > >> I would be curious to see a case-study of pre-forked OCaml vs threaded F#. > > Me too. Only problem is that fork-based parallel OCaml code takes a long > time to write in comparison. Incidentally, the F# does not make direct use > of threads. > > Cheers, > Jon. > > > From: julien verlaguet [mailto:julien.verlaguet@gmail.com] > Sent: 13 March 2013 17:14 > To: jon@ffconsultancy.com > Cc: caml-list@inria.fr > Subject: Re: [Caml-list] Case study in optimization: porting a compiler from > OCaml to F# > > Hi Jon, > > Thanks for sharing this case-study with us! > Have you tried parallelizing the OCaml version? I am thinking pre-forked > processes communicating with pipes? > We write a lot of large-scale static-analysis in OCaml here at Facebook. > Parallelizing them with pre-forked processes gave us very good performances. > I would be curious to see a case-study of pre-forked OCaml vs threaded F#. > > Julien > 2013/3/13 Jon Harrop > > There has been some discussion here about the implications of single- vs > multi-threaded garbage collectors and, in particular, their performance in > the context of the kinds of metaprogramming that OCaml has traditionally > been used for. > > I recently ported a compiler written in OCaml to the F# programming language > for a client and performance turned out to be an issue so I'd like to > present this as a case study to provide some real data. Unfortunately I > cannot disclose precise details. > > The original compiler was 15kLOC of OCaml code. The amounts of DSL code that > it consumes and C code that it produces can be considerable and compilation > can take minutes. Consequently, performance is valued by my client's > customers and, therefore, the original code had been optimized for OCaml's > performance characteristics. > > A direct translation of the OCaml code to F# proved to be over 10x slower. > This was so slow that it impeded testing my translation so I did some > optimization early. Specifically, profiling indicated that the biggest > problem was the high rate of exceptions being raised and caught. Exceptions > are around 600x slower on .NET than in OCaml so this can quickly degrade > performance. I changed all of the hot paths to use union types (usually > option types) instead of exceptions, according to F# idioms. Although this > incurs a lot of unnecessary boxing in F# the performance improvements were > substantial and the F# version became 5x slower than the OCaml. > > On a related note, thorough testing showed that my almost-blind translation > of 15kLOC of code was completely error free. I think this is a real > testament to the power of ML's static type system. The only error I have > introduced so far occurred when I was replacing the use of an exception in a > function with a union type. > > After demonstrating the correctness of the translation, my effort turned to > trying to improve performance in an attempt to compete with the original > OCaml code. I had believed that this could well prove to be prohibitively > difficult or even impossible because symbolic code is OCaml's main strength. > However, I have managed to make the F# around 8x faster than it was and, in > particular, substantially faster than the original OCaml. > > So this non-trivial symbolic code base has not had its performance suffer > from the adoption of a multicore-friendly garbage collector. > > -- > Dr Jon Harrop, Flying Frog Consultancy Ltd. > http://www.ffconsultancy.com > > > -- > Caml-list mailing list. Subscription management and archives: > https://sympa.inria.fr/sympa/arc/caml-list > Beginner's list: http://groups.yahoo.com/group/ocaml_beginners > Bug reports: http://caml.inria.fr/bin/caml-bugs > > >