5 ms·

To give it a different spin, an FPU required an external chip 20 or 30 years ago. Today you have processors smaller than a fingernail running a multi-GHz with p

To give it a different spin, an FPU required an external chip 20 or 30 years ago. Today you have processors smaller than a fingernail running a multi-GHz with pipelined FPU's. GPUs have so many FPUs (literally thousands) that their silicon footprint is quite large. Large SIMD FPUs, like those in the Sandy Bridge, are also large and power-hungry, so much that Intel actually has an (undocumented) feature where the Sandy Bridge powers down half of of the FPU if it hasn't been used recently. With regard to the importance of accuracy, even Intel realizes the importance of being able to improve power and performance with lower-accuracy FP calculations: see for example their demo hardware here: http://www.theregister.co.uk/2012/02/19/intel_isscc_ntv_digital_radio/ http://www.theregister.co.uk/2012/02/19/intel_isscc_ntv_digi... . "The FP unit can do 6-bit, 12-bit, and 24-bit precision and, by being smart about doing the math, it can cut energy consumption by as much as 50 per cent and - perhaps more importantly - you can do the math a lot faster because you only operate on the bits you need and don't stuff registers and do calculations on a lot of useless zeros."

robomartin 15y ago
Sure. Makes sense. The question really is about whether or not some of these applications can tolerate errors in the order of 1%. I contend that those application are few and far between, particularly in this day and age. People don't want to go backwards. For example, I can do photorealistic rendering of mechanical models from Solidworks. A 1% error in the output of these calculations would not be acceptable. The quality of the images would not be the same. Play with this in Photoshop and see what 1 1% error means to images. I would have zero interest in a graphics card that ran faster, used less power but offered a 1% error in calculations. That's an instant deal breaker. I can see the competitors' marketing: "Buy the other brand if you want 1% errors". Does a radiologist care about the processing of an MRI happening faster? Sure. Can he/she tolerate a 1% error in the resulting images? Probably not. He probably wants more detail and resolution rather than less. I wouldn't want him/her to be evaluating MRI's with a baked-in 1% error. I think it is ridiculous to think that this sort of thing is actually useful outside of a very narrow field within which errors would be OK. I'm still waiting for someone to rattle-off 100 to 1,000 applications where this would be actually acceptable. Without that it is nothing more than a fun lab experiment with lots of funding to burn but no real-world utility. Let's check in ten years and see where it's gone.
- DarkShikari 15y ago
  Sure. Makes sense. The question really is about whether or not some of these applications can tolerate errors in the order of 1%. I think the idea here is threefold: 1. The vast majority of computations do not need extremely high precision. A billion times more floating-point operations go into rendering video for games every day than for MRI processing (made-up statistic). Even now, we have double-precision floating point for this reason: most operations only need single-precision. 2. Applications that need a particular level of precision can be written with that level of precision in mind. If you know the ability of a particular operation to provide precision, and you are aware of the numerical properties of your algorithms, you can write faster code that is nevertheless still as accurate as necessary. Most of this isn't done by normal programmers, but rather by numerical libraries and such. 3. Many performance-intensive applications already use 16-bit floating point, even though it has very little native support in modern CPUs. AAC Main Profile even mandates its use in the specification. The world is not new to lower-precision floating point, and it has gained adoption despite its lack of hardware support on the most popular CPUs. The entire idea that this is "let's make ordinary computations less accurate" is a complete straw man and red herring that nobody actually suggested.

robomartin 15y ago

Sure. Makes sense. The question really is about whether or not some of these applications can tolerate errors in the order of 1%. I contend that those application are few and far between, particularly in this day and age. People don't want to go backwards. For example, I can do photorealistic rendering of mechanical models from Solidworks. A 1% error in the output of these calculations would not be acceptable. The quality of the images would not be the same. Play with this in Photoshop and see what 1 1% error means to images. I would have zero interest in a graphics card that ran faster, used less power but offered a 1% error in calculations. That's an instant deal breaker. I can see the competitors' marketing: "Buy the other brand if you want 1% errors". Does a radiologist care about the processing of an MRI happening faster? Sure. Can he/she tolerate a 1% error in the resulting images? Probably not. He probably wants more detail and resolution rather than less. I wouldn't want him/her to be evaluating MRI's with a baked-in 1% error. I think it is ridiculous to think that this sort of thing is actually useful outside of a very narrow field within which errors would be OK. I'm still waiting for someone to rattle-off 100 to 1,000 applications where this would be actually acceptable. Without that it is nothing more than a fun lab experiment with lots of funding to burn but no real-world utility. Let's check in ten years and see where it's gone.

DarkShikari 15y ago
Sure. Makes sense. The question really is about whether or not some of these applications can tolerate errors in the order of 1%. I think the idea here is threefold: 1. The vast majority of computations do not need extremely high precision. A billion times more floating-point operations go into rendering video for games every day than for MRI processing (made-up statistic). Even now, we have double-precision floating point for this reason: most operations only need single-precision. 2. Applications that need a particular level of precision can be written with that level of precision in mind. If you know the ability of a particular operation to provide precision, and you are aware of the numerical properties of your algorithms, you can write faster code that is nevertheless still as accurate as necessary. Most of this isn't done by normal programmers, but rather by numerical libraries and such. 3. Many performance-intensive applications already use 16-bit floating point, even though it has very little native support in modern CPUs. AAC Main Profile even mandates its use in the specification. The world is not new to lower-precision floating point, and it has gained adoption despite its lack of hardware support on the most popular CPUs. The entire idea that this is "let's make ordinary computations less accurate" is a complete straw man and red herring that nobody actually suggested.