[Shootout-list] Ray tracer

Jon Harrop jon@ffconsultancy.com
Thu, 28 Apr 2005 11:47:16 +0100


On Thursday 28 April 2005 10:48, Bengt Kleberg wrote:
> Jon Harrop wrote:
> > I believe Isaac is saying that we need to have submissions under 100 LOC
> > in both Java and C# or the benchmark is not suitable for the shootout. I
> > don't know either of those languages, which makes that hard for me.
>
> this is a chance to learn a new languague, or two :-)

I don't really have any desire to learn either Java or C#. They both seem to 
be much more verbose and slower than OCaml. The next language on my list is 
Haskell.

> > Of course, with 97 LOC in OCaml, the nbody benchmark is perfectly
> > acceptable (and one of the most cross language benchmarks). There are
> > also 117 and 120 LOC versions in C# and Java. Indeed, most
> > implementations are over 100 LOC. Perhaps we should remove nbody? I think
> > not...
>
> it would be simpler to change the 100 lines limit to 120 lines. or 150.
> or 200. with such a limit (still not official, mind you) it would be
> neccessary with a reason. to avoid answering the question ''why?'',
> again and again.

I'd rather scrap the LOC limit and just see how quickly a benchmark gets 
ported to other languages. Despite its size, the nbody benchmark has been 
ported to more languages than many of the much smaller tests (fasta, 
pidigits, regex, reverse-complement etc.).

I think the number of languages a benchmark is ported to depends much more on 
how interesting the benchmark is, rather than how short it is.

> > Also, regex has entries with 164, 766 and 767 LOC and spellcheck has C
> > entries with 178 LOC.
>
> if only c# and java counts, then other langugaes with > 100 lines does
> not matter.
> it does raise the question as to why only these 2 matters. with such a
> limit (still not official, mind you) it would be neccessary with a
> reason. to avoid answering the question ''why?'', over and over.

Given that Isaac's rule conflicts with Brent's rule, I'd go with Brent's:

Provide implementations in:
1)  An interpreted langauge, a JIT language, and
    a compiled language.  This shows the range of
    performance we can expect (and helps to avoid
    setting too low a value of 'N' for compiled
    languages, or too high a value for interpreted
    languages.
2)  An Algol-variant (such as Pascal, Java, or C++),
    a lisp-variant (such as Scheme or Common Lisp),
    and an ML-variant (such as Objective CAML or
    SML).

Personally, I'd replace (2) with a non-functional (Algol variant) and a 
functional language (Lisp or ML derived).

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