[Shootout-list] Science-related benchmarks

[Sebastien Loisel]

> Thanks for the links. What code have you written so far?

The only shootout style code is what's already been discussed
(implicitode, spectral norm, that integrator with a heap you hacked.)
The PDE solver, LU, GMRES etc... isn't written at all in shootout
style. It's hard work to get it to be <100 lines in many languages (I
try for c++ ocaml python c.)

There's also an issue. I will try to code these things so that they
make sense and are <100 lines, but sometimes it's possible to do
better by implementing stuff differently. For instance, an initial
implementation of a sparse matrix library might be built on top of the
map<> data structure, but ultimately this is probably not the most
efficient way. It would be nice if there could be one or more
reference implementations, which may not show the language in their
best light (because they run slower) but which are easier to
understand than the longer, but more efficient implementations. The
longer implementations aren't necessarely poor style -- mostly they
are caused by having to implement some algorithm or data structure
that's not in the language library, like FFTW.

> The optimisation I proposed is general purpose, not specific to the spher=
e
> flake. I've written the ray tracer now (currently 224 LOC in OCaml) but u=
sed
> hierarchical spherical bounding volumes instead of the set-plane trick as
> these can be used to accelerate non-primary rays. It can generate and ray
> trace a sphere flake containing over half a million objects with shadows =
and
> reflections in 36s at 1280x768.
>=20
> Code for the shootout could be a lot shorter as my current implementation
> does incremental rendering using OpenGL and the input is generated in the
> same program. I'm not sure I can get it below 100 LOC though.

Strip all the gui and make it spit out a pgm file
http://www.die.net/doc/linux/man/man5/pgm.5.html (get rid of color,
gray is enough.) I'd like to take a look at it after.

Sebastien Loisel