🚀 go-pugleaf

In article <1991Apr13.154112.11345@dircon.co.uk> uad1077@dircon.co.uk (Ian Kemmish) writes:

[  stuff about using scaled ints stuffed into bit bucket  ]

>
>But don't get rid of floats completely.  If you can, parameterise the
>decision to use floats or scaled ints in a config file.  On mips
>systems, and with luck the civilised habit will spread, doing
>arithmetic in floats os considerably faster than doing it in
>integers (assuming its not something simple like a long run
>of adds and subtracts with just a couple of token multiplies and
>divides thrown in), which in turn is faster than arithmetic using
>shorts.  Scaled integers and shorts are slower, again.  I recently
>saw a preliminary copy of the JPEG sample implementation, and
>it suffered from this ``integer-centrism''....
>
>-- 
>Ian D. Kemmish                    Tel. +44 767 601 361
>18 Durham Close                   uad1077@dircon.UUCP
>Biggleswade                       ukc!dircon!uad1077
>Beds SG18 8HZ United Kingdom    uad1077@dircon.co.uk

  So, okay, I have a MIPS system.  No problem.  But what about us poor
programmers who can only afford a 386/387 system?  It is still faster to
use ints than floats, for two reasons:

	1.  On a 386, the longest a IDIV will take (this is with a memory
	    operand here) is 46 cycles.  And the longest an IMUL will take
	    is 41 cycles.  On the 387, the SHORTEST time it will take to
	    divide two reals is 91 cycles.  A floating point multiply takes
	    about the same as the IMUL instruction (depends on addressing
	    modes, though).  Drop down to a 286/287 combo, and the IMUL/IDIV
	    instructions take about 20-30 cycles, while the FMUL/FDIV take
	    about (for a FMUL) 130-170 or (for a FDIV) 190-230 cycles.  Shall
	    we go on to a 86/87 combo?

	2.  Do we REALLY need the ability to go from 1E-100 to 1E+100 in range
	    when doing graphics?  And what does it mean to add 1E-100 to 1E+100?


  For me, scaled ints are fine.

  -spc (Floats?  I don't need no stinking floats!  :-)