From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: 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 E30A9820A1 for ; Fri, 6 Sep 2013 16:55:44 +0200 (CEST) Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of markus.mottl@gmail.com) identity=pra; client-ip=209.85.212.173; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="markus.mottl@gmail.com"; x-sender="markus.mottl@gmail.com"; x-conformance=sidf_compatible Received-SPF: Pass (mail2-smtp-roc.national.inria.fr: domain of markus.mottl@gmail.com designates 209.85.212.173 as permitted sender) identity=mailfrom; client-ip=209.85.212.173; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="markus.mottl@gmail.com"; x-sender="markus.mottl@gmail.com"; x-conformance=sidf_compatible; x-record-type="v=spf1" Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of postmaster@mail-wi0-f173.google.com) identity=helo; client-ip=209.85.212.173; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="markus.mottl@gmail.com"; x-sender="postmaster@mail-wi0-f173.google.com"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnIBAOTrKVLRVdStjWdsb2JhbABbgzxRwVSBHAgWDgEBAQEHCwsJEgYkgiQBAQQBQAEUBx0BAwELBgULDS4hAQERAQUBHAYTh28BAwkGoGiMUIMFhA4KGScNZIgzAQUMjQKCbgeEHQOWDIFpjDeDRhgphGQg X-IPAS-Result: AnIBAOTrKVLRVdStjWdsb2JhbABbgzxRwVSBHAgWDgEBAQEHCwsJEgYkgiQBAQQBQAEUBx0BAwELBgULDS4hAQERAQUBHAYTh28BAwkGoGiMUIMFhA4KGScNZIgzAQUMjQKCbgeEHQOWDIFpjDeDRhgphGQg X-IronPort-AV: E=Sophos;i="4.90,854,1371074400"; d="scan'208";a="31812608" Received: from mail-wi0-f173.google.com ([209.85.212.173]) by mail2-smtp-roc.national.inria.fr with ESMTP/TLS/RC4-SHA; 06 Sep 2013 16:55:43 +0200 Received: by mail-wi0-f173.google.com with SMTP id hq15so1002478wib.6 for ; Fri, 06 Sep 2013 07:55:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Wgxv541XB/bjQDpFSLu32mPr++98pk5P9245Dh7OaHQ=; b=n2VUboPBxgc+ckg5wCoCRnvpDIYdjajBuG2lNuCH+FjwwJOS+AMLDLa2dlOQRmGT1V JCfuD0LldhKH6bAayQW9VElvkt01vBPOwfQXLzgGg3Vm09EQIZing3aF9j5VrY798Lqu qZdqkBtvo0OYNgdKAql0DKehdEiJTdJWpCOTLQuCq8ajhAZ6uJue5nLSVita98QmTZvB TDozHYahQ0YJeSjqcYQQjhAE/1bgJvNnieZ7EA+WjXsUXBpecZmJ5Qx1FGtHcq61ynzS 1prcjCnS0J0Fjz0gAc+AvORy6hF9+11FX3AbGPkPH4oNMwO6iHXhKrMskNufbXXOyAoF 7CJg== MIME-Version: 1.0 X-Received: by 10.181.12.16 with SMTP id em16mr10664112wid.36.1378479343603; Fri, 06 Sep 2013 07:55:43 -0700 (PDT) Received: by 10.194.172.4 with HTTP; Fri, 6 Sep 2013 07:55:43 -0700 (PDT) In-Reply-To: <5229DEF9.7040706@inria.fr> References: <5229DEF9.7040706@inria.fr> Date: Fri, 6 Sep 2013 10:55:43 -0400 Message-ID: From: Markus Mottl To: Romain Bardou Cc: "caml-list@inria.fr" Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [Caml-list] Accelerating compilation On Fri, Sep 6, 2013 at 9:56 AM, 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". 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. This seems like an interesting suggestion. Code generation, especially for native code, can be quite expensive. I do use byte code compilation during development for that reason, which is somewhat faster. Note, however, that there is one problem with the approach as suggested: if you have both an .mli and an .ml file, the build system would have to know when to "type" the latter. In the suggested approach there would be no trace of this action, because the .cmi would come from the .mli file. We would need to generate a separate dummy file in that case to visibly record the fact that the .ml file unifies with the .cmi file. Or (see below) write out the typed abstract syntax tree of the .ml file, which would, of course, also have to unify with the .cmi file. > 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. The .cmi file does not contain enough information, because it only contains the signature. You need the typed AST for proper code generation, which might be quite big. I haven't looked into this, but I wouldn't be surprised if the size of that thing could be so large that you might prefer type checking again over writing to + reloading it from a file. > 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. The problem here is that not all Unix-filesystems support sub-second resolution in timestamps. So if you build a file and change a character in it within one second, the change may go unnoticed, i.e. required recompilation doesn't happen. That's why hashing provides much stronger guarantees. But I think this is not a big problem in practice so I'd support such a flag in ocamlbuild. > 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'm not sure what you are referring to, OCamlBuild does already support parallel builds. Regards, Markus -- Markus Mottl http://www.ocaml.info markus.mottl@gmail.com