That's using a discrete Radeon HD 5800 series card, not just Llano. In fact if you watch the video you'll see that Llano only reaches 100 GFLOPS.
Because every conditional branch doubles your potential outcomes*, and you simply don't have that much memory bandwidth to spare.
No. Current x86 CPUs are not homogeneous, themselves. Vector processing bolted on to a scalar CPU is a perfect example of it. GPGPU is different, in that the very idea is to add TLP, but it is not conceptually different than vector extensions. What is truly novel about it is that it is coming from a dedicated graphics processor towards being a chunk of the CPU.
Without extending the language a great deal, how are you going to successfully auto-vectorize it? As it is, it's practically a miracle that compilers can automatically vectorize much of anything. We need the language to support vector processing, to make good use of it. Standard C++ does not have this, at least not to enough of a degree that you won't have to read your hardware optimization docs to make it useful (no more easy ARM SoC port). So, you'll either need to use a customized version (AMP, CUDA), or a whole other language, to make good use of the hardware.
Sure, strictly speaking it's a separate feature. But for Intel it will arrive at the same time as AVX2. And yes AMD supported it first, but what you're quoting is from a text explaining that between Nehalem and Haswell, Intel will have increased the peak throughput by a factor of four. AMD is irrelevant to that argument.
I said future architectures, not current ones.
How is where it came from relevant? Haswell will be capable of 2 x 256-bit FMA per core per cycle. This isn't fundamentally different from a Fermi GPU executing 2 x 512-bit, at a lower frequency.
Yes it's a miracle today, since there is no vector equivalent of each scalar instruction yet. AVX2 changes that, making auto-vectorization far more straightforward. There's no need to extend the language. Any loop with independent iterations is a candidate for running several of them in parallel on each SIMD lane.
True, but the SDE emulator is irrelevant to the discussion, which was clearly about the performance of physical processors.
Yes, but please don't ignore the context. Since AMD already has FMA, it didn't need mentioning. And I was obviously also talking about a high-performance implementation, not the 1 x 256-bit per two cores they have today.
That without that context, it wouldn't exist. The trappings of what it is derived from are largely what makes it special, and that if those are removed, the barrier is one of effectively telling the computer to do X in a massively-parallel fashion.
Exactly.
The bolded part is not so easy to prove with procedural code, and sane compilers will err on the side of not doing it. A compiler needs to come up with a positive proof that it is safe to do, which it can't do so easily as a human. The language having ways of telling it that is the case would be far more straight-forward. To be widely effective, the language needs a way for the independence of the processing to be defined at a high level. It won't take moving mountains to get the job done, but it will take people doing it now, and letting standards get worked out later.
AVX doesn't exist in C, C++ (standard), C#, Java, etc.. A compiler for such a language must, through very limited programmed-in means, verify that some loop's iterations can be processed in parallel, then figure out if it can come up with a way to do that with proprietary hardware extensions, again using fairly limited programmed-in methods. In other words, there are many cases where a loop could be unrolled, or even implemented by as a set of vector maths, but won't be. Any number of additions to the language could do it easier, and more effectively, leaving the compiler just the job of figuring how to do it, having been told that it can be done. If any one change can be adopted by multiple major players (MS and GCC easily being the most important), and people use it, everyone else pretty much follows by default, and it will become a standard in practice long before it becomes one officially. Being required to understand how the compiler's logic was implemented, and coerce it into doing it, is simply not going to catch on. It would be easier to do it manually.
Vector processors with multiple lanes have existed since at least 1982. So it's not something that was invented by GPU manufacturers. Also, x86 processors had SIMD instructions before gaphics chips were even programmable. So you can't conclude that AVX2 would not have existed without GPUs.
Then what were you trying to argue?
Proving that loop iterations are independent might not be "easy", but compiler optimizations never are. So that's not a very convincing argument. Compiler writers will go to great lengths to extract more performance. Especially for something that can make 8 iterations run in parallel there is lots of incentive to solve "hard" problems. Auto-vectorization is a hot topic among the LLVM developers, and the Polly project shows some phenomenal potential. Note that for C++ the strict aliasing assumption helps a great deal too to determine (non)dependencies.
Actually I guess the reason why they have AVX2 is they do not want SnB which has AVX unit supports FMA. And in order to make the new AVX in Haswell ,which has a "new function" compared to SnB called FMA, more attractive, they establish a new name for it.
I don't. I conclude that OpenCL, DirectCompute (HLSL/Cg, basically), CUDA, etc., came about due to GPUs, and that DX10.1+ GPUs are far more capable that most vector coprocessors. Yet, unfortunately for the GPU manufacturers (especially NVidia, in the long run), there is nothing keeping [mostly scalar] CPUs from doing the same work just as well, regardless of how they go about it.
AVX2 might not have restrictions, but again, it's not AVX2 that limits results, if the compiler must figure out what the programmer should be able to tell it: it's MSVC and GCC C++ implementations.
The original topic is silly. It's some academic research that will never be used in practice. Why? Because it shows a flaw in the GPGPU hardware. It should be solved in hardware, not software. It will take AMD till 2014 to complete its HSA architecture, so developers won't bother putting a lot of effort into squeezing 20% performance out of a chip that has no significant market share whatsoever.
All Chips supporting AVX2 will also support FMA, so let's not split things up unnecessarily. And it makes sense for Intel to implement them together considering that both the 256-bit integer instructions in AVX2, and FMA, demand doubling the bandwidth.
Actually on second thought the topic title is indeed misleading. Most people would expect it to be about graphics performance, not generic computing. 😵
Ok, it wasn't entirely clear to me that you agree about the hardware aspects.
I'm not ignoring the software infrastructure. It is critically important, but I don't see any obstacles. First of all, every API for GPGPU will get an AVX2 implementation in the short term. Intel and Apple are working on an LLVM-based implementation of OpenCL. And LLVM also supports PTX which is used by CUDA. Next, Microsoft's implementation of C++ AMP will definitely support AVX2 as well.
Auto-vectorization is just one of the options. And a very important one for those who desire the best gain versus effort ratio. If you do want to push the hardware to its limits, auto-vectorization is probably not the best option. But there are countless alternatives to choose from.
Huh? The engineers I've talked to who work on 3D content production on the CPU told me they expect gather to make a massive difference. Texture filtering with lots of taps, the implementation of transcendental functions using lookup tables, dynamic indexing into constant buffer, etc. If you're expecting to only see a 5% speedup from a gather instruction that's four times faster than scalar loads, that would mean only about 6.5% of all your current code would perform scalar loads. That seems awfully little.
But wouldn't that make scalar loads become more of a bottleneck? 😛
I'm curious what you need the generic permute for in 3D rendering. GPUs don't support any cross-lane operations as far as I know.
Do you have a target market of millions of people who have a CPU only capable of AVX1? And why would that be significant compared to the billions of people who don't have AVX support at all? In other words, would you lose important paying clients if you skipped AVX? I've heard it only improves performance by 30% in the best case while AVX2 has a lot more potential.
