Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Fixed Point Arithmetic

vha3.github.io

Post reply on HN
Print view View original

31–40 of 61 posts

Re: Fixed Point Arithmetic

#31

Post by dreamcompiler »

benhoyt wrote: post #16

I know fixed point was very important back in the days when CPUs didn't have dedicated floating point instructions. How important is it now, when most common CPUs have fast floating point operations? Is there still a performance win? Do games and similar software use them today?

Several years ago I wrote a signal-processing kernel module for realtime interrupt handling in Linux. Surprise! You cannot do floating point in the kernel. So I wrote it all in fixed point.

ISTR the reason you couldn't use floats in the kernel had more to do with context switching and the kernel not spilling the FP registers than speed per se, but I might be misremembering.

Edit: Looks like I remembered it basically right:

https://stackoverflow.com/questions/13886338/use-of-floating...

Re: Fixed Point Arithmetic

#32

Post by cmroanirgo »

benhoyt wrote: post #26
whateveracct wrote: post #21

Earlier quoted context omitted.

The main appeal of fixed point nowadays is determinism across hardware - so networked games benefit, for instance.

Interesting. Are IEEE-specified floating point operations not deterministic?

That's my question too.

I wrote a multiplayer strategy game back in mid 90's issuing floating point and it was deterministic. No problems. Maybe chip optimizations have affected this?

We looked at fixed point, but with careful scheduling we'd get zero fpu (x87) stalls for float operations, so it wasn't a real win to go fixed. And it gave us the benefit of having more registers to use without needing to use the main stack as much, which also made the asm easier to read.

Edit: typos

Re: Fixed Point Arithmetic

#33

Post by corysama »

chas wrote: post #25
benhoyt wrote: post #16

I know fixed point was very important back in the days when CPUs didn't have dedicated floating point instructions. How important is it now, when most common CPUs have fast floating point operations? Is there still a performance win? Do games and similar software use them today?

Integer arithmetic is still simpler to implement in hardware and therefore faster than floating point arithmetic, so it is still heavily used for resource-constrained numerical programs. This shows up in signal processing code for e.g. very low-level network software, radios, and image processing. It is also popular for running efficient neural net inference. In neural nets, it is usually paired with reduced precisio…

At least as far as int32 vs float32 goes, surprisingly float is easier to make fast in the hardware. This is because floats are composed of multiple sections that can be processed in parallel whereas all of the bits of and integer addition, for example, have a serial dependency.

Re: Fixed Point Arithmetic

#34

Post by codr7 »

benhoyt wrote: post #16

I know fixed point was very important back in the days when CPUs didn't have dedicated floating point instructions. How important is it now, when most common CPUs have fast floating point operations? Is there still a performance win? Do games and similar software use them today?

It's not all about performance; fixpoints are consistent and predictable, which is very much not true of floats.

We should all be grateful that most banks still run Cobol, which has native fixpoint support for good reasons.

Re: Fixed Point Arithmetic

#35

Post by emacs28 »

benhoyt wrote: post #26
whateveracct wrote: post #21

Earlier quoted context omitted.

The main appeal of fixed point nowadays is determinism across hardware - so networked games benefit, for instance.

Interesting. Are IEEE-specified floating point operations not deterministic?

Floating point is deterministic, but it has limited precision, which introduces arithmetic errors depending on the specific values of the data. For example with full precision fp do: a = 2^25; b = 1; c = a+b; and you will just get c = 2^25. This is because there are 24 bits of precision but the +1 is 25 bits away from the most significant bit when representing 2^25+1 in binary, so the 1 gets lost in the fp representation.

Re: Fixed Point Arithmetic

#36

Post by justshowpost »

benhoyt wrote: post #16

I know fixed point was very important back in the days when CPUs didn't have dedicated floating point instructions. How important is it now, when most common CPUs have fast floating point operations? Is there still a performance win? Do games and similar software use them today?

> fixed point was very important back in the days when CPUs didn't have dedicated floating point instructions

That's a misconception, before widespread dedicated hardware (eg on-chip 80x87) there was software-emulated floating point arithmetic (eg Microsoft Binary Format) for general use. In contrast, fixed point solutions are very narrow purposed, that is, you choose a specific binary representation format so your specific range of values would fit with acceptable precision.

Re: Fixed Point Arithmetic

#37

Post by tuatoru »

benhoyt wrote: post #16

I know fixed point was very important back in the days when CPUs didn't have dedicated floating point instructions. How important is it now, when most common CPUs have fast floating point operations? Is there still a performance win? Do games and similar software use them today?

> I know fixed point was very important back in the day

So you don't care if your bank account is out by a percent or two?

Well, others do.

Re: Fixed Point Arithmetic

#38

Post by anonymoushn »

benhoyt wrote: post #16

I know fixed point was very important back in the days when CPUs didn't have dedicated floating point instructions. How important is it now, when most common CPUs have fast floating point operations? Is there still a performance win? Do games and similar software use them today?

Games that need to do dead reckoning and arrive at the same result on multiple computers either use fixed point or contain bugs. For example, almost every fighting game works this way. Early in the development of one fighting game I advised the lead developer to use integers for all parts of the game state, and he did not. Later, when testing the Switch port of the game, he was forced to switch to integers everywhere.

Re: Fixed Point Arithmetic

#39

Post by anonymoushn »

cmroanirgo wrote: post #32
benhoyt wrote: post #26

Earlier quoted context omitted.

Interesting. Are IEEE-specified floating point operations not deterministic?

That's my question too. I wrote a multiplayer strategy game back in mid 90's issuing floating point and it was deterministic. No problems. Maybe chip optimizations have affected this? We looked at fixed point, but with careful scheduling we'd get zero fpu (x87) stalls for float operations, so it wasn't a real win to go fixed. And it gave us the benefit of having more registers to use without needing to use the main s…

Your compiler or runtime might reorder operations, different machines might have DAZ and FTZ set differently, some CPUs might helpfully offer you a bunch of extra bits of precision while others do not

Re: Fixed Point Arithmetic

#40

Post by newpavlov »

cmroanirgo wrote: post #32
benhoyt wrote: post #26

Earlier quoted context omitted.

Interesting. Are IEEE-specified floating point operations not deterministic?

That's my question too. I wrote a multiplayer strategy game back in mid 90's issuing floating point and it was deterministic. No problems. Maybe chip optimizations have affected this? We looked at fixed point, but with careful scheduling we'd get zero fpu (x87) stalls for float operations, so it wasn't a real win to go fixed. And it gave us the benefit of having more registers to use without needing to use the main s…

Achieving reliable reproducibility for floating point calculations is... difficult, to say the least. There are minor differences between hardware (x87 vs SSE is the most famous one, but there are others). Changing compiler, its version or options may produce subtly different results (the most obvious example is the -ffast-math flag). And even the bigger problem is implementation of non-primitive (e.g. trigonometric) functions. Usually your program will use implementation from a system or vendor library, which probably have different underlying implementations.
Post reply on HN