> A posit processing unit takes less circuitry than an IEEE float FPU. With lower power use and smaller silicon footprint, the posit operations per second (POPS) supported by a chip can be significantly higher than the FLOPS using similar hardware resources.
The argument seems to be predicated on the cost associated with NaN-handling. The exposition comes across as somewhat arrogant, IMO:
> If a programmer finds the need for NaN values, it indicates the program is not yet finished, and the use of valids should be invoked as a sort of numerical debugging environment to find and eliminate possible sources of such outputs.
Meanwhile, from the article where people actually tried implementing this thing on an FPGA:
> They also found that the improved accuracy didn’t come at the cost of computation time, only a somewhat increased chip area and power consumption.
Posits have a variable size mantissa, and the largest mantissa for a given bit size (eg, 32 bit floats) is larger than the mantissa in the corresponding IEEE float. For example, in a 32 bit float, the IEEE mantissa is 23 bits, while the maximum size Posit mantissa is 27 bits. So a Posit FPU requires more mantissa bits than the IEEE FPU of the same bitsize, and this is why the Posit FPU will have a larger silicon footprint. IEEE needs a bit more silicon to manage all the special cases of IEEE logic, but apparently this is less than the extra transistors required for the Posit mantissa. (The extra cost for the mantissa is related to the better accuracy reported for posits.)
Gustafson's paper is old, and doesn't reflect the language of the recent Posit standard. He may have had a different silicon implementation in mind than what has been implemented. Gustafson says there is no NaN. But in the Posit standard, there is a single NaN-like value called NaR (Not a Real). In IEEE, 0/0 is NaN, while in Posit, 0/0 is NaR. The rules for NaN and NaR are different, so they have different names.
It's possible Gustafson's paper doesn't consider the scaling as you get to wider types, or the presence of NaR removes enough of the savings from killing off NaN that it's a wash.
I think Gustafson may be the kind of liar that doesn't know he is lying. He knows saying that his design improves upon power and die size sounds good, so he says it.
Nope, I have seen it tested on an fpga, many years ago. The reference was Berkeley hardfloat. This might not be the best implementation ever, but it is the most accessible open source one.
Where do you save transistors? With the Posit you have to be able to deal with larger mantissa, multiplier size scales with mantissa bits squared, so even a small increase makes quite a mark.
Maybe you save a bit by not having denormals, but then parsing the packed float is a bit more complicated in that the bits do not have a fixed division between exponent and mantissa.
It is possible that the Posit circuit was smaller by leaving out some feature, like exact rounding, which is quite expensive, but then it is not an apples-to-apples comparison.
you save transistors but not dealing with NaNs and Infs also. you also save some because your comparison operations just use signed integer comparison so you don't need hardware to do those. my guess is that when you combine these effects it could be a net win for 16 bit. also bigger multipliers might be slightly sub-quadratic by using karatsuba or similar.
The article links to the posit paper [0]:
> A posit processing unit takes less circuitry than an IEEE float FPU. With lower power use and smaller silicon footprint, the posit operations per second (POPS) supported by a chip can be significantly higher than the FLOPS using similar hardware resources.
The argument seems to be predicated on the cost associated with NaN-handling. The exposition comes across as somewhat arrogant, IMO:
> If a programmer finds the need for NaN values, it indicates the program is not yet finished, and the use of valids should be invoked as a sort of numerical debugging environment to find and eliminate possible sources of such outputs.
Meanwhile, from the article where people actually tried implementing this thing on an FPGA:
> They also found that the improved accuracy didn’t come at the cost of computation time, only a somewhat increased chip area and power consumption.
I wonder where the mismatch comes from.
[0] http://www.johngustafson.net/pdfs/BeatingFloatingPoint.pdf