🚀 go-pugleaf

In article <handleym-3003961246150001@a17-202-32-93.apple.com> handleym@apple.com (Maynard Handley) writes:
>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. 

You ask ***ME*** to be fair to the MAC, yet you are FAR from fair to me.
I CLEARLY showed the double precision operators used(including the 
transcendentals).  I was the FIRST to state that.  Further, it DOES have a lot
of other double precision code.  As to the use of transendentals, I didn't use
them in MY benchmark, so you can try THAT one!  Granted it isn't perfect.  I
doubt we'll ever find one.  It DOES, however, cover a lot of different items.
Even at THAT, compiler efficiency can make things very different.

Try THAT benchmark on your system, and let us know the particulars.  Frankly,
I AM curious.



>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 never claimed IT, NOR MINE, was the best!  I merely said that to show it was
unbiased.  Don't think for a MOMENT that gcc-2.7.2 is the best EITHER!  I know
for a fact it is NOT, because in converting from earlier software, system
performance went down by over 30% in some areas!  


>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.

BAD guess!  I have only HEARD that fast-math isn't fully IEEE compliant, and
some more complicated things show a slight difference.  That difference is 
VERY minor though.  Heck, on this large number, you have to go tothe sixth
decimal place. 

>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
>
>> 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


   ^^^^^^^^^^^^^^^^^^^^  GEE, you left this IN, though you claim that I didn't
                         realize this!


>> 
>> ALL are double precision!
>
>-- 
>My opinion only