My post is more about clarity and less about performance. Your proposed
alterations make the C++ implementation significantly longer and more
obfuscated and your littering of the source code with "inline" actually
slows the program down on my Athlon t-bird.

Moreover, your choices of initial optimisation are decidedly suboptimal. I'd
have gone for:

1. Terminating the intersection of shadow rays when the first intersection
is found (instead of finding the closest intersection).

2. Use an implicit scene, to avoid storing it explicitly.

3. Use single-precision storage (or no storage at all).

Both of these optimisations will give much bigger performance improvements
when averaged over different platforms and architectures.

As it happens, I had already implemented all of your optimisations and all
of these optimisations to both implementations before I made my original
post. None of them add anything new. Sometimes C++ is faster, sometimes
OCaml is faster. OCaml is always much more succinct. You can keep doing
this until you are blue in the face but I don't think you'll learn much of
interest.

Both ocamlopt and g++ were allowed to inline code.

As OCaml is for symbolic use, it performs no inlining by default (unlike
g++) so it is common to ask OCaml to do some inlining on numerical code.
Thus, specifying "-inline 100" actually makes for a fairer comparison.

Both implementations use pass by value as this is clearer, shorter and (as a
consequence) more common in real code.

If you want a fair comparison then you should also make equivalent changes
to the OCaml implementation.

You are trying to compare optimised C++ against unoptimised OCaml, which
would be unfair. More worryingly, you seem to have skipped the part of the
experiment where you actually measure something.

When restricted to 80 columns, your optimisations add several lines. Indeed,
they push the C++ program over 100 LOC limit imposed by the creators of the
shootout.

In fact, I'd already implemented your optimisations (and many more effective
optimisations) and had to throw them out because of this limit. Note that
the OCaml has 30 more lines with which to optimise. My optimised <100 LOC
OCaml program is much faster than my optimised <100 LOC C++ on all
platforms.

What would you recommend instead?

I chose an inheritance hierarchy because this is the closest C++ equivalent
to a variant type which I see in typical C++ programs.

Another optimisation that I made was to replace inheritance with a single
Scene struct which represented a group of child scenes or a sphere when it
had no children. I threw this out as well because it is not a fair
equivalent to OCaml's variant type. For example, you could not specify a
colour for each sphere without also specifying colours for all bounding
volumes.

Can you elaborate on these other "details"?

Manually implementing pass constant by reference is both obfuscating and
error-prone whilst being theoretically unnecessary. The fact that the OCaml
compiler does this optimisation for you when the GNU C++ compiler does not
might interest some people.

Everyone will be free to contribute to the shootout version of the ray
tracer. Perhaps you would like to contribute a less "fishy" C++
implementation?

--
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com