🚀 go-pugleaf

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