Re: [Caml-list] Ray tracer language comparison

[Thomas Fischbacher <Thomas.Fischbacher@Physik.Uni-Muenchen.DE>]

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)