[Shootout-list] Ray tracer

Jon Harrop jon@ffconsultancy.com
Fri, 17 Jun 2005 16:53:35 +0100


On Friday 17 June 2005 13:45, Stephen Weeks wrote:
> It would be nice for the algorithm and problem spec to be clarified
> and to stabilize, because I would guess a lot of implementations are
> out of sync, so it's not very clear what is being compared.

I think we should compare the fastest implementations under 100 LOC, anything 
goes. These are the optimisations that I'm guessing can be done in each of 
the major languages:

OCaml: Maybe better bounding volumes (e.g. pyramids), explicit scene tree with 
computed bounds, specialised shadow-ray intersection functions.

SML: Explicit scene tree with computed bounds, specialised shadow-ray 
intersection functions.

C++: Maybe a flat scene "tree", pass by reference, partly specialised 
shadow-ray intersection function.

Java/C/Fortran/C#: None.

I have found that the optimisations are very language-dependent. For example, 
making the scene tree implicit (computing it on-the-fly) made the OCaml much 
faster and the MLton much slower. So I think the diverse results will be of 
greater interest than a set of equivalently-naively written implementations.

> In any case, I've committed a new revision of raytracer.mlton that
> makes the same algorithmic improvements as in raytracer.mlton-2.  They
> now run at roughly the same speed.

Are the only differences stylistic between your code and my code? Having had a 
long debate on comp.lang.functional about this, I'd be interested to hear 
what others think about the code style on the shootout. Should we use 
Stephen's style, which is more representative of typical SML code, or should 
we use my style, which is more representative of the brevity of SML's grammar 
but arguably less comprehensible?

I think it would be best to use my style as, otherwise, both the performance 
and the LOC of MLton will suffer unrepresentatively if we adopt the "fastest 
under 100 LOC" approach.

-- 
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
Objective CAML for Scientists
http://www.ffconsultancy.com/products/ocaml_for_scientists