[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