From:	Yamaha / XYZZ <scriven AT CS DOT ColoState DOT edu>
Newsgroups:	comp.os.msdos.djgpp
Subject:	Re: Fixed Point (Optimization)
Date:	Thu, 09 Jan 1997 10:17:31 -0700
Organization:	XYZZ Software Co.
Lines:	28
Message-ID:	<32D5282B.41C6@CS.ColoState.edu>
References:	<Pine DOT SGI DOT 3 DOT 93 DOT 970108082917 DOT 19523G-100000 AT gibson DOT eee DOT upd DOT edu DOT ph>
NNTP-Posting-Host:	dali.vis.colostate.edu
Mime-Version:	1.0
To:	djgpp AT delorie DOT com
DJ-Gateway:	from newsgroup comp.os.msdos.djgpp

Orlando Andico wrote:
> > First: floating point is slower at add and subtracts. If all you ever do
> > is add/sub then integer will be 2* faster *at least*. If you use
> > Divides are slightly faster in fpu but a lot less hassle than fixed
> > point. If you use single precision fpu mode they are always 2* faster.
> > Also its possible to continue issuing integer instructions while a float
> > divide executes. That allows tricks like performing a perspective divide
> > in effectively 1 clk.

> is this true for 486's? or just Pentiums? i'm hacking at some MPEG audio

For 486's, try to avoid floating-point.  The integer math will be much
faster, though you still could do some long floating-point operations at
the same time as a bunch of integer calculations.  Also, on a 486,
multiplies (and especially divides) will always be slow unless you fake
it.

> code (MAPLAY -- UNIX-based really) so that it can run faster on 486's (the
> generic MAPLAY chokes on anything less than a Pentium-60) and I would love
> to learn about quickie speedups of FP code.

Look on my web page if you want opcode/timing listings for 486/Pentiums.


-- Yamaha / XYZZ          "May farce the with be you."
mailto:scriven AT CS DOT ColoState DOT edu          
mailto:scriven AT VIS DOT ColoState DOT edu
http://www.vis.colostate.edu/~scriven/

- Raw text -