[Shootout-list] Ray tracer

[Dave]

> -----Original Message-----
> From: shootout-list-admin@lists.alioth.debian.org
> [mailto:shootout-list-admin@lists.alioth.debian.org]On Behalf Of Jon
> Harrop
> Sent: Sunday, June 19, 2005 6:53 PM
> To: shootout-list@lists.alioth.debian.org
> Subject: Re: [Shootout-list] Ray tracer
>
>
> On Sunday 19 June 2005 19:06, Dave wrote:
> > Let's forget this damn 100 LOC limit *except as it was originally
> > intended* - to be a guideline for new ideas to make it into the sandbox.
>
> Are you happy with the lengths in the ray tracer test (57-471 LOC)?
>

Frankly, I don't care. I would like to see the fastest implementation, then
I'll look at the code and decide if 10% better performance is worth 400 more
lines of code (or whatever) to me.

>
> > Are people taking this stuff way too seriously, or what?
> >
> > Just keep the implementation rules and suggestions simple -
> after a program
> > is moved out of the sandbox let the implementors submit code reflecting
> > what is important to them.
>
> Would you be happy to see new algorithms and data structures used?
>

The 'same way' and 'same thing' idea that the original Shootout had was and
is Ok IMO - some things are so commonly used (like linked lists, hash
tables, etc.) that specifying 'same way' makes sense in some cases.

Then there are also cases where, say, most imperitive languages do something
more efficiently with arrays while many functional languages may be better
off using lists. So in that case it doesn't make sense to specify 'same
way'.

Most of the 'same thing' type of tests in the Shootout so far are trivial
enough so that while some details may be different, for all intents and
purposes the tests are basically doing everything the 'same way' anyhow
(e.g.: wc and wordfreq).

Brent did have a good point earlier regarding trying to control as many
variables as possible, but for raytracer it seems like this may be more of a
'same thing' rather than a 'same way' type of test. For example, the C
version can't operate on the data structures in the same way as C++ or Ocaml
because it lacks operator overloading and polymorphism.. How are you going
to control for things like that if you make the test 'same way'?

The current definition of the test here:

http://shootout.alioth.debian.org/sandbox/benchmark.php?test=raytracer&lang=
all&sort=fullcpu

would lead anyone not familiar with the current discussion to conclude that
anything goes.

>
> > We're all volunteers here - the best way to kill the Shootout
> would be to
> > make things more complicated than they already are.
>
> I think it would be simpler.
>
> --
> Dr Jon D Harrop, Flying Frog Consultancy Ltd.
> Objective CAML for Scientists
> http://www.ffconsultancy.com/products/ocaml_for_scientists
>
> _______________________________________________
> Shootout-list mailing list
> Shootout-list@lists.alioth.debian.org
> http://lists.alioth.debian.org/mailman/listinfo/shootout-list
>
>