[Shootout-list] Science-related benchmarks

[Jon Harrop]

On Monday 25 April 2005 15:28, Sebastien Loisel wrote:
> Looks good to me. Why didn't you use the conjugate gradient method though?

I felt it was too complicated and off-topic for that section of my book. A 
production program should definitely use something more sophisticated though. 
IIRC, Newton's method is actually better here because it is more numerically 
robust in the presence of a "noisy" derivative than CG. Obviously that would 
be a whole can of worms.

> > > > Some languages may be able to represent the lists (and their tails)
> > > > as arrays
> > >
> > > Which languages?
> >
> > In the shootout? No idea.
>
> Any language anywhere?

The Mathematica JIT compiler I wrote for Wolfram Research included this 
functionality. Coupled with the unusually powerful pattern matching 
capabilities of Mathematica, many such algorithms can be expressed very 
clearly and succinctly compared to the mess of array accesses that you end up 
with otherwise.

I wouldn't be surprised if some free language somewhere has this capability, 
but I don't know of any.

> There isn't that much difference between Haar and the next thing up,
> but that's not important. More to the point, I'm not sure the Haar
> transform is that interesting. In fortran I'd do it as arrays+floats,
> and the computations risk taking a back-seat to the memory accesses.

Yes, I'm not sure it would be FP bound. Perhaps a Newton-Raphson based quadric 
ray tracer would be better for pure FP performance as the inner loop would be 
root finding a little function without needing to access any other data.

> > Instead of using hierarchical bounding volumes, you could compute the
> > sets of spheres which intersect horizontal and vertical planes. Then you
> > can restrict
>
> Something like

That's short! I'll have a look at that code in more detail in a minute...

> and then the rest of the benchmark is a bunch of set intersections?
> That's not a lot of floating point work if you ask me, but ok.

We could try FP intensive tests (e.g. bounding box) instead and see if they 
were faster. I'd be surprised if they were though, unless we're also doing 
shadow rays or reflections.

> > Here's my improved C++ version of your integrate benchmark:
>
> Thanks for the code, I will look at it. With sin(x ln x) did you
> notice a speed change at all between your versions and my versions?

The C++ was virtually identical - just cosmetic improvements. I shaved 10% or 
so off the OCaml (mainly by type specialising the heap, IIRC).

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