🚀 go-pugleaf

In article <stephenkDp0JpA.F6u@netcom.com>, stephenk@netcom.com (Stephen
Knilans) wrote:

Munch, munch, munch, a simple benchmark story I ate for lunch :-)

> And the result is:
>   
> Hansen Floating-Point
> Machine   OS      Processor   Raw  Normalized  Relative  Compiler  
> --------  ------  ----------  ---  ----------  --------  --------
> Power100  Sys7.5  PPC601/100  82s     82s          1     1,2
> ==================================================================
> 1: CodeWarrior 8
> 2: optimized for speed
> 
> Hansen Floating-Point
> Machine   OS      Processor   Raw  Normalized  Relative  Compiler  
> --------  ------  ----------  ---  ----------  --------  --------
> TRITON    lin-1.3.78  P5/100  66s     66s          1.24  GNU 2.7.2
> ==================================================================
> NOT optimized!!!!!
> 
> Hansen Floating-Point
> Machine   OS      Processor   Raw  Normalized  Relative  Compiler  
> --------  ------  ----------  ---  ----------  --------  --------
> TRITON    lin-1.3.78  P5/100  44s     44s          1.86  GNU 2.7.2
> ==================================================================
> -O2 optimizing     
> 
> Hansen Floating-Point
> Machine   OS      Processor   Raw  Normalized  Relative  Compiler  
> --------  ------  ----------  ---  ----------  --------  --------
> TRITON    lin-1.3.78  P5/100  36s     36s          2.28  GNU 2.7.2
> ==================================================================
> -ffast-math -O2 optimizing     
> 
> NOTE: fast-math is not ieee compliant, and the total is off by .000002
> HEY, that's less of an error than the FDIV problem! 
> 
> */
> 
> Please note, that the first measurement was from GREGORY HANSON, a PPC user!
> The other ones were by ME on a LINUX 1-3.78 system that had SEVERAL processes
> running!  HE listed his system as a PPC601/100 which I ASSUME is a 601 Power
> PC chip CPU running at 100MHZ.  GRANTED, my system has 256K PB cache, but 
> This benchmark is HEAVILY FPU intensive, and should be a good indicator of FPU
> performance.  On an apples to apples comparison(approx = attempts at
optimizing)
> the P5/100 was 86% FASTER!!!!!! 
> 
> Either HANSEN was mistaking, I misinterpreted his info, or you have the
> benchmarks BACKWARDS!  This test has a set number of iterations, and so 
> lower numbers are BETTER, as they indicate it took less time to complete.
> 
> Steve
> 
> BTW EACH loop has:
> 
> 3 adds
> 2 divides
> 1 multiply
> 4 transcendentals
> 
> ALL are double precision!

Maybe you could capitalize a few more words???!!!?

But seriously. Flaws in you analysis include, but are hardly limited to:

1) using a single measurement
2) not indicating other system information (RAM, HD, whether the Power100
had L2 cache, etc.)
3) comparing linux with a GUI OS, which inherently incorporates more
computing overhead. A better comparison would be under Windows. Even
better, comparing both systems on linux later this spring/early summer
when it is available for Nubus Mac's.
4) more recent versions of MacOS (e.g., 7.5.1) have a much improved
mathlib over System 7.5. Maybe the original poster has 7.5.1, but it isn't
indicated as in the above text.
5) MacOS is not fully native, linux is native on x86. The MacOS is not the
best OS to show how fast a PPC CPU is. Try comparing your linux results
with Win3.1 results on the same machine.
6) using ffast (which results in a small error) does not seem fair if a
similar option (i.e., better speed at the expense of getting the right
answer) is not also used in CodeWarrior.

To be fair, the poster to whom you were responding may have exaggerated
the performance of PPC in comparison to Pentium. My sense of the consensus
view was that 601 PPC's and Pentiums were more or less equivalent in speed
at the same Mhz, possibly with a slight advantage to PPC. As someone noted
in an earlier post in this thread, at Motorola's web site, you see as much
difference on the same chip using different compilers as you see between
processor families.

-- 
ted.oliver@asu.edu