[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