[Shootout-list] Ray tracer

[Brent Fulgham]

--- Jon Harrop <jon@ffconsultancy.com> wrote:
> I think we should compare the fastest
> implementations under 100 LOC, anything 
> goes.

Dr. Harrop -- as a trained scientist I would think
you would see the value in trying to control for as
many variables as possible!  Do you really think an
"Anything Goes" attitude is correct when trying to
maintain some minimal level of objectivity?

> 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.

I agree that the results would be interesting, but
won't it be difficult to know what we are really
measuring?  If two different algorithms (and two
different data structures, etc.) are compared, how
can we determine what amount of the delta in
performance is due to algorithms versus the compiler
implementation?

You may not be privy to the regular scalding reviews
of the shootout in terms of measurement techniques
and 'fairness' (and so are perhaps not as sensitive
to these issues).  I think taking an 'Anything Goes'
approach will lead to more problems.

> 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?

One great benefit of the shootout is as a collection
of (often nontrivial) program implementations in a
wide range of languages.  I think we should accept
some level of 'noblesse oblige' and try to display
implementations that follow the coding style and
practices that are typical for the language in
question.  So, the short answer is "Use Stephen's
Style."

> 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.

This is not the obfuscated SML shootout.  We are not
trying to cram an interpreter for BASIC in a single
line of code!  I'd suggest extending the 100 LOC
guideline, but I recognize that that would only
raise the bar (not resolve the issue).  So, all I
can propose is that we try to follow Doug's original
guidelines and ask that people code their programs
as if LOC was not being measured.

And of course, I could always wave a dictatorial
wand and start reformatting files.... :-(

-Brent