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 TAA22926; Sun, 18 Aug 2002 19:57:13 +0200 (MET DST) 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 TAA22913 for ; Sun, 18 Aug 2002 19:57:12 +0200 (MET DST) Received: from tantalum.btinternet.com (tantalum.btinternet.com [194.73.73.80]) by nez-perce.inria.fr (8.11.1/8.11.1) with ESMTP id g7IHuwj18687 for ; Sun, 18 Aug 2002 19:57:02 +0200 (MET DST) Received: from host217-39-105-36.in-addr.btopenworld.com ([217.39.105.36] helo=beertje.william.bogus) by tantalum.btinternet.com with esmtp (Exim 3.22 #8) id 17gUIL-0005cV-00; Sun, 18 Aug 2002 18:56:57 +0100 Received: (from williamc@localhost) by beertje.william.bogus (8.11.6/8.11.6/SuSE Linux 0.5) id g7II0Hn01453; Sun, 18 Aug 2002 19:00:17 +0100 X-Authentication-Warning: beertje.william.bogus: williamc set sender to williamc@paneris.org using -f From: William Chesters MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15711.57520.125841.25102@beertje.william.bogus> Date: Sun, 18 Aug 2002 19:00:16 +0100 To: caml-list@inria.fr Subject: [Caml-list] O'Caml vs C++: a little benchmark In-Reply-To: <200208181716.NAA10426@hickory.cc.columbia.edu> References: <200208181716.NAA10426@hickory.cc.columbia.edu> X-Mailer: VM 6.95 under 21.4 (patch 4) "Artificial Intelligence" XEmacs Lucid Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk Oleg writes: > I'm curious as to where these huge differences for these small programs come > from. >>From a very quick look at your array example, the point is very simply that in your "abstract" fold_left idiom Array.fold_left (fun x a -> x +. float a) sum ar the compiler doesn't inline Array.fold_left, and hence not your anonymous "fun" either, because it doesn't inline anything between compilation units. You would see this clearly in the assembler output if you used ocamlopt -S. This is an example of the general truth that you can get very good performance out of ocaml, but only as long as you ensure that your inner loops are coded in a very down-to-earth style. Whether this is a problem depends on your point of view. If you think the aim of good programming is to find beautiful abstract formulations (including the inner loops) which nevertheless compile to optimal machine code, it's bad. If you think that languages and programming idioms should stay more or less isomorphic to the execution model of the CPU then you won't feel a need for it. ------------------- 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