3 ms·

I doubt it. It fails for far too many useful programming situations that it would cause more problems than floating point. Cannot use it efficiently for nearly

I doubt it. It fails for far too many useful programming situations that it would cause more problems than floating point. Cannot use it efficiently for nearly anything: finance software, science software, engineering software, high quality graphics software... 3d software, pretty much anything that has any range needed or ability to lower errors while doing accumulation of information. This is exactly why floating point was invented and standardized - fixed point is a failure for most any program, and only can work with much effort only for certain situations. (I've written tons of fixed point code, numerical libraries across the spectrum from high performance, high quality, tunable quality, arbitrary precision libs, posits and unums, IEEE half-float software implementations, and more, so I do know what I'm talking about).

jerf 2y ago
Is there even any performance benefit on modern CPUs? I tried to consult some real tables but I'm not experienced enough to be sure I'm reading them correctly. If I'm reading something like [1] properly, it looks like it is not a clear win on modern hardware to use fixed point & integer operations. It would depend on the ratio of addition/subtraction/multiplication to division. (Obviously one must factor out a lot of local considerations, which modern CPUs are full unto overflowing with; I'm kind of looking at a very, very broad average performance question across code bases doing enough different math operations to average out, not whether one particular loop can run theoretically run faster or slower with one or the other.) [1]: https://stackoverflow.com/questions/2550281/floating-point-vs-integer-calculations-on-modern-hardware https://stackoverflow.com/questions/2550281/floating-point-v...
- ooterness 2y ago
  It depends a lot on CPU architecture. Floating point units may be tied to each core, or they may be shared, so it may further depend on other concurrent workloads. There's also SIMD instructions. Modern CPUs have built-in instructions for handling multiple ints or floats as a vector. If you can get your fixed-point varies to for into 8-bit or 16-bit fields instead of 32, then the same sized vector units can handle more values per instruction.
- taeric 2y ago
  My gut would be that you also get some benefit by some auxiliary choices. With a lot of precomputed constants, you can probably avoid a lot of known multiplications. That said, yeah, if you have to start doing a lot of fixed point multiplications, you could eat any savings you had.
- ack_complete 2y ago
  Address calculations are a place where fixed point can still have an advantage -- it's often less latency and fewer ops to step a fixed-point accumulator and shift it into an address offset on the integer units than to step a floating point accumulator, convert it to integer, then move that over from the FP/vector units to the integer units.
thequux 2y ago
You might be surprised at where fixed point is already used: * Finance software: if you're using floats, you're doing something horribly wrong. All balances are measured in integer multiples of some quantum; depending on the system, that may be cents, it may be 0.1 cents, or it may be 0.01 cents. Gradations finer than that simply do not exist, and integer overflow is both more likely to be noticed and more easily explained to be a bug than precision loss (and this matters when you have a regulator asking uncomfortable questions) * CAD software: floating point may make sense for simulations, but at least for PCB design, layout is done in fixed point. You need consistent precision across the board, and avoiding edge cases in your geometry kernel from precision issues makes everything much easier. Besides, with a 1µm quantum, 32-bit numbers are sufficient for a board 4km on a side. If you need larger, I would love to see your fab. * Robotics: maybe this one's just me, but expressing motion control algorithms in fixed point has saved me €1/part on more than a few occasions as a result of being able to use an MCU without hardware floating point. Compared to the €0.20/part saved by muntzing the rest of the circuit, the small amount of additional work was totally worth it. Indeed, the tools for working with fixed point aren't great. C is a lost cause; the best you can do is name your variables things like velocity_12_4 and manually check that the precision lines up. Rust wasn't great when I tried, though const generics may have resulted in an improvement. C++ was, astonishingly enough, quite good; I made a header-only fixedpoint.h with a templated struct `fixed<type,size,precision>` and all inline operations. I get the impression that Ada would be even better, but I've yet to use it in anger.
- edflsafoiewq 2y ago
  The most common place is probably image/audio processing. Sample values are usually always quantized, even in intermediate stages. Decoding a JPEG for example is a bunch of fixed point math.
  - SideQuark 2y ago
    Professional tools even for audio use floating point engines (Ableton has done this for well over a decade [1]). While fixed point may be ok for input/output formats, it is certainly not suitable for complex audio processing needs, where errors accumulate far too fast for any fixed point system at equivalent bit depth. And fixed point is an order of magnitude slower. > Decoding a JPEG for example is a bunch of fixed point math It can be done that way, but modern decoders use float for accuracy and speed when available. Search libjpeg-turbo [2] codebase for float and surprise yourself. Even the ancient libjpeg [3] uses float when possible. Why not simply used fixed-point? Because it's worse in nearly every way, and an artifact of computing from the 1970s-1980s when JPEG pieces were designed (DCT, lots of work culminating in the final JPEG spec in 1992). When JPEG was designed, computers generally didn't have floating-point hardware. The world of computing has changed a bit since then. [1] https://cdn-resources.ableton.com/80bA26cPQ1hEJDFjpUKntxfqdmG3ZykO/static/manual/pdf/L9Manual_EN.0f97a0bd6041.pdf https://cdn-resources.ableton.com/80bA26cPQ1hEJDFjpUKntxfqdm... [2] https://github.com/libjpeg-turbo/libjpeg-turbo https://github.com/libjpeg-turbo/libjpeg-turbo [3] https://www.ijg.org/files/ https://www.ijg.org/files/

