Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!helios!bcm!rice!uw-beaver!mit-eddie!wuarchive!usc!jarthur!nntp-server.caltech.edu!kanga!bchen
From: bchen@pooh.caltech.edu
Newsgroups: comp.sys.next
Subject: Re: 68040 Math / Why so much system time?
Message-ID: <1991Feb15.064606.14492@nntp-server.caltech.edu>
Date: 15 Feb 91 06:46:06 GMT
References: <1991Feb15.045235.5984@ee.ualberta.ca>
Sender: news@nntp-server.caltech.edu
Reply-To: bchen@pooh.caltech.edu
Distribution: na
Organization: California Institute of Technology, Pasadena
Lines: 29
Originator: bchen@kanga
Nntp-Posting-Host: kanga

From article <1991Feb15.045235.5984@ee.ualberta.ca>, by keen@ee.ualberta.ca (Jeff '876393' Keen):
> 
> to the extra hardware.  This speeds up the hole affair without a
> change in any software.  Anyway the 68040 executes the floating point
> faster, so the minimal overhead in the trap wouldn't change the time
> much.  This is based on my personal knowledge of the 68040, if I had a
> spec sheet handy I could confirm this, but I don't so I won't.

The problem is the 68040 floating point speed is 30%-100% slower than that
of 25Mhz 68882 when emulating transcendental functions. The following table
shows the execution speed of both 68040 and 68030 of some fairly common
transcendental functions (I use them a lot) in units of Kilo-operations
per second. 

Operation 	68040 (Kops/sec)	68882 (Kops/sec)
fetoxx(exp)	36.092 			49.448 
flognx(log)	37.290			45.510 
fsinx		35.361			64.281 
fcosx		35.950			64.641 			
ftanx		37.323			53.201 

I like the idea of providing different shared libraries depending on 
processor. I see no reason why this would cause any problems, it requires
no change in software at all if you don't compile the program with inline
math. Or one may hope Motorola can provide a more efficient emulation libary.

------------
Bing Chen
NeXT Mail: bchen@pooh.caltech.edu