From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on yquem.inria.fr X-Spam-Level: * X-Spam-Status: No, score=1.3 required=5.0 tests=SPF_FAIL autolearn=disabled version=3.1.3 X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by yquem.inria.fr (Postfix) with ESMTP id D1EB5BC37 for ; Mon, 12 Oct 2009 14:34:04 +0200 (CEST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsgBAI+/0krUTWUBkGdsb2JhbACBUZk7AQEBAQkJDAcTBLsJhC0E X-IronPort-AV: E=Sophos;i="4.44,545,1249250400"; d="scan'208";a="36154071" Received: from smtp.wp.pl (HELO mx1.wp.pl) ([212.77.101.1]) by mail3-smtp-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-SHA; 12 Oct 2009 14:34:01 +0200 Received: (wp-smtpd smtp.wp.pl 13254 invoked from network); 12 Oct 2009 14:33:55 +0200 Received: from pfpleia.if.uj.edu.pl (d0@[149.156.90.26]) (envelope-sender ) by smtp.wp.pl (WP-SMTPD) with AES256-SHA encrypted SMTP for ; 12 Oct 2009 14:33:55 +0200 Message-ID: <4AD33ED1.6070804@wp.pl> Date: Mon, 12 Oct 2009 16:36:01 +0200 From: Dawid Toton User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: caml-list@yquem.inria.fr Subject: Re: Incremental linking References: <4AC25433.1060709@uj.edu.pl> <4AC311E2.7030409@inria.fr> In-Reply-To: <4AC311E2.7030409@inria.fr> Content-Type: text/plain; charset=ISO-8859-2; format=flowed Content-Transfer-Encoding: 7bit X-WP-AV: skaner antywirusowy poczty Wirtualnej Polski S. A. X-WP-SPAM: NO 0000000 [YdMk] X-Spam: no; 0.00; ocamlopt:01 -pack:01 compilation:01 cmx:01 compilation:01 ocamlopt:01 cmx:01 link-time:01 ocaml:01 recompile:01 mitigate:98 incremental:01 incremental:01 unix:01 arbitrary:02 > > Yes. "ocamlopt -pack" actually calls "ld -r" underneath to > consolidate several compilation units in a single .cmx/.o file. > "ld -r" will resolve references between these compilation units. I tried with this switch and indeed I can link a toy program by arbitrary intermediate steps. It works OK and is good news to me. Since today I thought that I have no way to generate the startup code quickly, but I came to the following solution: ocamlopt -o prog -dstartup --cc echo A.cmx B.cx C.cmx D.cmx as -o prog.startup.o prog.startup.s This way I have all the technical pieces working. Now I have to think how to automate this. :) > > Generally speaking, I'm somewhat surprised that linking time is an > issue for Dawid. Modern Unix linkers are quite fast, and the > additional link-time work that OCaml does is small. Let us know if > you manage to narrow the problem. My interest in this comes from combination of few facts: all my calculations are done on a not very fresh machine, my code is a big tree of small modules and I normally work this way: 1. modify some module (usually at leaf position) 2. recompile everything to native code 3. run, look at the results and go to 1. I need therefore fast recompilation and fast linking (to stay focused on the work). I'm about to solve the problem of ocamlbuild spending all its time looking at unmodified modules. Then I wanted to make sure that it will be possible to mitigate the second bottleneck. This is why I'm happy to be able to do incremental linking. It's helpful that the ocamlopt itself is very fast. Dawid