jerf 2y ago

Is there even any performance benefit on modern CPUs? I tried to consult some real tables but I'm not experienced enough to be sure I'm reading them correctly. If I'm reading something like [1] properly, it looks like it is not a clear win on modern hardware to use fixed point & integer operations. It would depend on the ratio of addition/subtraction/multiplication to division. (Obviously one must factor out a lot of local considerations, which modern CPUs are full unto overflowing with; I'm kind of looking at a very, very broad average performance question across code bases doing enough different math operations to average out, not whether one particular loop can run theoretically run faster or slower with one or the other.) [1]: https://stackoverflow.com/questions/2550281/floating-point-vs-integer-calculations-on-modern-hardware https://stackoverflow.com/questions/2550281/floating-point-v...

ooterness 2y ago
It depends a lot on CPU architecture. Floating point units may be tied to each core, or they may be shared, so it may further depend on other concurrent workloads. There's also SIMD instructions. Modern CPUs have built-in instructions for handling multiple ints or floats as a vector. If you can get your fixed-point varies to for into 8-bit or 16-bit fields instead of 32, then the same sized vector units can handle more values per instruction.
taeric 2y ago
My gut would be that you also get some benefit by some auxiliary choices. With a lot of precomputed constants, you can probably avoid a lot of known multiplications. That said, yeah, if you have to start doing a lot of fixed point multiplications, you could eat any savings you had.
ack_complete 2y ago
Address calculations are a place where fixed point can still have an advantage -- it's often less latency and fewer ops to step a fixed-point accumulator and shift it into an address offset on the integer units than to step a floating point accumulator, convert it to integer, then move that over from the FP/vector units to the integer units.

thequux 2y ago

You might be surprised at where fixed point is already used: * Finance software: if you're using floats, you're doing something horribly wrong. All balances are measured in integer multiples of some quantum; depending on the system, that may be cents, it may be 0.1 cents, or it may be 0.01 cents. Gradations finer than that simply do not exist, and integer overflow is both more likely to be noticed and more easily explained to be a bug than precision loss (and this matters when you have a regulator asking uncomfortable questions) * CAD software: floating point may make sense for simulations, but at least for PCB design, layout is done in fixed point. You need consistent precision across the board, and avoiding edge cases in your geometry kernel from precision issues makes everything much easier. Besides, with a 1µm quantum, 32-bit numbers are sufficient for a board 4km on a side. If you need larger, I would love to see your fab. * Robotics: maybe this one's just me, but expressing motion control algorithms in fixed point has saved me €1/part on more than a few occasions as a result of being able to use an MCU without hardware floating point. Compared to the €0.20/part saved by muntzing the rest of the circuit, the small amount of additional work was totally worth it. Indeed, the tools for working with fixed point aren't great. C is a lost cause; the best you can do is name your variables things like velocity_12_4 and manually check that the precision lines up. Rust wasn't great when I tried, though const generics may have resulted in an improvement. C++ was, astonishingly enough, quite good; I made a header-only fixedpoint.h with a templated struct `fixed<type,size,precision>` and all inline operations. I get the impression that Ada would be even better, but I've yet to use it in anger.

edflsafoiewq 2y ago
The most common place is probably image/audio processing. Sample values are usually always quantized, even in intermediate stages. Decoding a JPEG for example is a bunch of fixed point math.
- SideQuark 2y ago
  Professional tools even for audio use floating point engines (Ableton has done this for well over a decade [1]). While fixed point may be ok for input/output formats, it is certainly not suitable for complex audio processing needs, where errors accumulate far too fast for any fixed point system at equivalent bit depth. And fixed point is an order of magnitude slower. > Decoding a JPEG for example is a bunch of fixed point math It can be done that way, but modern decoders use float for accuracy and speed when available. Search libjpeg-turbo [2] codebase for float and surprise yourself. Even the ancient libjpeg [3] uses float when possible. Why not simply used fixed-point? Because it's worse in nearly every way, and an artifact of computing from the 1970s-1980s when JPEG pieces were designed (DCT, lots of work culminating in the final JPEG spec in 1992). When JPEG was designed, computers generally didn't have floating-point hardware. The world of computing has changed a bit since then. [1] https://cdn-resources.ableton.com/80bA26cPQ1hEJDFjpUKntxfqdmG3ZykO/static/manual/pdf/L9Manual_EN.0f97a0bd6041.pdf https://cdn-resources.ableton.com/80bA26cPQ1hEJDFjpUKntxfqdm... [2] https://github.com/libjpeg-turbo/libjpeg-turbo https://github.com/libjpeg-turbo/libjpeg-turbo [3] https://www.ijg.org/files/ https://www.ijg.org/files/