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 KAA11770; Thu, 28 Jun 2001 10:37:26 +0200 (MET DST) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id KAA11767 for ; Thu, 28 Jun 2001 10:37:25 +0200 (MET DST) Received: from pauillac.inria.fr (pauillac.inria.fr [128.93.11.35]) by concorde.inria.fr (8.11.1/8.10.0) with ESMTP id f5S8bOr13508; Thu, 28 Jun 2001 10:37:24 +0200 (MET DST) Received: (from xleroy@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id KAA11764; Thu, 28 Jun 2001 10:37:24 +0200 (MET DST) Date: Thu, 28 Jun 2001 10:37:24 +0200 From: Xavier Leroy To: Florian Hars Cc: caml-list@inria.fr Subject: Re: [Caml-list] Where does Ocaml spend all the time? Message-ID: <20010628103724.A11414@pauillac.inria.fr> References: <20010628101635.A25747@hars> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <20010628101635.A25747@hars>; from florian@hars.de on Thu, Jun 28, 2001 at 10:16:35AM +0200 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk > I have written an ocaml program, which is about an order of magnitude > slower than a similar C program, and now I am wondering what to do. > According to gprof, I have neiter written nor called most of the > top-scoring functions in my program: > Only the third and fourth entry seem to do anything "useful", the rest > looks like administrative overhead to me. What are these functions > doing? mark_slice and sweep_slice are the major garbage collector. oldify is the minor garbage collector. string_equal is the string comparison operator (i.e. Caml's = operator at type string->string->bool). > Are there any general hints on how to write ocaml programs for efficiency? > Like, don't use functional updates for records to reduce garbage? That might be a possibility, depending on the size of the records. However, heap allocation of short-lived data structures is quite cheap, while some forms of in-place updates can be quite expensive (in particular, storing a pointer to a young object in an old object). So, the answer is not clear-cut. At any rate, the GC-related functions account for only 25% of the running time (which is typical for symbolic processing, but a bit high for numerical processing), so the "order of magnitude" slowdown that you mention corresponds to other factors than just GC overhead. My experience is that carefully written Caml code always deliver at least 50% of the performance of equivalent, carefully written C code. It is true, however, that tuning Caml code for performance is not obvious without a good knowledge of the compiler internals. However, the "making code run fast" section of the OCaml Questions and Answers might help: http://caml.inria.fr/ocaml/QandA.html - Xavier Leroy ------------------- Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/ To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr