Hello Nick,

NK> deal of PM code in addition to the "test" code.  I could
do a bunch of 
NK> sorted-list insert, or fill one of our "cellbox" with
10,000 items ... is 
NK> there anything out there to use as a model or give me some ideas?

In late 1993, I did some timing tests for a Belgian magazine. I compared
BC++ OS/2 version 1 to CSET 2.00. At the time I used some encryption
algorithm, a freeware adventure game and a DNA pattern matching program.
CSET compiled programs were 10 (encryption) to 20% (DNA) faster than those
compiled with Borland. They were also roughly some 10 or 15 % bigger. The
size increase seemed to decrease with the total size of the program being
compiled. At the time I thought that the IBM compiler just linked by
default a few things that Borland left out, unless they were actually used.
 
I retested in 1994 for the same magazine to reach the same conclusions,
except that the Watcom Compiler was also included. This time I also used
the training of a neuronal network (developed by a student at a University
nearby) to compare the compilers. Watcom came first by about 5%.

IMHO, "PM code" is essentially an interpreted language and
execution time should not be compiler dependent. It was not tested. Of
course, in the real world application and in an OS like OS/2, the way
memory is allocated, commited, swapped, the way resources are handled, the
way segments are kept in memory etc... is very important... and very hard
to evaluate. During the "DNA test", one of the program began to
trash on the HD. Performance took a severe penalty. The problem was solved
paradoxically by eliminating all cache ( it gave more memory to the
application ). 

I have seen advertisements for products that claim to enhance the speed of
your programs simply by shuffling its pieces around. Never had an
opportunity to test them. But it occurs to me that if they really do what
they pretend (40 to 200 % speed increase advertised), their impact on
optimization is one order of magnitude above the impact of the compiler...
:) Maybe then, what we should test is the susceptibility of the code
produced by one compiler to post-processing by reorganizers...

BENCH.ZIP     201 03-29-94  C Benchmarks to see how your PC stacks up against
                            MIPs4000, DEC Alphas
SBENCH09.ZIP  135 12-03-94  System Benchmark "SysBench" 0.9.0 - tests:
                            Graphics, CPU integer, CPU float, Disk I/O, an
                            memory (source included)

Are two files that may interest testers and are freqable from my system
(and from many others, I assume)

Pierre
@EOT:

--- Msgedsq 3.04