Re: [Caml-list] Case study in optimization: porting a compiler from OCaml to F#

[Francois Berenger <berenger@riken.jp>]

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 <jon@ffconsultancy.com>
>
> 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
>
>
>