3 ms·

I very commonly see fixed-point libs be slower than floating-point (assuming floating-point hardware is available --- soft-float is slow as hell compared to fix

I very commonly see fixed-point libs be slower than floating-point (assuming floating-point hardware is available --- soft-float is slow as hell compared to fixed-point, of course). Commonly enough that I think it's some fundamental reason (given available/current hardware as opposed to hypothetical). Two reasons I can think of, though granted, they only apply in certain niches: 1) Floating-point SIMD extensions are far more common than integer ones. This means you can compute N (often N=4 or 8) float operations in one instruction, vs 1 integer operation. 2) For any GPGPU processing: GPUs far prefer floats, to the point where you didn't even use to have integers available (somewhat ironically, the platforms that prefer float much more strongly to int are mobile/embedded ones nowadays --- which is the exact opposite of the CPU situation). To this day, you have a `mul24` intrinsic for integer multiplication in some languages ... which converts two integers to floats, multiplies them as floats, and then converts back to integers. Yes, that was faster than direct multiplication. I'm sure many GPUs do it directly nowadays though. It's also worth considering that a typical fixed-point multiply (as opposed to integer) is an integer multiply followed by a shift; often to a 2×-bit intermediate, if you want to preserve precision. That's a cost.

taeric 3mo ago
Apologies for not responding earlier. I am honestly fine with where this conversation ended and was worried about it never ending. That said, I also find it fun to discuss. :D Conflicting feelings! (To that end, fully understood if this is fully dropped, now.) I do not at all contest this. Would largely expect it. It is a common enough trap that people introduce complications to something expecting it to be faster. I do expect that the largest reason, in this case, is simply volume/network effects. More people lean on floats than on fixed decimal. Therefore, it is not that surprising that more optimization has happened there. This is exactly why I somewhat lament there is not more fixed point work out there. My assertion is if it was more standard, there would be more standard optimizations. For that last point, I would still expect you could pick constants more for multiplication so that you didn't have to do the shifts as often. Probably even preferring classes of numbers where if you have a set of X values that you often multiply with Y values, if you can limit yourself so that all Y values have no decimal part, X*Y is always just an integer multiplication. Now, I also fully grant that systems start to crash when someone didn't realize exactly why no Y values had a decimal. They decide they really need one, and then update the code with a massive performance hit that they didn't even pay attention to.

taeric 3mo ago

Apologies for not responding earlier. I am honestly fine with where this conversation ended and was worried about it never ending. That said, I also find it fun to discuss. :D Conflicting feelings! (To that end, fully understood if this is fully dropped, now.) I do not at all contest this. Would largely expect it. It is a common enough trap that people introduce complications to something expecting it to be faster. I do expect that the largest reason, in this case, is simply volume/network effects. More people lean on floats than on fixed decimal. Therefore, it is not that surprising that more optimization has happened there. This is exactly why I somewhat lament there is not more fixed point work out there. My assertion is if it was more standard, there would be more standard optimizations. For that last point, I would still expect you could pick constants more for multiplication so that you didn't have to do the shifts as often. Probably even preferring classes of numbers where if you have a set of X values that you often multiply with Y values, if you can limit yourself so that all Y values have no decimal part, X*Y is always just an integer multiplication. Now, I also fully grant that systems start to crash when someone didn't realize exactly why no Y values had a decimal. They decide they really need one, and then update the code with a massive performance hit that they didn't even pay attention to.