🚀 go-pugleaf

I apologize for retaining the entire message below but some people may
want to refer to it.
What we see below is a classic case of the not very smart leading the even
less smart.
First of all we have the supposed benchmark which as any intelligent
person can see is a test of the speed of transcendentals on the given
machine, nothing else. So on PPC it is purely a test of the way the math
library was coded, not a test of the CPU. (My recollection is that on x86
the FPU does transcendentals so there are not math library issues involved
but I could be wrong.)
Second we get a pretty lame PPC compiler to do the work and claim that
because that was the compiler used by a PPC fan, that means it's the best
a PPC can do. Just because a person is a PPC fan doesn't mean they know
squat about what makes the CPU tick or how to make it work better.

I compiled this same code below using mcc 2.0, all optimizations and the
motorola math library. The result was, using the format below

Hansen Floating-Point
Machine   OS      Processor   Raw  Normalized  Relative  Compiler  
--------  ------  ----------  ---  ----------  --------  --------
8100/110  MacOS   601/110     28s     31s         2.65   mcc 2.0
==================================================================
-O4, link with libmoto.

I am guessing libmoto is fully IEEE compiant since the docs do not
indicate otherwise and the results were identical with the "standard" math
lib.

So what we have is a best case "speedup" on Pentium of 1.86 vs 2.65 on 601,
ie a factor of 1.4. Even when the less acuurate math lib is used 601 comes
out ahead.
Please on future such comparisons make sure you are at least vaguely being
fair to PowerPC.

Maynard Handley

---------------------------------------------------------------------------

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

> In article <dke-2803961851210001@adnline290.adnc.com> dke@adnc.com
(David K. Every) writes:
> >In article <4jf32c$qm6@steel.interlog.com>, daveacg@interlog.com (Dave
> >Glue) wrote:
> >
> >> PPC is faster running Bytemarks. That is all that it shows.  Wow,
> >> looking at SpecMarks, the Pro is faster, guess it's the faster
> >> processor then.
> >
> >OK.. but Apple and others have shown that PowerMacs are faster than P5's
> >by a gawd awful amount - up to 3 times at the same clock rate (fp
> >intensive stuff)... now according to Intels OWN numbers, the P6 is only
> >50%+ faster at the same clock rate (at least the ones I saw)... so that
> >would make it what?!?! A heck of a lot slower in the real world than a
> >604?!?!
> >
> >Which seems to be the case I've seen... (only based on the P5's). Intel
> >claimed it was as good as the 601... it was EATEN ALIVE. We did some
> >comparisons and the 66mhz 601 was beating the 120mhz P5 in processor or
> >floating point intesive stuff. So now they claim the P6 is better still...
> >and I'm supposed to beleive what? That THIS TIME they mean it... that they
> >didn't lie (market creatively) like they always do?!?!  I look at the
> >performance difference on my 150mhz 604 (as compared to a 66mhz 601) and
> >think, there is NO WAY that Intel made the P6 3 TIMES faster (minimum)
> >than the P5... which is what they would have had to have done.
> >-- 
> 
> Ya know, I WAS going to mail this post back seperate, but I guess I'll do it 
> HERE!  the P5 was "EATEN ALIVE" by the 601, HUH?  Look at this, and tell
me how
> we are mistaken!
> 
> #include <stdio.h>
> #include <math.h>
>  
> void main(void)
> {
>         double  sum, i;
>         
>         sum = 0;
>         for(i=1;i<10000000;i++)
>         {
>                 sum = sum + sqrt(sin(i/4.2)*sin(i/4.2) + log(i));
>         }
>         printf("total: %f", sum);
> }
> /*** end ***/
> /*  
> 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!

-- 
My opinion only