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.6 required=5.0 tests=NO_REAL_NAME autolearn=disabled version=3.1.3 X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from discorde.inria.fr (discorde.inria.fr [192.93.2.38]) by yquem.inria.fr (Postfix) with ESMTP id E189ABC69 for ; Sat, 10 Feb 2007 16:46:42 +0100 (CET) Received: from server2.thinkcrime.de (server2.thinkcrime.de [213.133.110.149]) by discorde.inria.fr (8.13.6/8.13.6) with ESMTP id l1AFkgTs023144 for ; Sat, 10 Feb 2007 16:46:42 +0100 Received: from hod-sarge-2005-10.lan.m-e-leypold.de (dslb-088-074-033-177.pools.arcor-ip.net [88.74.33.177]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by server2.thinkcrime.de (Postfix) with ESMTP id 07E0F48805D for ; Sat, 10 Feb 2007 16:46:44 +0100 (CET) Received: by hod-sarge-2005-10.lan.m-e-leypold.de (Postfix, from userid 1003) id 9C7C7376C1; Sat, 10 Feb 2007 16:51:55 +0100 (CET) To: caml-list@yquem.inria.fr Subject: Re: [Caml-list] Multiplication of matrix in C and OCaml References: <45CAF3E2.7020807@univ-paris12.fr> <200702100224.32450.jon@ffconsultancy.com> <200702101452.02955.jon@ffconsultancy.com> From: ls-ocaml-developer-2006@m-e-leypold.de Date: Sat, 10 Feb 2007 16:51:55 +0100 In-Reply-To: <200702101452.02955.jon@ffconsultancy.com> (Jon Harrop's message of "Sat, 10 Feb 2007 14:52:02 +0000") Message-ID: User-Agent: Some cool user agent (SCUG) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Miltered: at discorde with ID 45CDE8E2.000 by Joe's j-chkmail (http://j-chkmail . ensmp . fr)! X-Spam: no; 0.00; ocaml:01 compiler:01 compiler:01 reals:01 complained:01 gcc:01 gcc:01 integers:01 flags:01 bug:01 markus:01 constants:01 wrote:01 integer:01 behaviour:01 Jon Harrop writes: > On Saturday 10 February 2007 14:41, ls-ocaml-developer-2006@m-e-leypold.de > wrote: >> Just to be sure: Would the compiler be wrong to optimize >> >> c * q > c * k >> >> to just >> >> q > k >> >> (all floats). And why? > > Consider c=0, q=3 and k=2: > > 0 * 3 > 0 * 2 --> false > 3 > 2 --> true > > It is just mathematically incorrect. Damn. I should have taken '+'. I've not been paying attention. My question should rather have been: Is the compiler allowed to make optimizations according to known mathematical laws? >> If not, why, in the case above? > > Floats are not reals, they are just an approximation that happens to be very > useful. Floats do not obey the same laws (e.g. associativity). However, > programmers may be relying upon this fact, e.g. when doing exact float > arithmetic. Apart from my obvious error above, I wonder, how much the compiler is required to keep to that expectations and when. Some examples to illustrate: Recently someone complained to the Gcc team that the compiler optimizes a + 100 < 100 to false in case a is an unsigned int. Actually the lnaguage standard allows it: If the addition flows over, anything is allowed (undefined behaviour) and if not, a+100 < 100 is just like a < 0. The expectation that the overflow must be visible in the language was not justfied in this case. I've been wondering about similar optimizations for floats, but didn't get my examples right. The transformtion done by the compiler would of course be forbidden to increase the error. >> I don't want >> letter and verse, but a general hand waving in the right direction >> would be nice, since I have the impression, that is exactly what Gcc >> 4.1. is currently doing (though for the integer case). > Ints are completely different because they are exact (as modulo integers). So > they do obey the same laws and they do not have special constants (like > infinity, neg_infinity, nan, -0. and so on as floats do). Yes, thanks. I hope I have justfied sufficiently my motiviation to ask my question, about which I should have been thinking just for some more minutes (I admit :-). Still: With a certain Gcc version and flags combination the OP saw a threefold improvement in performance. That in intself is suspicious (I don't think that this much optimization potential was left in Gcc ...) and I still would check for optimization errors in this case. Gcc is not bug free either, so one should test the correctness of the compiled program first and wether it really does the work it is supposed to do. Regards -- Markus