Not really, allow me to explain.

One of the challenges of GPU performance is getting the connection between the CPU and Memory correct. That is why for years and years you've had the 'special' video card slot which was optimized for that, and then the general purpose slots that didn't have the kinds of demands that video offered. So if I get back space for a 'regular' slot and can put the GPU inside, that is a win for me, even though I predominantly use them in servers which brings me to ...

CUDA, or more accurately, running general purpose compute tasks on shader engines. Having the GPU there, even if I am not using it as a GPU, can provide some impressive benefits if I can program it to operate on in memory data in a fast parallel way. So in this regard it stops being a GPU and starts being a kind of funky but powerful co-processor.

And of course the third thing is that keeping the power draw sane is important. Its a small chip and pulling a lot of heat out of it is very difficult. Additional cores, additional heat, higher operating temps (or more exotic cooling systems).

One of the things that would be interesting (but won't happen on an Intel part any time soon) is if there were a bridge port so you could run dual-CPU and the GPUs could run in a crossfire/SLI mode where they each rendered every other line or something along those lines. Since I use dual cpu motherboards that would give me additional compute options that I don't have at the moment, but it won't happen at Intel because it would disrupt the market positioning of Ivy Bridge.

Ouch, please don't do this. You're mixing stuff up badly. The "special" video card slot throughout history has simply been a higher bandwidth interconnect relative to whatever else was there (well, in the AGP days it also had a primitive IOMMU for doing DMA into userspace). The integrated graphics on Intel parts, obviously, have the important distinction of sharing the memory controllers (and, I believe, the L3 cache?) with CPU work. That does hurt things under some loads, though many games are actually quite CPU-light these days.

"CUDA" is an NVIDIA trademark for their compute platform, it's not a special kind of technology. In fact Intel's i915 derived GPU works very similarly. In fact, Intel's AVX instructions also work along basically identical lines. They're all wide SIMD implementations of a bunch of parallel tasks(/threads/lanes/warps, the Industry terminology is a mess).

Honestly, I think rwmj is right: for a consumer gaming rig, it would be preferable to have an 8 core part without integrated graphics. The reasons that isn't going to happen aren't technical though: first, Intel needs to ship different binnings of these same parts into segments (Ultrabooks, tablets) where the graphics are required and where price is more constrained -- basically, they have to make these in large quantities anyway. Second (and relatedly) they already do make "lots of cores w/o graphics" variants, but they sell them into the low volume server market where margins are much higher. Selling an 8 core consumer chip would canibalize Xeon sales.

Just to clarify:

You: "The "special" video card slot throughout history has simply been a higher bandwidth interconnect relative to whatever else was there..."

Me: "One of the challenges of GPU performance is getting the connection between the CPU and Memory correct. "

Yes, its the GPU <-> (CPU/Memory) interconnect. It has, since the introduction of PCI, been a 'different' slot than other peripherals. So I don't see how we're confused.

You: ""CUDA" is an NVIDIA trademark for their compute platform, it's not a special kind of technology. ... the Industry terminology is a mess)."

Me: "CUDA, or more accurately, running general purpose compute tasks on shader engines."

The industry terminology is a mess, however most readers recognize the name 'CUDA', nVidia's implementation of a shader language, as that technology. Further it was the introduction of using shaders as vector units which lead to folks implementing things like the 'PS2 supercomputers'. (and to be precise, no you cannot use nVidia's tools on PS2s)

You: "Honestly, I think rwmj is right: for a consumer gaming rig, it would be preferable to have an 8 core part without integrated graphics."

Which is great, what I would love to see then is how you reason to that opinion. What is it about the 4 additional cores that would improve the 'consumer gaming rig'. How are you measuring 'good' vs 'not as good'? Cost? Triangles per second per dollar? Developer support?

"Second (and relatedly) they already do make "lots of cores w/o graphics" variants, but they sell them into the low volume server market where margins are much higher. Selling an 8 core consumer chip would canibalize Xeon sales."

I don't think anyone has argued that Intel couldn't make an 8 core processor out of this technology, heck the feature size is small enough they could probably to 12 or 16 cores and still get decent yield, but there are other system issues associated with that, most notably cache behavior and size.

But the specific question on the table was that Intel has made a part which they expect people to put into laptop machines and maybe even tablets. They chose to make it a four core machine with an integrated GPU, are you arguing that the consumer experience on those laptops would be improved if Intel required an external GPU? If so I'd be interested on your take on that as well. First, the way you evaluate value, and then the case for an external GPU that maximizes that value.

You just restated what he said, but with a bad pedantic overtone to top it.

That's already available; it's called Sandy Bridge-E.

I was thinking the opposite; for games it would probably be better to have two cores but more GPU. The upcoming Ivy Bridge vs. Trinity comparison will be interesting.

Throwing more cores at the problem isn't really terribly efficient, though. You don't see as much of a return as you might expect, especially when most things aren't properly multithreaded.

Oh sure, I understand it's not in Intel's interests at all. But it would sure make my builds faster if I could default to 'make -j16' (hyperthreads). I guess I'm not the target audience here.

I suppose it depends on the toolchain, but in my experience build time is mostly dominated by disk I/O nowadays. Even with my code stored on an SSD.

With C++ it is in my experience solidly CPU-bound, for example on 12 xeon cores, or 24 hyperthreading threads, and one 7200 RPM disk.

For any compiling work I need to do, I usually offload to my Linode install with 4 Xeons. Your mileage may vary, though.

The graphics in IVB are not just on the die, but are part of the internal memory ring and thus the shared L3 cache. So CPU cores are able to directly send and receive shared memory from the GPU, and the GPU is able to use the same last-level cache (LLC) as the CPU cores.

This is why you see the simple fill-rate benchmarks of IVB blow away SNB and discrete GPUs.