Mailing list for all users of the OCaml language and system.
 help / color / mirror / Atom feed
From: Romain Bardou <romain.bardou@inria.fr>
To: Gabriel Scherer <gabriel.scherer@gmail.com>
Cc: "caml-list@inria.fr" <caml-list@inria.fr>
Subject: Re: [Caml-list] Accelerating compilation
Date: Fri, 06 Sep 2013 17:28:32 +0200	[thread overview]
Message-ID: <5229F4A0.40606@inria.fr> (raw)
In-Reply-To: <CAPFanBH17V-j5egiUCC9eWT8vh69M37ZuHOxkMdZZSoP5AVtTg@mail.gmail.com>

Le 06/09/2013 17:18, Gabriel Scherer a écrit :
> Those are all good points, but they would be just as appropriate as
> feature requests in the OCaml bugtracker (
> http://caml.inria.fr/mantis/ ).

Actually Xavier Clerc noticed me that there is already a related feature
request:
http://caml.inria.fr/mantis/view.php?id=6102

> I think it should not be too difficult to add a flag to the compiler
> to only produce .cmi files out of its source inputs, and not also a
> .cmo (or also a .cmx) as is currently done. If you (or anyone
> interested in contributing) are interested in providing a patch for
> this, I'm more than ready to review the patch to help upstream
> integration. I'd consider this "junior job" difficulty.

Thanks for your review proposal. I might actually consider doing this
the day it becomes too much of a pain. FR#6102 actually have a patch
attached which looks like a nice starting point.

> 
> Integrating this into build systems may be trickier because, as Markus
> noted, just asking for the .cmi of the main module of your project
> will recursively build .cmi from the .mli of its dependencies, without
> checking that the .ml matches them. You could add a phony rule/stamp
> .impl.cmi that is handled differently by the build system (basically
> like .cmo, except they would be empty).
> 
> Your points (2) and (3) are well noted. I've personally been thinking
> about an optional -use-timestamp option for ocamlbuild, but devoted my
> own contribution time to other things this summer.
> 
> 
> Markus Mottl wrote:
>> I'm not sure what you are referring to, OCamlBuild does already
>> support parallel builds.
> 
> While there is support for parallel compilation in ocamlbuild (...
> except on Windows, I'm afraid), I've often found out that it doesn't
> parallelize much in practice because of current implementation
> limitations -- but if you have success stories about this I'd be glad
> to hear about them. Improving on this is on the medium-term
> ocamlbuild-development TODO list.
> 
> On Fri, Sep 6, 2013 at 3:56 PM, Romain Bardou <romain.bardou@inria.fr> wrote:
>> Hello list,
>>
>> As my project grows bigger, it is becoming much less efficient to use
>> the type-checker to quickly find places in my code which must be updated
>> (e.g. pattern-matching). Here is a wishlist for improvements.
>>
>> 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". The compiler
>> would only need the .cmi of the dependencies, not their .cmo or .cmx.
>> This would make it possible to have a Makefile target, or an Ocamlbuild
>> option, to just type.
>>
>> Also, provide an option -do-not-retype which would mean "if the .cmi
>> exists, load it instead of type-checking again". This would allow the
>> build process to first type-check (using -typing-only) and then generate
>> the code without type-checking again (using -do-not-retype). Of course
>> the build system should be very careful to ensure the .cmi is
>> up-to-date. This option could also help when compiling both in bytecode
>> and in native code. This option is not necessary to just find errors
>> quickly, though.
>>
>> 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 does help to prevent useless recompilation, but
>> what good does it make to prevent a useless recompilation once in a
>> while if it is at the cost of losing a lot of time in all other cases?
>> I'm sure it is project-dependent though so it should only be an option,
>> say, -do-not-hash, or -comparison-mode dateandsize.
>>
>> 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.
>>
>> I think the most important point is the first one, as the other two
>> depend on the build system, and they have been debated already. I'm not
>> aware of any discussion about separing typing and code generation
>> though. What do you think about that?
>>
>> Cheers,
>>
>> --
>> Romain Bardou
>>
>> --
>> 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
> 


  reply	other threads:[~2013-09-06 15:28 UTC|newest]

Thread overview: 49+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-09-06 13:56 Romain Bardou
2013-09-06 14:55 ` Markus Mottl
2013-09-06 15:19   ` Romain Bardou
2013-09-06 15:27     ` Gabriel Scherer
2013-09-06 15:33       ` Alain Frisch
2013-09-06 20:51     ` Fabrice Le Fessant
2013-09-09  7:44       ` Romain Bardou
2013-09-11 13:00       ` Francois Berenger
2013-09-11 13:46         ` Wojciech Meyer
2013-09-12  1:23           ` Francois Berenger
2013-09-12 15:15             ` Jacques Le Normand
2013-09-30  8:06       ` [Caml-list] from oasis to obuild (original subject was Re: Accelerating compilation) Francois Berenger
2013-09-30  8:18         ` Török Edwin
2013-09-30  9:00         ` Fabrice Le Fessant
2013-09-30  9:13           ` Anil Madhavapeddy
2013-09-30 11:13             ` Alain Frisch
2013-09-30 11:19               ` Anil Madhavapeddy
2013-09-30 11:27                 ` Alain Frisch
2013-09-30 11:36                   ` Anil Madhavapeddy
2013-09-30  9:18           ` Francois Berenger
2013-09-30 14:11         ` Sylvain Le Gall
2013-10-01  0:57           ` Francois Berenger
2013-10-01 12:25             ` Sylvain Le Gall
2013-09-07 11:37     ` [Caml-list] Accelerating compilation Matej Kosik
2013-09-08  6:37     ` Francois Berenger
2013-09-06 15:18 ` Gabriel Scherer
2013-09-06 15:28   ` Romain Bardou [this message]
2013-09-06 16:04   ` Markus Mottl
2013-09-06 16:30 ` Xavier Leroy
2013-09-07 19:13   ` Wojciech Meyer
2013-09-07 21:42     ` Jacques-Pascal Deplaix
2013-09-08  1:59       ` Markus Mottl
2013-09-09  7:59   ` Romain Bardou
2013-09-09  8:25   ` Alain Frisch
2013-09-09  8:35     ` Francois Berenger
2013-09-09 10:13     ` Anil Madhavapeddy
2013-09-09 17:08     ` Adrien Nader
2013-09-09 17:17       ` Gabriel Kerneis
2013-09-10  2:01     ` oleg
2013-09-10 10:21       ` Gerd Stolpmann
2013-09-10 16:15       ` Adrien Nader
2013-09-10 16:46       ` Xavier Leroy
2013-09-10 16:53         ` Adrien Nader
2013-09-10 17:43           ` ygrek
2013-09-06 18:45 ` Martin Jambon
2013-09-09  8:15   ` Romain Bardou
2013-09-09  8:36     ` Francois Berenger
2013-09-09  8:41       ` Thomas Refis
2013-09-09 17:32     ` Aleksey Nogin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5229F4A0.40606@inria.fr \
    --to=romain.bardou@inria.fr \
    --cc=caml-list@inria.fr \
    --cc=gabriel.scherer@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox