I just converted a big fixed point algorithm to float on Cortex-M4f. It runs very close to the same speed, but significantly more readable.
In the fixed code I used straight c but wrote functions for sin, cos, and reciprocal square root.
I can't see getting just a 2x improvement over soft float, while using llvm specific features and modifying libraries just eliminates portability.
Cortex-M4F has an FPU, i.e., hardware floating point support (albeit single precision only). You likely would see a much greater performance drop without it.
You can also use a library for it:
https://github.com/PetteriAimonen/libfixmath
I saw this getting forked for a custom SDK for the PS1 (which doesnt have a FPU).
That's a good library (I use it myself), but just to be clear for anyone reading: that's a standalone fixed-point implementation, not a compiler-provided one like the article discusses (via -ffixed-point).
What is the advantage of fixed point arithmetic over rational arithmetic? Rational arithmetic seems to include fixed point arithmetic as a subset (in fixed point arithmetic the denominator is always a power of the base).
Unless you allow the denominator to grow unbound, rational have no real advantage over FP and are much slower. If you allow unbound denominator, you will run out of memory after perhaps a few thousand operations (and having to dynamically allocate memory will kill performance even further). And then there are transcendent functions which cannot be represented by rationals anyway.
> And then there are transcendent functions which cannot be represented by rationals anyway.
They cannot be represented by floats either. So this doesn't matter.
The meaningful difference with irrational computations on rationals vs floats is that in floats you have some inherent, expected, and well-understood imprecision that applies evenly over results of add/mul/div/sqrt/sin/etc, whereas in unbounded rationals add/mul/div are all infinitely precise always (and presumably this property is why one would want rationals over floats) but has no such possible equivalent for sqrt/sin.
- after few operations denominator exceeds 64-bit range, so you either need bigint, or make fractions approximate, what is in affect fixed point
- often you use decimal fraction on output and input anyway
- it's slower, even slower with bigint
- no square root, sin, and so on with rationals
> no square root, sin, and so on with rationals
Are you thinking about a specific library? You aren't the only person who commented this way. But, the truth is that root, sin and so on don't "work" with floats either. In fact, there are common ways to implement these functions by either using tables (which are approximate) or algebraic approximations (that give you... drum roll: rationals!)
But, really, there isn't any way (except symbolically) to represent transcendental functions in computers. It doesn't matter what kind of number you choose to do it.
√2 with floating point is obviously closest representable number. With fixed point it is obviously closest representable number as well. With rationals, you need to arbitrarily limit precision, and the point of using rational was to use exact values.
As stated: rationals are more general purpose, hence more complicated.
It has to run on a computer. How would you simulate rational arithmetic?
Rational arithmetic represents numbers as a numerator and denominator (rational numbers). There are hundreds (at least) of libraries that implement rational arithmetic on a computer.
I meant run on the cpu itself. Most processors have floating-point support, and fixed-point just uses integer operations. All those heavy libraries require an arbitrary amount of memory for their calculations.
The article here is about hardware without native FP already; that said, rationals (even before getting to the need of bigints) are quite bad regardless, likely requiring division & gcd around basic arith, which are slow both in software and in hardware.
the Raku language https://raku.org defaults to bigint (Int)and rational (Rat) numerics since that gives fewer unexpected results with eg decimals (0.1+0.2==0.3) … it’s easy enough to reach for floating point (Num), but this is deliberately the non default so that you the coder need to know that is what you want to trade performance vs precision
all irrational operations (sqrt, sin, cos and so on) return Num in a consistent way
In most other languages, aren’t rationals “deliberately the non default so that you the coder need to know that ais what you want to trade precision vs performanc”?
My point being, your point doesn't actually make Raku sound like they made a good design decision, it’s just different for the sake of being different when put that way.
I'd say the best choice is correctness over performance. So bignums win.