From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by yquem.inria.fr (Postfix) with ESMTP id 3CFF5BB84 for ; Thu, 18 May 2006 01:33:44 +0200 (CEST) Received: from biscayne-one-station.mit.edu (BISCAYNE-ONE-STATION.MIT.EDU [18.7.7.80]) by concorde.inria.fr (8.13.0/8.13.0) with ESMTP id k4HNXg4Q028426 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 18 May 2006 01:33:43 +0200 Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103]) by biscayne-one-station.mit.edu (8.13.6/8.9.2) with ESMTP id k4HNXQeY002471; Wed, 17 May 2006 19:33:26 -0400 (EDT) Received: from contents-vnder-pressvre.mit.edu (CONTENTS-VNDER-PRESSVRE.MIT.EDU [18.7.16.67]) (authenticated bits=56) (User authenticated as jfc@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.6/8.12.4) with ESMTP id k4HNXOJX013567 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 17 May 2006 19:33:25 -0400 (EDT) Received: (from jfc@localhost) by contents-vnder-pressvre.mit.edu (8.12.9.20060308) id k4HNXOa0010233; Wed, 17 May 2006 19:33:24 -0400 (EDT) Message-Id: <200605172333.k4HNXOa0010233@contents-vnder-pressvre.mit.edu> To: Dan Koppel Cc: caml-list@yquem.inria.fr Subject: Re: [Caml-list] compiler bug? In-Reply-To: Your message of "Wed, 17 May 2006 16:14:26 PDT." <20060517231426.30289.qmail@web32203.mail.mud.yahoo.com> Date: Wed, 17 May 2006 19:33:24 -0400 From: John Carr X-Scanned-By: MIMEDefang 2.42 X-Miltered: at concorde with ID 446BB2D6.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam: no; 0.00; compiler:01 bug:01 stack:01 iteration:01 stack:01 buffer:01 surprising:01 bug:01 compiler:01 ocaml:01 inserting:01 -inline:01 ocamlopt:01 unix:01 gettimeofday:01 X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on yquem.inria.fr X-Spam-Level: X-Spam-Status: No, score=0.8 required=5.0 tests=SPF_SOFTFAIL autolearn=disabled version=3.0.3 On SPARC the presence of the function call in the outer loop causes the code generated for the inner loop to change so the dummy1 variable is stored on the stack instead of in a register. Each loop iteration loads dummy1, modifies it, and stores it back onto the stack. The store-load hazard, loading a value that is in the store buffer, adds a large delay. The loop runs in half the time if I comment out either the store or the load in the assembly. If the inner loop did more computation the effect would be much less. This is surprising but not strictly a bug. Xavier Leroy has posted about similar minor changes causing the compiler to box or unbox a floating point value with major changes in performance. > I would like to report what I think might be a bug in the Ocaml compiler. But first I wanted to run this by this group in case there's something I'm missing. I have some very simple code that consists of 2 nested loops. Inside the inner loop, is a simple statement. Furthermore, the inner loop is not "tight". Ie. the number of iterations within the inner loop is very large and the number of iterations of the outer loop is very small. I then manually time this. I then change the code by inserting a simple function call between the inner and outer loops. This should have virtually no effect whatsoever. However, when I time this, I get exactly twice the time. This is somewhat inexplicable. I tried tinkering with the "-inline" option for ocamlopt but this had no effect. Below is the actual code (main.ml): > > let main () = > let dummy1 = ref 0 in > let dummy2 = ref 0.0 in > for i = 1 to 4 do > for j = 1 to 1000000000 do > dummy1 := !dummy1 + 1; > dummy1 := !dummy1 - 1 > done; > dummy2 := Unix.gettimeofday () > done > > let _ = main () > > I compile as follows: ocamlopt unix.cmxa main.ml > and run: ./a.out > > Is this in fact a bug of the ocamlopt compiler? Or is there some way currently to make this effect disappear?