timings using optimized codewarrior

[John Hall]

Gang:
Well, my student and I just got an optimized version of a simple 
little diffusion stencil using Metrowerks Codewarrior and frankly the 
results are kind of interesting. First, optimized code runs around 6 
times faster than unoptimzed code. Dave Nystrom and I seem to recall 
that optimized code under R1 ran 10-20 times faster than unoptimized 
using KCC. I don't want to attach too much significance to this 
though. It is an indicator that either Metrowerks optimizer is not 
all that hot (my belief) or that somehow the abstractions of R2 are 
somehow less onerous in debug mode (also a possibility).

Anyhow, this was a 2-D diffusion stencil and no matter what we tried 
we always got a linear response in the timing study. For the first 
block, this is a good result since we were just running the same size 
problem for more cycles.

But, we tried to run larger and larger problems to get us to go out 
of L2 cache (on this PIII we had a 256K L2 cache), and we were never 
able to notice a drop. It stayed linear versus the total number of 
cells. This will make more sense when we can convert the units to 
something like MFlops. So either you guys have done something really 
impressive regarding cache utilization, or we are running so slowly 
that cache misses are not noticeable.

Also, we ran optimized on a Mac and a PC and the result differed 
exactly by the difference in clock speed. This was a surprise, since 
Mac advocates had always claimed that the Motorola floating point 
performance was better than that of Intel at a given clock rate. 
(This was for a 650 MHZ PIII laptop and a 500 MHz G3 laptop).

As an aside, the Brick Engine ran reproducibly slightly slower than 
compressibleBrick (only about 5 percent, so it was basically a dead 
heat), but, I would have expected Brick to be slightly faster than 
compressibleBrick (and probably by more than a few percent since it 
should have less overhead).

Anyhow, here is the raw data for the Brick PIII runs:
cellsXY cycles  elapsed time (secs):        Total Cells
101     1000    24      24      24              10201
101     2000    48      48      47              10201
101     3000    72      71      72              10201
101     5000    119     122     121             10201
101     10000   243     243     244             10201
101     25000   608     607     606             10201

25      1000    2       2       2               625
51      1000    6       5       5               2601
101     1000    24      24      24              10201
201     1000    103     103     103             40401
501     1000    635                             251001
1001    1000    2520                            1002001


15      5000    4       4       3               225
25      5000    8       9       8               625
51      5000    29      29      28              2601
75      5000    61      61      61              5625
101     5000    124                             10201
201     5000    518                             40401
401     5000    2054                            160801


3       10000   3                               9
6       10000   3                               36
12      10000   6                               144
24      10000   15                              576

3       100000  28                              9
6       100000  34                              36
12      100000  59                              144
24      100000  150                             576

This was single processor with no MPI, etc under Win 2000. All I/O 
was turned off within the timed region so it was just Cycle Manager 
loop overhead (Tecolote Loops over models, in this case 1 Model) and 
floating point calculations being timed. There were 3 fields 
involved, Temperature, Conductivity and a TmpField to collect the 
stencil info. We used difftime and the time_t time functions to 
collect our data (in seconds), so only high granularity can be 
studied.

Code:
This is the relation between Conductivity (Lval) and Temperature:

template<class Traits>
void DiffRelation<Traits>::ConFuncT6( const ScalarField& Conductivity,
                                      const ScalarField& Temperature ) {
    Conductivity = (1.0/(2.0*Dim))*pow(Temperature,Real(6.0));
}

This is the relation between TmpField (Lval) and Conductivity and Temperature:
template<class Traits>
void OffsetRelation<Traits>::sumNeighbors(const ScalarField& TmpField,
        const ScalarField& Conductivity, const ScalarField& Temperature ) {
        Interval<Dim> ND = Temperature.domain();
        Loc<Dim> offset;
        TmpField = 0.0;
        for ( int d = 0; d < Dim; ++d ) {
                for ( int off = 0; off < Dim; ++off ) {
                  offset[off] = off==d ? 1:0;
                }
		TmpField(ND) += 
Temperature(ND+offset)*Conductivity(ND+offset) +
                                Temperature(ND-offset)*Conductivity(ND-offset);
        }
}

So the loop was just over this one line:

Temperature = (1.0-2.0*Conductivity*Dim)*Temperature + TmpField;

which kept causing the other two updater dependencies above to get 
called as relations.

There are some obvious optimizations which can be performed on this 
code, but, it was the relative timings of optimized and unoptimized 
executables (factor of 6) along with these simple scaling studies 
that we were interested in.

Hope this is interesting,
John Hall and Richard Williams