From: gpt20 AT thor DOT cam DOT ac DOT uk (G.P. Tootell)
Newsgroups: comp.os.msdos.djgpp
Subject: Re: floating point is... fast???
Date: 20 Jan 1997 18:36:00 GMT
Organization: University of Cambridge, England
Lines: 55
Sender: gpt20 AT hammer DOT thor DOT cam DOT ac DOT uk (G.P. Tootell)
Message-ID: <5c0dug$bh1@lyra.csx.cam.ac.uk>
References: <5brd2e$dap AT lyra DOT csx DOT cam DOT ac DOT uk> <32e22337 DOT 2066519 AT ursa DOT smsu DOT edu> <5bvjeb$mji AT lyra DOT csx DOT cam DOT ac DOT uk> <853780174 DOT 909237 AT araga DOT funcom DOT com>
NNTP-Posting-Host: hammer.thor.cam.ac.uk
To: djgpp AT delorie DOT com
DJ-Gateway: from newsgroup comp.os.msdos.djgpp

well i had a look thru the code produced to see if i could find any evidence of
this and it seems you're sort of right. converting floats to integer produces a
whole lot of code i couldn't figure out because i don't have a list of fp
instructions in at&t syntax but the sheer number of them suggests they take some
considerable time :) however, converting integer to float has no penalty at all
that i can see, meaning that :

unsigned long b,c;
float a;

a=(float)b*c;
is faster than
a=b*c; 

(the latter does a mul followed by a conversion to fp)

provided you can make sure the destination of the operation is a float and avoid
the translation back into integer, you appear to have saved some considerable
cycles (10 in the best case on a pentium and 4 at worst) extending the analogy to
integer division gives even better savings.

the weird world of floating point arithmetic :)

nik

In article <853780174 DOT 909237 AT araga DOT funcom DOT com>, kurt DOT skauen AT funcom DOT com (Kurt Skauen) writes:
|> 
|> gpt20 AT thor DOT cam DOT ac DOT uk (G.P. Tootell) wrote:
|> >i would be better writing - (and changing a to a float)
|> >
|> >a=1.0/b;	(because fdiv is still faster than idiv in most cases)
|> >c=(float)x*a;
|> >d=(float)y*a;
|> >
|> >ie. to change the integers into floating wherever possible to make use of the
|> >fmul timings, which outstrip every other timing even in worst case!
|> >
|> >
|> >so there must be a catch somewhere of course ;)
|> >perhaps the changing from float->int and vice versa takes a lot of time?
|> >anyone?
|> 
|> I don't have the excact numbers, but float to int, and int to float
|> conversions are supposed to be very slow. So normaly it is a good idea
|> to avoid them. But since the FPU can process one instruction in
|> parallel with the CPU (four on Cyrics I heard?), you can execute all
|> FPU instrucions on *ONE* cycle as long as you have enough integer
|> instructions to fill in between each FPU instruction.
|> 
|> Kurt. 	Programmer Funcom/R&D
|> The above expressions is not ment to represent Funcom.
|> 
|> 

--