Hacker News Reader

Comment by abainbridge | Hacker News Reader

Efficient fixed-point arithmetic requires hardware support.

"Some DSP architectures offer native support for specific fixed-point formats, for example signed n-bit numbers with n−1 fraction bits (whose values may range between −1 and almost +1). The support may include a multiply instruction that includes renormalization—the scaling conversion of the product from 2n−2 to n−1 fraction bits.[citation needed] If the CPU does not provide that feature, the programmer must save the product in a large enough register or temporary variable, and code the renormalization explicitly."

From: https://en.wikipedia.org/wiki/Fixed-point_arithmetic#Hardwar...

View on HN

The most valuable thing here is the renormalization on multiply, but even that's not actually much.

Take the Analog Devices Blackfin range, if you want fixed point, which you're welcome to, they want you to use 1.15, so that's a 16-bit two's complement value between -32768/32768 and +32767/32768. Additions and subtractions are the same as integer maths, we're adding fractions but the adder doesn't care.

For the multiply, we're doing the same operation, 16-bit x 16-bit = 32-bit, but we can shift away the left bit and then snap off the bottom 16-bits to get another 1.15 fixed point value.

If you want this sort of fixed point type, lack of "hardware support" is not what's holding you back, nothing remotely modern would struggle to perform that shift operation on general purpose hardware.

How can we quantify "not actually much"? Here's my attempt for multiply:

You'd have to do a imul instruction followed by a right shift. On, say, Ice Lake, the imul has a reciprocal throughput of 1 and a latency of 3. The shift has RT of 0.5 and a latency of 1.

So compared to regular integer multiply, a fixed-point implementation on Ice Lake would be 0.67x the speed if you were throughput bound and 0.75x the speed if you were latency bound.

But most (all?) other operations wouldn't be any slower than regular integer operations, so a real program would slow down by less than the figures calculated above.

Reply on news.ycombinator.com