The limitation is that every thread on a core is executing the same instruction. If some of them take one branch and the rest take another, both branches have to be executed one after the other while masking out the threads it doesn't apply to. That reduces the performance you get, but it's certainly possible.
It's also worth pointing out that GPUs these days have a number of independent cores, each of which can execute different instructions simultaneously.
Hope that clears it up for you.
> The limitation is that every thread on a core is
> executing the same instruction. If some of them take
> one branch and the rest take another, both branches
> have to be executed one after the other while masking
> out the threads it doesn't apply to.
> That reduces the performance you get
In many non-trivial situations you need to check for reaching limits on loops or plain data structure bounds check.
Don't get me wrong, I think it's amazing to do GPGPU, what pisses me off is the overblown marketing and all the noise by people repeating that like canon when they clearly never implemented a single non-trivial program in OpenMP/CUDA/OpenCL/SIMD.
> Hope that clears it up for you.
This doesn't sound correct to me, but perhaps I'm missing something? I can't see how the branch predictor is relevant here. Can you explain in more detail?
"That's an understatement. It complicates the implementation significantly. Parallel-oriented (?) programming is quite hard by itself without all this."
How does this complicate it? You don't have to implement it yourself. If you're coding in CUDA, OpenCL or any of the common shading languages, then you write if-statements just as you would in C and it does the right thing. Honestly, the only concern is the performance degradation you get.
"That phrasing can carry an implied personal attack"
There was none intended. I was hoping that would make it sound helpful but I guess it didn't work. Text can be a tricky medium. Sorry.
Intel's GPUs kinda suck so I'm not sure how much performance you're going to get out of them even with the so called "low-latency" interconnect. On the AMD side, they have better GPUs, but unfortunately Ontario (and I believe Llano as well) don't even share northbridges, leave alone L3 cache.
>> * Low latency GPU-CPU interaction via L3 cache
> Intel's GPUs kinda suck so I'm not sure how much performance
> you're going to get out of them even with the so called
> "low-latency" interconnect
> On the AMD side, they have better GPUs, but unfortunately
> Ontario (and I believe Llano as well) don't even share
> northbridges, leave alone L3 cache.
http://www.anandtech.com/show/3865/amd-bobcat-bulldozer-hot-...
I would question AMD's gamble on OpenCL and lack of tools compared to Intel who acquired MIT's Cilk and absorbed other projects. Also I haven't seen anything close to Intel's SIMD sort algorithm yet (with regards of technical concepts, elegance, and sheer record-breaking performance.)
Next year with Intel's Sandy Bridge and AMD's Fusion things will change significantly. With CPU absorbing the GPU cores many shortcomings will be gone:
And also next year AVX will revive x86's SIMD. OpenCL is a bit of a can of worms, I'm not sure it will prevail in the long run. There are exciting new products for higher level programming like Intel's Parallel studio, in particular Cilk and Array Building Blocks.Hardware is changing and it's unviable to recompile for every possible combination of hardware. Most educated predictions are on generated code.
The chaos and misinformation is very annoying, but it is very exciting to live in an era of such a huge paradigm change in computing. Most algorithms have to be rewritten with a very different mindset. It's like a gold rush. Good times :)