[Shootout-list] Ray tracer developments
Jon Harrop
jon@ffconsultancy.com
Sun, 1 May 2005 14:24:32 +0100
On Sunday 01 May 2005 13:24, Sebastien Loisel wrote:
> I think your C++ version is longer than it needs to be. There is no
> need for virtual functions and derived classes.
The inheritance hierarchy is certainly one of the most verbose parts. But what
would you use instead? You could use a tagged union, but that is much more
common in C than in C++.
> Keep in mind that
> you've done several iterations of the ocaml and just one of the C++.
Well, 11 iterations of the OCaml (starting from scratch) and then two
iterations of the C++ starting from a working OCaml program.
> * On the proportion of floating point code and the 25 test limit
>
> If there's going to be some sort of decision that 5 programs (say) and
> only 5 programs are allowed in the FP category then I would like to be
> consulted as to what 5 programs these should be. I joined this effort
> to try to improve the scientific computing aspect, which is my field.
> The numerical codes present in the current shootout look nothing like
> traditional or forward-looking scientific computing benchmarks, except
> for n-body. If we have such a budget, I would like to know it, and
> then I would like to reallocate this tight budget as efficiently as
> possible to the highest quality test possible.
That was just an idea I proposed. Nobody in authority has agreed to it. I
agree that you should be responsible for many of the FP intensive scientific
computing benchmarks. As these aren't really relevant to the scientific
computing that I do, I'll concentrate on the non-FP ones.
> * On magic numbers in FP code.
>
> This is good practice in the field of scientific computing.
No, this is an awful (but all too common) practice in the field of scientific
computing and, if you were my student, I would fail you for saying that! :-)
> For
> instance, the magic numbers in n-body are astronomical measurements.
> In other cases, there are large and unwieldy algebraic relations, but
> seeing sqrt(pi * ((1 + (pi^2)) / ((pi^3) - (sqrt(2 + exp(-3)) * (pi^(1
> / (2 + exp(-3)))))))) instead of 1.09453934 doesn't give any useful
> information.
The algebraic expression tells you the formula from which the digits are
derived, which is very relevant information and belongs in the program. You
wouldn't determine the memory contents of an initialised struct and then
allocate it by bits, would you?
> Moreover, much of the time there is no closed-form algebraic expression for
> the quantities.
Yes, there is no simple, closed form algebraic expression for most of the
quantities used by programs, e.g. the input to the "count-words" benchmark.
This is precisely the time to relegate such data to a separate file.
The easiest way that I can see around this problem is to increase the number
of magic numbers you would want to put into the code to the point that it is
blatantly silly (the program is almost entirely data with a little bit of
code scattered in between, which nbody is already to me). With about a
million magic numbers, my "relax" benchmark should fit the bill.
--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
Objective CAML for Scientists
http://www.ffconsultancy.com/products/ocaml_for_scientists