From: Isaac Gouy <igouy@...>
Date: 2006-08-03T03:00:08+09:00
Subject: Re: For performance, write it in C - Part 3, Source code now available


Peter Hickman wrote:
> Charles O Nutter wrote:
> > Ok, so there's a bunch of problems with the Java version.
> >
> > - In addition to the addRow run and the Java startup time you're also
> > benchmarking over 5200 array modifications to set Compared values to true
>
> That was simple because I couldn't define the array when I declared it
> as I did in C.


1) I made some changes to the jen.pl script you used to generate the
Java program, it now splits apart the array initialization into many
different methods - and that will let you generate a Java program for
6x6. I emailed it to you.


2) By "benchmarking without analysis is bogus" I understand that
without analysis the programs might not be doing what we think they are
doing - what we think is an apples to apples comparison might not be an
apples to apples comparison.

In this case, I understand Charles O Nutter to be saying that in C all
those boolean arrays are initialized at compile time, but in Java all
those boolean arrays are initialized at runtime - so although we're
writing a similar thing in the code, we aren't doing the same thing
when the code is run.

In the same way, we have similar print statements in the C and Java
code, but they don't do the same thing when the code is run - one deals
with bytes the other deals with Unicode double bytes.

So it depends which part of the computation we're interested in - if
we're interested in the addARow recursive calls and loops, that part of
the computation might be swamped by the time taken to to initialize the
arrays at runtime and naively print strings.


3) There seems to be a bigger problem with using this latin squares
algorithm for benchmarking - the computation explodes!

        0.496s gcc 5x5 (without print statements)
30055.098s gcc 6x6 (without print statements)