From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on yquem.inria.fr X-Spam-Level: X-Spam-Status: No, score=0.3 required=5.0 tests=AWL autolearn=disabled version=3.1.3 X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82]) by yquem.inria.fr (Postfix) with ESMTP id D94E7BC37 for ; Mon, 31 Aug 2009 18:06:05 +0200 (CEST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmICAE+Rm0rUnwckk2dsb2JhbACCIpkBAQEBAQcLCgkTBL0bhBoF X-IronPort-AV: E=Sophos;i="4.44,306,1249250400"; d="scan'208";a="35243458" Received: from relay.ptn-ipout02.plus.net ([212.159.7.36]) by mail1-smtp-roc.national.inria.fr with ESMTP/TLS/RC4-SHA; 31 Aug 2009 18:06:05 +0200 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4FAE+Rm0rUnw4R/2dsb2JhbACCItZchBoF Received: from pih-relay04.plus.net ([212.159.14.17]) by relay.ptn-ipout02.plus.net with ESMTP; 31 Aug 2009 17:06:04 +0100 Received: from [87.114.1.46] (helo=leper.local) by pih-relay04.plus.net with esmtp (Exim) id 1Mi9NO-0004uk-Vn for caml-list@yquem.inria.fr; Mon, 31 Aug 2009 17:05:03 +0100 From: Jon Harrop Organization: Flying Frog Consultancy Ltd. To: caml-list@yquem.inria.fr Subject: Re: [Caml-list] Optimizing Float Ref's Date: Mon, 31 Aug 2009 18:15:52 +0100 User-Agent: KMail/1.9.9 References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200908311815.52663.jon@ffconsultancy.com> X-Plusnet-Relay: c3986e643a83d4892e5227563bf2fb19 X-Spam: no; 0.00; ref's:01 ocaml:01 ocaml:01 ref's:01 unboxed:01 compiler:01 bug:01 2009:98 1.0:98 frog:98 wrote:01 caml-list:01 unsafe:01 unsafe:01 interaction:02 On Friday 28 August 2009 21:32:55 Will M Farr wrote: > Hello all, > > I'm running OCaml 3.11.1, and I noticed something strange in some > native code for matrix multiply today. I'm running OCaml 3.11.0 and I get the opposite result on both x86 and x64: $ ./will Took 31.445965s Took 39.942496s $ ./will Took 25.457591s Took 40.414526s > But, I thought that float ref's were automatically unboxed by the > compiler when they didn't escape the local context. Is this a > complier bug, is there a bad interaction with unsafe_get and > unsafe_set, or is there something else going on that I don't > understand? Any enlightenment would be appreciated. That appears to occur in this case on my machine but it can be hampered sometimes if the accumulator is returned immediately and the problem worked around by performing a redundant floating point operation (such as 1.0 *. x) on the result. -- Dr Jon Harrop, Flying Frog Consultancy Ltd. http://www.ffconsultancy.com/?e