[Shootout-list] What people say about shootout

[Jon Harrop]

On Friday 29 April 2005 21:19, Dave wrote:
> Let's see, right now harmonic, heapsort, mandelbrot, nbody, random and
> takfp are all primarily floating point.

I wouldn't call "heapsort" and "random" floating point. AFAIK, heapsort need 
not use any floating point as you can compare and shuffle bits. Even if 
heapsort is implemented using floating point, it is probably more memory 
bound than arithmetic bound. Random uses more integer arithmetic than 
floating point.

> Given that the goal is 25 tests (that's what the home page says anyhow) and
> there are 6 already, we're at 25% - which seems reasonable to me.

I make that 4/25 = 16%.

> Plus, fasta and knucleotide also use the random algorithm. And the sandbox
> also has spectal-norm and 'health' (uses random).

I just profiled the OCaml implementation of knucleotide and most of the time 
is spent in the GC and in the hash table, so not FP. Spectral norm should be 
FP.

> Given that, I think that all in all the balance is pretty good, with maybe
> 1 more new and 1 to replace harmonic or maybe random sense it is used in
> other benchmarks.

Could random be relegated to a "common code" section and not counted as a 
benchmark?

> The ray-tracer looks promising to me as one to include I 
> guess.

Yes, I like the ray tracer. :-)

I'd like to replace nbody with my "relax" benchmark (once I've written it!) as 
it is a similar idea but more juicy.

The ray tracer is also an interesting and instructive example for various 
different reasons. I'd like to see the equivalent to MLs variant type and 
C++s inheritance hierarchy in different languages. I guess it would be a 
tagged union in C. As the ray tracer is also floating point intensive then it 
certainly belongs in this category but I vote that we put it up and see what 
people's responses are and, particularly, see how many other languages it 
gets ported too before deciding whether or not it should replace an existing 
benchmark.

If nbody is to be kept then I really think we should factor out all of those 
magic numbers - it's really quite bad!

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