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.7 required=5.0 tests=AWL,SPF_SOFTFAIL autolearn=disabled version=3.1.3 X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from mail4-relais-sop.national.inria.fr (mail4-relais-sop.national.inria.fr [192.134.164.105]) by yquem.inria.fr (Postfix) with ESMTP id 50987BC69 for ; Wed, 26 Sep 2007 10:53:32 +0200 (CEST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAAAS6+UbLENaMnmdsb2JhbACOLQEBAQEHBAYn X-IronPort-AV: E=Sophos;i="4.20,300,1186351200"; d="scan'208";a="16799934" Received: from ipmail01.adl2.internode.on.net ([203.16.214.140]) by mail4-smtp-sop.national.inria.fr with ESMTP; 26 Sep 2007 10:53:31 +0200 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAAAS6+UZ5LHvc/2dsb2JhbAAM X-IronPort-AV: E=Sophos;i="4.20,300,1186324200"; d="scan'208";a="197915863" Received: from ppp121-44-123-220.lns10.syd6.internode.on.net (HELO [192.168.1.201]) ([121.44.123.220]) by ipmail01.adl2.internode.on.net with ESMTP; 26 Sep 2007 18:23:29 +0930 Subject: Re: [Caml-list] Re: Ocaml for Scientific computing From: skaller To: Florian Hars Cc: caml-list@yquem.inria.fr In-Reply-To: <46FA1800.90406@bik-gmbh.de> References: <2a1a1a0c0709251027v6dc42b38g1138b09f5627dbca@mail.gmail.com> <1190745994.12747.41.camel@rosella.wigram> <200709252138.49050.jon@ffconsultancy.com> <1190754074.6800.8.camel@rosella.wigram> <46FA1800.90406@bik-gmbh.de> Content-Type: text/plain Date: Wed, 26 Sep 2007 18:53:28 +1000 Message-Id: <1190796808.6800.87.camel@rosella.wigram> Mime-Version: 1.0 X-Mailer: Evolution 2.10.1 Content-Transfer-Encoding: 7bit X-Spam: no; 0.00; ocaml:01 0200,:01 hars:01 xavier's:01 ocamlopt:01 gcc:01 compiler:01 bug:01 compiler:01 gcc:01 2.5:98 sourceforge:01 wrote:01 stack:01 stack:01 On Wed, 2007-09-26 at 10:27 +0200, Florian Hars wrote: > skaller schrieb: > > I guess that this is easier. How much speed is gained eliding > > bounds checks? > > It may even make the code slower: > > http://caml.inria.fr/pub/ml-archives/caml-list/2004/01/679987f7b8b70e4cd9f088ac4e6c8097.en.html Yes, I tend to agree with Xavier's analysis. This may also explain why C code generated by Felix is often faster than hand written C code: on AMD64 Felix generated C code for Ackermann's function is almost the same as the hand written C, but runs 2x faster, and 2.5x faster than Ocamlopt generated code. At this point with gcc as the compiler and using stack programming (no heap), I'm now expecting Felix to beat C on all programs (and if it doesn't it's a bug in the compiler that needs fixing). I am guessing this is because GCC has good SSA analysis, and it works a lot better on goto spaghetti with a fixed stack frame of the kind Felix tends to generate, than block structured C code using for loops, etc. So I'd add to Xaviers comments on processor behaviour that small differences in source code structure can make a big difference to compiler technology. -- John Skaller Felix, successor to C++: http://felix.sf.net