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.0 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 discorde.inria.fr (discorde.inria.fr [192.93.2.38]) by yquem.inria.fr (Postfix) with ESMTP id EEBC8BC6B for ; Fri, 29 Jun 2007 03:17:43 +0200 (CEST) Received: from ptb-relay03.plus.net (ptb-relay03.plus.net [212.159.14.214]) by discorde.inria.fr (8.13.6/8.13.6) with ESMTP id l5T1HhVM013583 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Fri, 29 Jun 2007 03:17:43 +0200 Received: from [80.229.56.224] (helo=beast.local) by ptb-relay03.plus.net with esmtp (Exim) id 1I457H-0004Kn-48 for caml-list@yquem.inria.fr; Fri, 29 Jun 2007 02:17:43 +0100 Resent-From: Jon Harrop Resent-To: caml-list@yquem.inria.fr Resent-Date: Fri, 29 Jun 2007 02:11:59 +0100 Resent-Message-ID: <200706290211.59224.jon@ffconsultancy.com> From: Jon Harrop Organization: Flying Frog Consultancy Ltd. To: Thomas Fischbacher Subject: Re: [Caml-list] The Implicit Accumulator: a design pattern using optional arguments Date: Thu, 28 Jun 2007 18:53:13 +0100 User-Agent: KMail/1.9.7 References: <200706271314.35134.jon@ffconsultancy.com> <200706281543.01424.jon@ffconsultancy.com> <4683DB41.50801@functionality.de> In-Reply-To: <4683DB41.50801@functionality.de> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200706281853.14015.jon@ffconsultancy.com> X-Miltered: at discorde with ID 46845DB7.002 by Joe's j-chkmail (http://j-chkmail . ensmp . fr)! X-Spam: no; 0.00; ocaml:01 run-time:01 ocaml:01 variants:01 subjective:01 frog:98 heap:01 wrote:01 caml-list:01 minor:01 minor:01 lisp:01 behaviour:01 variant:02 behaves:02 On Thursday 28 June 2007 17:01:05 you wrote: > ...so the continuation-based approach can execute not using the GC > at all - neither major nor minor. Sure, the OCaml GC behaves so > nicely that it does not make a difference in terms of run-time for > this particular small example Yes. > (1) is this the same if the minor heap is more complicated, as in a real > application and Converting to CPS typically slows programs down IME. > (2) shouldn't there be huge potential for optimization in the second case > then? Why? > In particular, concerning point (2), when comparing run times > with the following bit of C code, I find that both OCaml > variants are slower than the C variant by more than a factor > of 3: You are benchmarking "mod" and bounds checking. > >>According to your usually-screwed-up metrics... > > > > Time taken? > > We are talking about your ray-tracer here. Yes. > For those who do not know yet, the fundamental problem with that study > of yours is that you kept on setting the *criteria* what to consider as > a permissible solution only after seeing the result, and doing so in > such a way that the outcome is the one you desired, i.e. to create the > impression OCaml were the best system around. This is not proper > scientific behaviour. My choice of the intermediate implementations is subjective. The shortest and faster are a free for all. Feel free to post a faster Lisp implementation. -- Dr Jon D Harrop, Flying Frog Consultancy Ltd. The OCaml Journal http://www.ffconsultancy.com/products/ocaml_journal/?e