For this particular optimization, it looks better not to have it.
But in general, knowing how something is flawed lets you mitigate the flaws. We use floating point despite it being mathematically wrong, because it's fast and we can mitigate the wrongness. I could imagine a chip where speculation could be toggled between different modes, if there was enough demand.
I will say that "just further behind" is probably wrong. AMD has a lot of optimizations in their chips. They have safer ones, which might be luck or might be engineering talent, but it's not a mere artifact of being behind the curve.
This makes no sense at all. The differences that you're seeing fall within the spec. You're basically saying that Intel is justified in crippling AMD CPUs if AMD's floating point instructions doesn't implement Intel's out-of-spec quirks as well. This is a flimsy argument, the FUD that Intel has been propagating for years now, and I'm not sure why you keep on pushing the Intel FUD so hard again and again.
There is basically nothing which guarantees that the numerical errors that are within the error tolerance of the spec won't change in new iterations of Intel CPUs either.
If the correctness of your calculation depends on the values of the unspecified within the spec, this means you need to change the code to a more stable algorithm or use higher precision floats anyway.
No. AMD has worse floating point performance, and has poor support for half precision floating point values. Also gets beat on power consumption per flop.
Thats because AMD basically bet the farm on the GPU replacing the FPU for doing floating point math, but never got any real traction for it on the OS level.
This article was about improving floating point performance in general, they just used the benchmark as a benchmark. What correctness are you talking about here? The fact that floats are no longer being promoted to doubles for some operations? It's pretty unnecessary for most things, especially for a game engine.
This sort of floating-point optimization, while admittedly quite imprecise, actually does still see plenty of application in high performance, framerate-critical gaming. Especially games with require a robust physics package (my previous employment was at a now-defunct maker of hardware-accelerated physics products). For these gaming applications, or specifically for the graphics drivers they depend on, you're coding multi-threaded routines in proprietary instruction sets that run on a GPU, which is becoming more and more like a parallel vector processor.
It's quite clearly decimal floats, with instant trapping instead of bad values.
IMO, with the sheer amount of silicon modern processors use for incredibly specialized gains, there's no reason our computers should be specialized for scientific computations when they could support daily computations too.
You obviously do not want decimals on your GPU, but the choice on the CPU is out of wack.
I think you are significantly underestimate the prevalence of floating point calculations, there is a reason why Intel and AMD created all the special simd instructions. Multimedia is a big user for example. You also seriously underestimate the performance cost of using decimal types, we are talking orders of magnitude.
I would be interested to hear about the difference in floating point performance. I would have guessed that, at this point, pretty much every chip designer in the world knows equally well how to make a floating-point multiplier. So it must be that nvidia vs amd have made different trade-offs in when it comes to caching memory near the FP registers or some such thing?
It took a long time for GPU's to get double precision floating point and plenty of GPGPU work was done with them prior to that, so it's not a deal breaker
Not sure if world first or AMD's first, but it was around this timeframe, 2007:
"AMD Delivers First Stream Processor with Double Precision Floating Point Technology"
http://phys.org/news113757140.html
It wouldn't be useful anymore, that was 3-4 years ago. At the time besides having AMD issues we had floating point optimization issues which messed up our physics. I doubt it's an issue today.
At first glance, this seems like such an extreme opinion that my curiosity is piqued.
What do you want to see with fast decimals, what does that mean to you, in terms of hardware implementations? Do you think financial applications are more important in the hardware and software markets than simulations? ("Simulations", btw, includes all video games.)
I'd like to give your suggestion the benefit of the doubt, that the "only" place floating point is necessary is in simulations and that GPUs could handle all floating point needs, but my gut reaction is that this is wildly out of touch with how often programs use floats. I might be wrong here, that's just my first thought.
IIRC, GPUs across different devices often don't guarantee the level of precision you might need. Not to mention, getting data in and out, and using non built-in math functions, are both a pain.
Depending on what kind of display or device or medium you're using, 2D layouts using floating point routinely. Most mobile devices now come in non 1:1 device pixel ratio. You have to use floating point to get pixel accurate layouts. Almost all vector art (SVG, PDF, etc) and almost all animation (CSS, Movie editing) use floating point heavily.
"Data processing" - I dunno what that means, but a lot of the "data processing" I've done used floats or doubles or higher. Anything with computer vision in it will often use floating point; think about the rise of fingerprint and facial recognition.
A long time ago, desktop CPUs used to come without floating point support, and everyone wanted it and paid for it, so now we have it. Granted that was before GPUs, but I'm curious if Intel would even entertain the idea of a general purpose desktop CPU without floating point support.
My point about floating point numbers having no advantages other than speed and memory usage was referring to the following: Some people think that you can decide equality of floating point numbers, while you can't decide equality of real numbers, but this advantage is an illusion because rounding errors can make numbers that should equal each other not equal each other. So ultimately it ends up being a pure efficiency vs accuracy trade-off, where efficiency includes things like speed and memory, and of course that could make it impractical in an embedded setting. I can't list out every single disadvantage of something being slower and less space-efficient, including in your pet interest, which is embedded programming. Is that not politically correct?
And ultimately, I'm interested in beautiful things as well as practical things. I fully acknowledged that the idea here is impractical, though theoretically possible, with some very interesting theorems coming out of it. I don't want to always think like a hard-nosed practitioner. That's stupidly dogmatic.
[edit]
Const-me is complaining that I didn't mention his pet interest, which is GPGPU. And then he said some totally irrelevant and obvious stuff (to anyone who knows CS), just like you did. This is why we can't have nice things.
Not to defend Intel because I think Intel has become a Ship of Fools With a lot of money, but AMD has FP24, Nvidia has FP16 and Google has TPU 2 with an FP16 implementation so proprietary they can't talk about it. I think the valid concern here is that if this doesn't take off immediately they will end-of-life it and not so much the floating point format.
Despite what the article says, if you're using floating point numbers you're already using sloppy arithmetic. That's not just a sarcastic point, it's actually important; given that you're already not being precise it isn't necessarily surprising that you can trade away even more precision for speed, rather than it being some sort of binary yea/nay proposition that cracks numeric algorithms wide open.
"Off by 1% or so" leads me to guess it is implemented by using 8-bit numbers, and not necessarily with any particular sloppiness added by the chips, just the fact that the precision is small. Visual and audio processing could be set up in such a way that you wouldn't overflow those numbers because you know precisely what's coming in. You'd have to be careful about overflow and underflow but, per my first paragraph, you already have to be careful about that. It also makes sense in such apps that silicon would be more profitably used computing more significant bits more often rather than dithering about getting the bits in the 2^-50 absolutely precisely correct, a good insight. I don't know if that's what they're doing because it's hard to reverse engineer back through a science journalist but "8 bit math processors in quantity" -> "science journalist" -> "this article" is at least plausible.
As a matter of fact, AMD GPUs are using the floating point ALUs to perform integer math (note: this might have changed with their GCN architecture). However, given that the mantissa of IEEE floats is just 24 bits long, the ALU also can just handle 24 bits, which is not sufficient for full 32 bit math. Hence, for "true" integer arithmetic, the ALUs need to be double-pumped or emulated via floats (i.e. the dirty tricks which we avoided need to be done in the driver instead - but at this stage it can actually be done reliably, even if it's still ugly).
I assume the situation is similar for Nvidia GPUs. Either way both vendors said their GPUs aren't designed for optimal integer performance - so that's why we expect the performance drawbacks of integer usage to become less and less of an issue in the future.
Counter argument: Always enable fast-math unless your application has a demonstrable need for deterministically consistent floating point math. If you're just trying to get a "good enough" calculation (which is the vast majority of floating point work, physics and rendering calculations for 3D graphics), there's no reason to leave the performance on the floor.
I find that floating point story hard to swallow. It looks like they went "huh, this CPU benchmarks roughly as fast as the others, but we find it slow in practice. Only floating point benchmarks lag behind the competition, so that must be why!".
Floating point instruction are rarely used in common software. They're important in rendering (which is offloaded to a GPU in this case) or scientific computing (which is irrelevant here, unless you were planning to fold genomes on your watch).
It's possible that this OMAP came without an FPU to save space and power.
Most Linux software for ARM is compiled with softfloat anyway, because it rarely matters for end users, and lots of ARM boards don't have an FPU. Some distributions have a separate armhf version, which does use hardware floating point operations.
For this particular optimization, it looks better not to have it.
But in general, knowing how something is flawed lets you mitigate the flaws. We use floating point despite it being mathematically wrong, because it's fast and we can mitigate the wrongness. I could imagine a chip where speculation could be toggled between different modes, if there was enough demand.
I will say that "just further behind" is probably wrong. AMD has a lot of optimizations in their chips. They have safer ones, which might be luck or might be engineering talent, but it's not a mere artifact of being behind the curve.
reply