So if larrabee is supposed to have really wide vectors doesn't that mean it will have the same difficult time the GPUs currently do with those pesky unpredictable branches and irregular memory accesses?

I'd take it that Mr. Ghuloum stands more in favor of gni than lni.
CPU to GPGPU link is slow?
AMD plans to have a HTX socket for the GPGPUs connected with low-latency / high-bandwidth HyperTransport to the CPU(s). Lack of dedicated ultra-high speed memory for the GPGPU would be a bigger problem for achieving peak performance, but this is solvable too.

Programming model? There are many emerging solutions to that problem. They will mature in a few years, but even before that you have many applications which would benefit greatly. It is not the number of applications that matters, it is the overall impact. Think about:
1. Server side anti-virus software (mail / content filtering)
2. Server side encryption (secure web servers, file servers etc.)
3. Server side RDBMS - SQL / Oracle (search / indexing / re-indexing)
4. Server side search - Exchange Server etc.

The benefits for the end-users? Faster and better Speach Recognition / OCR, picture search, desktop publishing software acceleration etc.

This is just well forgotten history - think abou the FPU co-processors back in the i286 / i386 era? Who would need FPU? Mostly scientists...;-))))
Does Wily actually read any of the INQ articles, otherwise he would know about Intel Larrabee and its 16 core mini AI. Intel is suppose to demo Larrabee next year.

creating a GPU solely for ray tracting would be great, but lets not forget 3D applications,they runs better under OpenGL. Hopefully Intel has thought about that also.
So if larrabee is supposed to have really wide vectors doesn't that mean it will have the same difficult time the GPUs currently do with those pesky unpredictable branches and irregular memory accesses?

I'd take it that Mr. Ghuloum stands more in favor of gni than lni.
Isn't that what larrabee is about??
CPU to GPGPU link is slow?
AMD plans to have a HTX socket for the GPGPUs connected with low-latency / high-bandwidth HyperTransport to the CPU(s). Lack of dedicated ultra-high speed memory for the GPGPU would be a bigger problem for achieving peak performance, but this is solvable too.

Programming model? There are many emerging solutions to that problem. They will mature in a few years, but even before that you have many applications which would benefit greatly. It is not the number of applications that matters, it is the overall impact. Think about:
1. Server side anti-virus software (mail / content filtering)
2. Server side encryption (secure web servers, file servers etc.)
3. Server side RDBMS - SQL / Oracle (search / indexing / re-indexing)
4. Server side search - Exchange Server etc.

The benefits for the end-users? Faster and better Speach Recognition / OCR, picture search, desktop publishing software acceleration etc.

This is just well forgotten history - think abou the FPU co-processors back in the i286 / i386 era? Who would need FPU? Mostly scientists...;-))))
But he is right, I as a GPGPU developer can confirm that.
Does Wily actually read any of the INQ articles, otherwise he would know about Intel Larrabee and its 16 core mini AI. Intel is suppose to demo Larrabee next year.

creating a GPU solely for ray tracting would be great, but lets not forget 3D applications,they runs better under OpenGL. Hopefully Intel has thought about that also.