What kind of representation for floats should be used?

[gabor]

Hi everyone!

I have a little question: what sort of float numbers should be used under what circumstances?
I know only a few about MMX and SSE and those things. I thought of FPU floats and also of fixed point numbers.
Please give your comments, pro and kontra.
Which are commonly used? Which are the fastest? What hardware is needed for each representations?
The possibilities I know:
- fix point: n bytes int, n bytes fraction. Could be 32-32 bits.
- FPU types



Greets, gábor

[Mirno]

Fixed point is done using integer instructions, think of it as an integer divided by 2^n.

The reason to use fixed point is speed, if your number is within a range that'll fit within a total of 32 bits it'll be very fast as you just use integer instructions. The final conversion is done using a shift (or an add & shift if you want to round).

The whole advantage of floating point is it's range is dynamic, where you sacrifice precision for range or vice-versa. Most of the time when you deal with very large numbers you don't care about smaller values (the national debt of the USA is over $7.5 trillion, you don't care so much about the cents). It is in fact the dynamic range that makes the hardware more expensive (in terms of gates & timing)!

Mirno

[Mark_Larson]

Hi everyone!

I have a little question: what sort of float numbers should be used under what circumstances?
I know only a few about MMX and SSE and those things. I thought of FPU floats and also of fixed point numbers.
Please give your comments, pro and kontra.
Which are commonly used? Which are the fastest? What hardware is needed for each representations?
The possibilities I know:
- fix point: n bytes int, n bytes fraction. Could be 32-32 bits.
- FPU types



Greets, gábor.  Fixed point math was really popular when the Pentium first came out because it's floating point unit blew chunks ( as well as earlier Intel processors not being that fast at floating point).  If I remember right the original Doom used fixed point math, because of that.  Now adays floating point is a lot faster, so usually it's rare that you want to sacrifice accuracy for a slight increase in speed.  I prefer using scalar SSE and scalar SSE2 over standard FPU.  On my P4 it's faster, and it's also easier to program.  That's why I posted that one tutorial on using it to do FPU stuff.

  Het Gabor :)  You

[raymond]

If you need maximum precision with the equivalent of up to 19 significant decimal digits and/or a range spanning 10^-4932 to 10^+4932, only the FPU can presently provide you with it.

Raymond

[gabor]

Hi ya folks!

I made a little research in this topic and I've found that as Mark posted there is no particular reason not to use FPU and float numbers...

So for me the winner is float.

Could someone give the rande for the real4,8 and 10 numbers? Are there any other floats for the FPU?


Greets, gábor

[raymond]

If you intend to use the FPU but know little or nothing about it, you may want to have a look at the following:

http://www.ray.masmcode.com/index.html#fputut

Raymond

[AeroASM]

LoL shameless self-promotion! (no insult intended)

I think it is better to use REAL8 and SSE2 because the FPU will probably be phased out in the next decade or two.

[gabor]

:))) The FPU will phase out in the next decade? Don't be so pessimistic! I am positive, that in the next few decades the whole computerlike joke lead by Intel will die out. It is really a joke, that they are doing everything to keep that old way of architecture. Pumping up the clock frequency and shrinking the circuits will definitly not be enough in the next few years. No they come with dual processors, maybe later three CPU, or like in PS3 a CPU a GPU and other 5-6 processors integrated...And we the end users are forced to buy them because of the slow and resource wasting softwares created nowdays, I don't want to name a company, but in opposite its name they are creating huge, say macro soft-wares...
Okay I made all my complaints :))

Viva parallel processing, viva RISC architecture and viva neuron modelling architectures!

:))

BTW: thanks for the post, very usefull!


Greets, gábor

[AeroASM]

:))) The FPU will phase out in the next decade? Don't be so pessimistic!

If you are pessimistic, you are never disappointed, and sometimes pleasantly surprised!

Look how long it took DOS to disappear. Even now, a decade since the first 32 bit operating system (win95), CPUs still start up in real mode.

[MichaelW]

But DOS hasn't disappeared. And I expect the ability to run FPU code to persist for at least 20 more years, for the same reason that real mode is still supported. Breaking a mountain of still-useful software would be bad business.

[AeroASM]

Breaking a mountain of still-useful software would be bad business.

No one uses DOS anymore. It disappeared with Win2000 and WinME.

It is hardly a mountain, if anything.

[gabor]

I think we could endlessly argue about such things, but the main problem is, that MS DOS and WIN has too much influence on computer buisness and to be downwards compatible (I don't really see why is this such important rule) the newest versions still suffer from the design and implementation problems made at the very first versions.

However a float is still a float, and when hardware or OS changes only we suffer the low lever programmers. But pease don't start to develope in JAVA, I mean only in JAVA...In my opinion it is allways good to know how things are really working.

Greets, gábor

[MichaelW]

Breaking a mountain of still-useful software would be bad business.

No one uses DOS anymore. It disappeared with Win2000 and WinME.

It is hardly a mountain, if anything.

I meant actual DOS, as in MS-DOS version 6.22 and below, not Windows 95/98 MS-DOS mode.

And there is a mountain of software in use that contains FPU code.

[AeroASM]

I could have sworn that Win95/98 dos mode was DOS.

Anyway, I am not saying that we should get rid of the FPU and nail all the existing software, I am merely saying that because SSE(2/3) is faster and better it needs to become the standard instead of the FPU. As you say, Intel cannot take it out until developers stop using the FPU and start using SSE. So we should do SSE instead of FPU, to help this.

[GregL]

One thing to keep in mind is that 64-bit Windows does not allow FPU or MMX code in 64-bit mode, only SSE/SSE2/SSE3. Which I think was a dumb decision, it's going to break a lot of code, but there must have been a good reason for it. It isn't a hardware limitation, just an OS limitation. From what I have read, 64-bit Linux allows FPU and MMX code in 64-bit mode.  ::)