From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from majordomo@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id QAA21536; Tue, 3 Jun 2003 16:29:31 +0200 (MET DST) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id QAA21732 for ; Tue, 3 Jun 2003 16:29:30 +0200 (MET DST) Received: from mail.speakeasy.net (mail9.speakeasy.net [216.254.0.209]) by nez-perce.inria.fr (8.11.1/8.11.1) with ESMTP id h53ETRT22903 for ; Tue, 3 Jun 2003 16:29:29 +0200 (MET DST) Received: (qmail 5522 invoked from network); 3 Jun 2003 14:29:25 -0000 Received: from unknown (HELO apprentice.genxnet.com) ([64.81.145.152]) (envelope-sender ) by mail9.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 3 Jun 2003 14:29:25 -0000 Date: Tue, 3 Jun 2003 09:31:51 -0500 From: art yerkes To: caml-list@inria.fr Subject: Re: [Caml-list] ocaml and large development projects Message-Id: <20030603093151.159e5b1f.ayerkes@on-demand-tech.com> In-Reply-To: <4.3.2.7.2.20030602171041.045da898@localhost> References: <4.3.2.7.2.20030517192812.033d9040@localhost> <4.3.2.7.2.20030602171041.045da898@localhost> X-Mailer: Sylpheed version 0.8.11 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam: no; 0.00; yerkes:01 ayerkes:01 caml-list:01 hecker:01 checker:01 ocamlopt:01 tolerance:99 camlp:01 decoupling:01 ranting:01 stupid:01 checksum:01 cmx:01 inlining:01 gerd:01 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk On Mon, 02 Jun 2003 17:31:46 -0700 Chris Hecker wrote: > > >In other words, don't worry about it. Ocaml is FAST. [...] > >So you are expecting poor performance where it > >simply doesn't exist. > > Uh, I must have missed it when you stopped by my office and came to this > conclusion from looking at actual data from my project instead of just > asserting it on a mailing list. :) Another example of > You-Don't-Need-This-itis. > > Actually, ocamlopt compile speeds are already a problem for me, and my > project is only about 20% done, LOC-wise. This is a small problem for me > now that's going to be a huge problem soon enough unless I can get it > fixed. Perhaps I have a lower process-overhead tolerance than you. I've > already had to change my project around so only the files that need it use > camlp4 (for streams) because it was too slow. I was counting on ocamlopt > working "correctly" and allowing this decoupling as well, and again, I'm > amazed it doesn't. I'm hoping that the ocaml team takes this seriously and > fixes it soon (although no one from Inria has responded to this thread, > which worries me). > > >[lots of ranting about software houses snipped] > > In spite of these generalizations about developers and organizations, it is > not hard in C++ to decouple a large project. All C++ compilers support > this "feature". It's done every day in large projects, and it mostly > works. It appears impossible with ocamlopt given the current state of the > compiler. There is a fundamental and important difference between "often > people don't do it in C++ and John thinks they're stupid" and "it is > physically impossible to do so in ocaml". > > Anyway, back to the problem: it seems like the hacked way to enable this > is to checksum the cmi and compare the new one to the old one and if they > match then don't update the new one during cmx compilation. That, coupled > with a way to disable code inlining would allow you to control decoupling > fairly well. Unless I'm missing something; I haven't looked into this yet > (we had a baby :). > > Chris Have you thought of trying to use Gerd Stolpmann's Dl package? Although that's not exactly its purpose you'll be able to use it to implement each module in a separate shared library. It's fairly trivial to adapt it to work on win32. In order to generate the loader for each part, you use: ocamldlgen original_implementation.ml implementing_library.dll > stub_impl.ml And build your bits as dlls with something like: ocamlopt -pack <*.cmx> -output-obj -o packed.obj link /dll /out:implementing_library.dll packed.obj $(LIBS) This would allow you to separate your project into as many separately compiled subparts as you want without sacrificing inlining within the parts. -- `No, you don't understand,' the Knight said, looking a little vexed. `That's what the name is called. The name really is "The Aged Aged Man."' -- Lewis Carroll ------------------- To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/ Beginner's list: http://groups.yahoo.com/group/ocaml_beginners