Re: [Caml-list] Accelerating compilation

[Romain Bardou <romain.bardou@inria.fr>]

Le 06/09/2013 18:30, Xavier Leroy a écrit :
> On 06/09/13 15:56, Romain Bardou wrote:
> 
>> 1) Separate typing and code generation, in ocamlc and in ocamlopt
>> For instance, provide an option -typing-only which would mean "only
>> produce the .cmi but do not produce the .cmo or the .cmx". 
> 
> I strongly suspect that bytecode generation takes much less time than
> parsing and typechecking, so you wouldn't gain much compared to simply
> compiling to bytecode.

Bytecode compilation is indeed much faster, I learned that with Melt,
which compiles an OCaml file which itself generates a .tex file. I used
to compile the OCaml file with ocamlopt. I gained a lot by using ocamlc
instead. The executable takes more time to execute but it is still much
faster overall.

However, compiling to bytecode is not always an option. In my current
case, it fails at link-time because of some C stubs (I could probably
fix this). Moreover, I compile a model-checker and speed is obviously
needed in that case. Maybe I could isolate the model-checker part…

> Some obvious recommendations:
> 
> - Make sure the .opt compilers (ocamlc.opt, ocamlopt.opt) are
>   installed.  They are significantly faster than their non-.opt
>   counterparts, and some Linux distros package the .opt compilers
>   separately and don't install them by default.

Indeed, I benchmarked this out of curiosity and it does accelerate the
compilation time by a factor of about 3.

> - Put your project on a fast disk, ideally a SSD.  ocamlc can be I/O
>   bound sometimes.  The only times where I observe somewhat slow
>   compilations is when I work in an NFS partition mounted from our
>   super-reliable-but-rather-slow NAS.
> 
>> 2) Be able to disable Ocamlbuild's digest mechanism and use dates and
>> file sizes instead
>>
>> If I am not mistaken, this is one of the main reasons why Ocamlbuild is
>> slower that make.
> 
> It's one possible reason among others, e.g. that ocamlbuild runs
> ocamldep very often.  Again, some profiling would help understanding
> the bottleneck(s).  But this is a reasonable suggestion.
> 
>> 3) Parallel compilation in Ocamlbuild
>> Of course it would help but it is not easy to implement so I'm just
>> putting it there to be exhaustive.
> 
> As others said, ocamlbuild has some support for parallelism, but
> it's much less effective than "make -j".  One reason could be that
> ocamlbuild discovers dependencies as it goes, so it's doing online
> scheduling, in contrast with make's offline scheduling.  But within
> the online scheduling approach, there is certainly room for
> improvement.  Suggestions and patches welcome.

-- 
Romain Bardou