🚀 go-pugleaf

In article <4jhq8r$nt2@cville-srv.wam.umd.edu>,
David T. Wang <veakblad@Glue.umd.edu> wrote:

>I didn't want to say anything, because I knew from just looking at the 
>code how silly it was. I think that it was hashed out here a while back
>that PPC601's didn't support transedentals (sine, cosines) via hardware,
>while pentiums did, so any simplified benchmark like the one given by
>Mr Hansen will show the Pentium "better" than a PPC chip.  I think that
>it's not even close to a decent benchmark, all it shows you is that if
>you happen to be writing your own code, and you use a bunch of sines and 
>cosines all the time, you'd be better off with a Pentium, that's about it.

Thank you for that explanation.  I admit I was a little confused by the 
results, but what could I do but show what I'd found?  I missed the 
hashing of PPC math because there's so darn much traffic here I only read 
it sporadically.  It seems kind of obtuse to leave out transcendals since 
almost anything that uses floating-point math is going to start slinging 
them around.  How about the PPC604?

>Ofcourse Mr Hansen could return with a new program which completely eliminates
>sine and cosine, but he could then carefully pick some operations whose
>code implementation uses instructions which are faster on the PPC601
>than a Pentium.  And then if someone else had the energy or drive to do it,
>just come back with a different "benchmark" which could favor the Pentium.
>This is why benchmarking is a difficult art.

Then perhaps we can have "with transcendentals" and "without 
transcendentals" catagories.  The reason I proposed the UseMarks is so 
our readers can remove the ambiguities.  When they can examine the 
benchmarks, debate them, and propose their own, hopefully we can get some 
numbers that everyone's happy with.  Then the only argument will be 
interpreting them ("601 does floating point faster!"  "So what?  It 
can't find a sine.") rather than the numbers themselves.

Maybe needless to say, I hope some more qualified persons can help with 
the project.

In <4jp2i8$f0r@nuke.csu.net> ghansen@isc.sjsu.edu (Gregory L Hansen) writes:

>In article <4jhq8r$nt2@cville-srv.wam.umd.edu>,
>David T. Wang <veakblad@Glue.umd.edu> wrote:
>
>>I didn't want to say anything, because I knew from just looking at the 
>>code how silly it was. I think that it was hashed out here a while back
>>that PPC601's didn't support transedentals (sine, cosines) via hardware,
>>while pentiums did, so any simplified benchmark like the one given by
>>Mr Hansen will show the Pentium "better" than a PPC chip.  I think that
>>it's not even close to a decent benchmark, all it shows you is that if
>>you happen to be writing your own code, and you use a bunch of sines and 
>>cosines all the time, you'd be better off with a Pentium, that's about it.
>
>Thank you for that explanation.  I admit I was a little confused by the 
>results, but what could I do but show what I'd found?  I missed the 
>hashing of PPC math because there's so darn much traffic here I only read 
>it sporadically.  It seems kind of obtuse to leave out transcendals since 
>almost anything that uses floating-point math is going to start slinging 
>them around.  How about the PPC604?

Didn't the 'R' in RISC stand for "reduced"?  Now you want a RISC chip
with full-blown CISC features :-)

It's not at all obtuse to leave out transcendentals, because only a
rather insignificant percentage of the cpu time spent in a "typical"
number crunching application is used for computing transcendentals.
Of course, exceptions do exist, but the designer tries to optimise for
the mainstream (read SPECmarks :-)

A _good_ math library can implement them in software very efficiently,
but this can be done only by people who have done some serious research
(or, at least, reading) in this field.  The quick and dirty Taylor/Mac
Laurin series approach is catastrophic, performance-wise.

Dan
--
Dan Pop
CERN, CN Division
Email: danpop@mail.cern.ch 
Mail:  CERN - PPE, Bat. 31 R-004, CH-1211 Geneve 23, Switzerland