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 VAA19554; Mon, 21 May 2001 21:09:19 +0200 (MET DST) 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 VAA19550 for ; Mon, 21 May 2001 21:09:18 +0200 (MET DST) Received: from smtp9.xs4all.nl (smtp9.xs4all.nl [194.109.127.135]) by concorde.inria.fr (8.11.1/8.10.0) with ESMTP id f4LJ9Hv26324 for ; Mon, 21 May 2001 21:09:17 +0200 (MET DST) Received: from beertje.william.bogus (williamc.xs4all.nl [213.84.56.92]) by smtp9.xs4all.nl (8.9.3/8.9.3) with ESMTP id VAA02149; Mon, 21 May 2001 21:09:16 +0200 (CEST) Received: (from williamc@localhost) by beertje.william.bogus (8.11.2/8.11.2/SuSE Linux 8.11.1-0.5) id f4LJCip05780; Mon, 21 May 2001 21:12:44 +0200 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: <15113.26795.857779.14693@beertje.william.bogus> Date: Mon, 21 May 2001 21:12:43 +0200 (CEST) To: Subject: [Caml-list] Obsessed by speed In-Reply-To: References: X-Mailer: VM 6.75 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk Mattias Waldau writes: > In the FAQ, I can read an estimation on how expensive different operations > in ocamlopt are. > > I have some further questions: > 1. If I define Array.iter + a function that uses it, > will ocamlopt combine these two functions two one? > (I looked in the assembler code, but it seemed as > ocamlopt didn't combine them) That's been my experience too---definitely it would be nice to have! > 3. Would ocamlopt benefit from a peephole optimizer of > the assembler code? Or is the assembler code already > optimal? I have generally found the backend to be very good indeed at the assembler level. Sometimes it gets things handed down to it from the intermediate level (e.g. less-than-100% unboxing) which it couldn't reasonably be expected to fix. It's so much better than backends like JDK, ghc, ... it isn't funny. > 4. What is unboxed and what isn't? Integers are always unboxed anyway (they are tagged with a low 1 and the arithmetic done on them is warped to accomodate it!). Floats seem to be unboxed very well within an expression. Float loop variables in for-loops (sadly not tail-recursive expressions) stay unboxed and indeed in registers, _provided_ that they are stored in monomorphic records that are known at a high level to be float-only---so not float ref (!!!). Define e.g. type floatref = { it: float }, works much better. To a reasonable extent, whole objects are "unboxed" too, i.e. tuples and records which are simply passed to functions which immediately deconstruct them are elided and the components become available for storing in registers. I don't know to what extent this happens in other situations but it is very helpful. ------------------- To unsubscribe, mail caml-list-request@inria.fr. Archives: http://caml.inria.fr