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 nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by yquem.inria.fr (Postfix) with ESMTP id 704BABB94 for ; Tue, 4 Oct 2005 15:49:09 +0200 (CEST) Received: from mail.physik.uni-muenchen.de (mail.physik.uni-muenchen.de [192.54.42.129]) by nez-perce.inria.fr (8.13.0/8.13.0) with ESMTP id j94Dn8BR027728 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Tue, 4 Oct 2005 15:49:08 +0200 Received: from localhost (unknown [127.0.0.1]) by mail.physik.uni-muenchen.de (Postfix) with ESMTP id 2EDDF20013; Tue, 4 Oct 2005 15:49:08 +0200 (CEST) Received: from mail.physik.uni-muenchen.de ([127.0.0.1]) by localhost (mail.physik.uni-muenchen.de [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 02592-01-95; Tue, 4 Oct 2005 15:49:08 +0200 (CEST) Received: from mailhost.cip.physik.uni-muenchen.de (kaiser.cip.physik.uni-muenchen.de [141.84.136.1]) by mail.physik.uni-muenchen.de (Postfix) with ESMTP id 00DA12000A; Tue, 4 Oct 2005 15:49:08 +0200 (CEST) Received: from eiger.cip.physik.uni-muenchen.de (eiger.cip.physik.uni-muenchen.de [141.84.136.54]) by mailhost.cip.physik.uni-muenchen.de (Postfix) with ESMTP id 31FE126E87; Tue, 4 Oct 2005 15:49:07 +0200 (CEST) Received: by eiger.cip.physik.uni-muenchen.de (Postfix, from userid 3092) id 067FF12F75; Tue, 4 Oct 2005 15:49:07 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by eiger.cip.physik.uni-muenchen.de (Postfix) with ESMTP id 013FA12F17; Tue, 4 Oct 2005 15:49:06 +0200 (CEST) Date: Tue, 4 Oct 2005 15:49:06 +0200 (CEST) From: Thomas Fischbacher To: Jon Harrop Cc: caml-list@yquem.inria.fr Subject: Re: [Caml-list] Ray tracer language comparison In-Reply-To: <200510040018.24932.jon@ffconsultancy.com> Message-ID: References: <200510040018.24932.jon@ffconsultancy.com> X-BOFH: Daemons did it MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: amavisd-new at physik.uni-muenchen.de X-Miltered: at nez-perce with ID 43428854.001 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam: no; 0.00; caml-list:01 trivial:01 snippets:01 integers:01 ocaml:01 inference:01 2005,:98 ...:98 tower:98 cip:98 cip:98 lambda:01 lambda:01 wrote:01 integer: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.0 required=5.0 tests=SPF_FAIL autolearn=disabled version=3.0.3 On Tue, 4 Oct 2005, Jon Harrop wrote: > > I've updated my language comparison with four implementations in Scheme and > one in Lisp: > > http://www.ffconsultancy.com/free/ray_tracer/languages.html I think this analysis is quite seriously flawed: (1) You are mostly comparing implementations, not languages, yet call this a "language comparison". (2) Just having a glance at in particular at the Lisp implementation immediately reveals trivial but relevant further optimizations that one would like to include. For example, just adding a further entry (:type (vector double-float)) to (defstruct vec ...) reduces run time by more than 20%. I did not take a closer look yet, but my impression is that this is not even a comparison of implementations, but just a comparison of various snippets of code for various languages, written by people with quite different proficiency with the individual languages and implementations. So, I wonder whether the data may indeed be quite seriously flawed. (3) Unless I missed some interesting development, Stalin by no means is a "Scheme", at least for any of the official definitions of the term "Scheme" (IEEE, RnRS). Of course, it is easy to optimize towards using machine integers (instead of "proper numbers") if the system just does not support the Scheme numerical tower. (4) You are just looking at one single example application, which in addition is not especially large. So, if Lisp's metasyntactic capabilities really are a great boon, as many people like to claim, this clearly will not show in a ~100 lines example. And this is just one example of a small "benchmark" program not really allowing any conclusions for real world applicability. So, okay, OCaml is a great system for writing a primitive raytracer in ~60 lines, but I would not dare to extrapolate any conclusion about other programs from this. (5) Some statements are just plain outright wrong, such as this: "In practice, SBCL is very poor at inferring types and it is necessary to litter the source code with type declarations, as we have done here." While SBCL/CMUCL are not Hindley-Milner, their type inference does know more tricks than one might suppose. If you declare a number to be an integer in the range (0..100) (which you can do), it will know that its square is in the range (0..10000). If you declare a number x to be a fixnum, then it will know that (+ 1 x) will not necessarily be a fixnum, and hence generate generic addition code (which it has to - to maintain correctness). So it is more an issue of the programmer expecting different things from the system than it provides. Please do not spread such un-informed comments that just contribute to the general confusion and misunderstanding. -- regards, tf@cip.physik.uni-muenchen.de (o_ Thomas Fischbacher - http://www.cip.physik.uni-muenchen.de/~tf //\ (lambda (n) ((lambda (p q r) (p p q r)) (lambda (g x y) V_/_ (if (= x 0) y (g g (- x 1) (* x y)))) n 1)) (Debian GNU)