[Shootout-list] Ray tracer

[Brent Fulgham]

--- Sebastien Loisel <sloisel@gmail.com> wrote:
> If there's one thing that's clear to me, it's that
> having things like ray tracers, n-body and LU 
> decomposition is more interesting than
> method call. But that's just me. So I'd like to find
> a way to make sure we can accept these tests.

I agree.

> So either
> 
> 0) we refuse these new app tests.
> 1) we pick an unrelated, but "less interesting"
> test, and demote it,

No to these two.

> 2) or we just add these "app" tests but try to keep
> a lid on so there's not too much proliferation.
>    a) Either we have a list of "apps" and require
> that there are no two variants of a single app. For
> instance, both n-body and implicitode are ODE 
> solvers.
>    b) Or if we disagree on whether two benchmarks
> are the same "app", whoever's trying to add the 
> latest app has responsibility for providing a large 
> (LARGE) number of implementations.

[ ... ]

> 2a) might be most tempting, but I was hoping to
> sneak in my tests with 2b). I intend to give ocaml,
> ml, haskell, fortran, c, c++, python,
> lisp, scheme and (if I am dragged kicking and
> screaming) java or perhaps even c#.

2b) would be fine, but there's also the issue of
maintenance.  Even if you provide some large 'N'
of tests, the old benchmark will have to be 
maintained.  If it is not provide any useful new
data, perhaps we should not have it.

If we aren't going too crazy, I think I can live with
2b).  But to answer Bengt's next question,
"What does too crazy mean", the answer is "I'm not
sure yet."

> Some traditional benchmark apps are
> 
> * raytracing
> * SOR/GMRES or some other iterative matrix solver
> * LU or sparse LU (direct matrix solver)
> * PDE solver
> * Fourier transform/convolution (beware FFTW!)
> * multipole
> * convex hull
> * linear programming
> 
> They are traditional, but I think Jon and I would
> like to put a spin on things by perhaps writing
> tests that _use_ these things instead of
> just running a quick test. So like you'd stick LU in
> some toy PDE solver as the linear solve, so it gets 
> used in an interesting way.
> Perhaps we can even decrease the # of apps this way.

I'm not quite sure I follow.  You mean one test
would run using the code from a second test?

-Brent