Intel - Market Doesn't Need Eight Cores

PeterK writes "TG Daily has posted an interesting interview with Intel's top mobility executive David Perlmutter. While he sideswipes AMD very carefully ('I am not underestimating the competition, but..'), he shares some details about the successor of Core, which goes by the name 'Nehalem.' Especially interesting are his remarks about power consumption, which he believes will 'dramatically' decrease in the next years as well as the number of cores in processors: Two are enough for now, four will be mainstream in three years and eight is something the desktop market does not need." From the article: "Core scales and it will be scaling to the level we expect it to. That also applies to the upcoming generations - they all will come with the right scaling factors. But, of course, I would be lying if I said that it scales from here to eternity. In general, I believe that we will be able to do very well against what AMD will be able to do. I want everybody to go from a frequency world to a number-of-cores-world. But especially in the client space, we have to be very careful with overloading the market with a number of cores and see what is useful."

Comments

We've heard that before.

[GundamFan]

I don't doubt an "8 core" desktop will exist in the near future. Then again he has a point... we won't likely need it.

Re:We've heard that before.

[kfg]

I don't "need" an R sticker and turbo sound synthesizer either, but they sure make my FIAT 500 go faster.

The Little Mouse that Roars!

KFG

Re:We've heard that before.

[tomstdenis]

If you're basing that on some logical sense of "need" I may remind you the average consumer doesn't need a quarter the computer they already have.

Tom

Re:We've heard that before.

[mrxak]

I frequently run as many as 8 programs at a time, sometimes more, but I seriously doubt each program would know what to do with its own core. With my two-CPU set-up, I find RAM to be almost the biggest limiting factor (although with 2GB, I've never actually run out). There's really no need for 8 cores until my brain is able to take multitasking to the next level, doing many many complex tasks that would gain benefit from (essentially) unlimited CPU power for each program.

They say the biggest bottleneck of any modern computer is its user...

Re:We've heard that before.

[rbgaynor]

eight is something the desktop market does not need

So is he the only person on the planet who has not tried the Vista beta?

Re:We've heard that before.

[Mayhem178]

And that will almost let you run Oblivion at max settings.

Re:We've heard that before.

[hackstraw]

I don't doubt an "8 core" desktop will exist in the near future. Then again he has a point... we won't likely need it.

My crystal ball is not always crystal clear, but I believe that 8+ cores will exist and are needed in the near future, at least for desktop systems.

History here. I'm an HPC admin which translates into I run beowulf stuff where pretty much OTS computers are connected together to work as one big computer. I'm also a desktop computer user who is anal retentive about having realtime info regarding the status of my computer with respect to CPU utilization and whatnot.

Now, in the many years of running desktop systems and being anal retentively monitoring them, I've noticed that CPU utilization is very often bursty. Meaning that its common for the CPU to hover around zero, and spike up with doing something like rendering a webpage, printing, compiling code, etc, etc. But most of the time (> 90% or well more if including when I sleep and stuff), the CPU is doing nothing.

So, what is my point? Give me cores out the wazoo, and let them completely power down when not needed and crank up to all 8 or more when needed. This will greatly improve power requirements and improve performance at the same time. Evidence of similar stuff in either nature or in other technologies are plentiful. 1) Hybrid gas/electric cars. They use both for higher performance when needed, and then back off and oscillate between the two when its optimal for efficiency. 2) Animal tissue like muscles and nerves. Muscles are pretty much idle most of the time, and only use a few fibers when doing a light contraction, but all of the available fibers become active when exerting maximum effort. Similar, but different with nervous systems. 3) Human workloads. There are certain industries that are not really a constant, and even the seemingly constant ones also have bursts as well, but lets think of things like seasonal things like retail, taxes, or things like seasonal vacation spots. These kinds of jobs bring in more human bodies to handle the peak loads, and let them go when the peaks are over. Its nuts that in many places in the US, seasonal vacation spots are frequently employed by people from half way across the world!

Now, is my 8+ core pipe dream going to happen tomorrow? No. But I believe this is where computing is going. Another thing that will have to change is that RAM should not be as random. In other words, memory, like CPU cores, should go dormant when not needed in order to conserve power as well, and of course there is the memory bandwidth issue as well.

Re:We've heard that before.

[avronius]

See, here's where I have to disagree.

Imagine an RPG that has multiples (100's) of 'computer' competitors that are "developing" along the same lines as you and your character(s). Or perhaps an MMORPG with thousands of players, competing against 100's of thousands of virtual characters that are developing along the same lines as your and the mmorpg's characters. Say goodbye to random encounters with stale NPC's - and hello to enemies with unique names and playing styles - all due to the computer's ability to handle such incredible virtualization.

Adding more RAM and a minor increase in speed wouldn't help in either of these scenarios. Bring on the cores, man, and don't stop at 8...

Re:We've heard that before.

[guaigean]

The home consumer market isn't exactly the goal for technology like this intiially, and the price won't be inline with home consumers anyhow. This is the kind of stuff used in High Performance Computing, as a single computing node can maintain large amount of CPU performance with no transfer between nodes. 2GB is nothing in the HPC world, and 8 cores get filled up fast. While it may be easy to assume "I can't fill 1 CPU, what would I do with 8"? you have to remember that there are people out there running huge simulations, which could very easily use up many thousands of CPU's.

Utility is in the eye of the user.

Re:We've heard that before.

[samkass]

Isn't this the same thing they said about 64bit chips?

Good point... yes, Intel said this about 64bit chips, and they were right. Almost nobody needs 64bit chips. But now virtually all chips are 64bits, wasting a lot of die real estate and engineering effort because of the perceived benefits driven more by AMD's marketing than reality. It's quite possible 8 cores could end up in the same boat-- AMD pushing it for no valid technological reason and Intel being forced to follow suit.

Re:We've heard that before.

[synx]

Interestingly enough as you recompile for 64 bits, you also need more memory as you get more memory. Now your memory alignment is now 8 bytes not 4 bytes, and your pointers are much later.

I'd like to take a moment to rail against most commonly accepted forms of parallel education. I'm sure you were taught about threads, critical sections, semaphores, shared memory, etc.

These are all inherently dangerous and difficult to program concepts. Write some application that is flexible and can run with N threads - usually this is hard, the best solution from Java-land is the concurrency toolkit which defines units of work which can be parallelized by a thread pool.

However, there _is_ another way. "CSP" - communicating sequential programs. This is a method of writing naturally parallel systems that do not have the disadvantages of all of the above. (Standard concurrency debugging suggestion in java: "make the method synchronized") A practical example of this is the programming language Erlang. Ericsson invented this language to write high performance telco gear. Their ATM switch line is written in it. In Erlang you have many many 'processes' (not traditional OS processes, but defined in the VM) which cannot share memory - the only way they can communicate is via async messages. You can build a synchronous call on top of async messages pretty trivially (after all, all syncronous network protocols are based on IP which is asynchronous). You never have to worry about memory stomps, or critical sections. You _do_ have to design your applications differently, but it is most definitely worth it.

Another interesting thing about this is your applications naturally parallelize. The "R11" release was just put out, which included SMP support. The previous versions would only use 1 CPU, but this version will use all your CPUs, which means if you have multiple processes ready to run, they'll run on as many CPUs you have! Instant SMP support, no redesign, no RECOMPILE necessary.

This kind of language technology is what is necessary to get us to the next level. A similar thing is possible with Functional languages such as OCaml, Haskell, etc.

I've been working in the industry for 5 years and I'm currently working on a Erlang project. My company was fairly conservative in terms of languages, there was a standing order (until about 2000) "no C++".

Re:We've heard that before.

[vadim_t]

Actually, I've been discussing this with a friend recently.

Take NWN for instance. How about making a game where things are REALLY happening? So far most worlds are extremely static. MMORPGs are static in that nothing ever changes, you kill the Lord of Evil and he's back on his dark throne 5 minutes later. And in most RPGs things just stay there and wait for you to appear (say, you never miss a battle in progress, as they just stay there until you appear nearby so that you can conveniently join the battle).

For example, in NWN it's very clear that there are multiple factions living in the area. How about having kobolds, knolls, wolves, etc move around on their own, gather food, kill each other, reproduce, try to invade, etc? Wouldn't it be neat if you could defeat the gnolls, then wander off for whatever reason, and when you return find the kobolds now took over the gnoll cave, increased their population, and Tymofarrar got out of the cave and set fire to the town?

Of course, make it too realistic and it gets a bit weird... imagine having to kill kobold children and walking on gnolls having sex.

The desktop market is the largest market.

[khasim]

If you put 8 core procs in desktop machines, software will be written that will take advantage of them. Which means you'll sell more 8 core procs.

Are you going to lead or follow?

Translation

[lisaparratt]

"Our multiprocessor technology doesn't scale, but we don't want to scare investors away, so we'll pretend it doesn't matter."

Silly Perlmutter

[ackthpt]

If the home user can justify (even indirectly due to demands of the operating system or changes in software architecture) 4 cores then 8 is immenently logical. Seems some minds at Intel are falling back to the dubious position they held regarding home users never needing 64 bit CPUs. Then again, maybe they're just playing dumb and are slaving away, burning midnight oil by the drum, to make 8 and 16 core processors.

Three Cores for the Clippy, but I don't know why,
Seven for the Vista kernel which is defect prone,
Nine for for Bloat which will make the cooling fry,
One for the Screensaver to toil alone,
In the Land of Redmond where Marketing lies.
One Core to rule them all, One Core to find them,
One Core to bring them all and in the darkness bind them
In the Land of Redmond where Marketing lies.

Neither four nor eight.

[MarkByers]

I think there is a world market for maybe five cores.

Re:well,

[man_of_mr_e]

I think he was talking about the foreseeable future.

1 core is really enough for most users. 2 cores is enough for most power users. 4 cores will be enough for all but the most demanding jobs. Workstations are different, however and are not usually considered part of the "desktop". For example, I could see 3D artists using 4 or 8 cores easily. In fact, there's simply no such thing as a computer that's "too fast" for certain purposes.

The issue, though, is one of moderation. Why would a desktop user want 8 cores, which are drawing insane amounts of power, when they're not even utilizing 4 to full advantage? Word processing, accounting, and surfing the web don't need any of this. Games? I can imagine in 10+ years we'll have some photo-realistic 3D games that run in real-time, but the vast majority of the work will likely be handled by GPU's and won't need 8 cores to deal with it.

I simply cannot fathom a purpose for 8 cores for any "desktop" application that isn't in the "workstation" class.

Classic mistake

[ajs]

He's right. Current desktops don't need 8 cores. However, as four cores become widely available, desktops will begin to change. They will become more threaded, and more processing that would have been avoided previously will begin to happen passively. Constantly streaming video in multiple thumbnail size icons on taskbars, stronger and more pervasive encryption on everything that enters or leaves the machine, smarter background filtering on multiple RSS sources, MUCH beefier JIT on virtual machines, on-the-fly JIT for dynamic languages, more complex client-side rendering of Web content (SVG, etc), these will all start to become more practical for constant use. Other things that we haven't even thought of because they're impactical now will also spring up. By the time 8-core systems are available, the market will already be over-taxing 4-core systems.

Do all cores have to be smart?

[spyrochaete]

I recently read about a 1024-core chip for small devices like cell phones Each core ran on a simplified instruction set and specialized in a certain task like muting the microphone when incoming sounds are too quiet, smoothing text on the low resolution screen, and other minute tasks. Individual cores could be placed in low power sleep mode until the software dictated a need for that instruction set.

Is it possible to couple CISC and RISC cores on one die? Is this how the math coprocessors of the 386 era worked? This sounds like an ideal solution to me since nobody needs 4 or 8 cores to be fully powered and ready to pounce at all times.

People Will Always "Need" More

[ausoleil]

"Need" is subjective.

Once upon a time, Bill Gates said we would never "need" more than 640K.

Once upon a time, mainframes only had 32K of RAM -- and that was a vast amount more than their predecessors.

The '286 came out and was primarily aimed at the server and workstation market. "No one will ever need all of that power."

Thing is, people always "need" more speed, more RAM and more storage. And they'll pay for it too, so Intel may "need" to sell 8X cores.

Re:Question.

[Aadain2001]

It depends on which memory bottleneck you are talking about. There is a memory hierarchy in computers, with the fastest also being the closest to the processor, the level 1 or L1 cache (usually split into separate data and instruction caches). This is then tied into a much larger, but slower, L2 cache (combined instruction and data lines). Some processors use an L3 cache, but not many these days. Current processors have L1 and L2 directly on the chip. If you see those die pictures they show off to the press, the largest areas of the chip are the caches. Finally, the chip can go across the front side bus and access the main system memory, which is very large compared to the L2 and L1 caches, but much slower in terms of number of cycles to access.

So which bottleneck are you refering to? The new Core 2 Duo chips of Intel's share the L2 cache and, as far as I can tell from the reviews I have read, this setup works very well. Both chips can share data very quickly or when executing a single sequential program one of the cores can use all of the L2 cache (which in the Extreme Edition verion is up to 4MB!). Or are you refering to the main memory? It is possible for both cores to need to access the main memory at the same time, but modern pre-fetching and aggress speculation techniques reduce how often that occurs and the timing penalties when they do occur. And of course, the larger the L2 cache the more memory can be stored on the chip at once, reducing the need to access the main memory very often. According to Intel's own internal testing, they had a very hard time using all of the bandwidth the current front side bus and memory offers, which means the main memory shouldn't be a bottleneck.

So what is the bottleneck you are refering to?

6 Coors enough

[CrazyJim1]

The 6 pack has been tried and true, why try and stuff an additional 2 Coors into it.

Re:Translation

[ssista537]

Seems like people dont RTFA. Let me Quote "Will we see eight cores in the client in the next two years? If someone chooses to do that, engineering-wise that is possible. But I doubt this is something the market needs." He is talking about next two years not ever. We just have an abundance of dual core machines in the market now and the apps to take advantage of it. Tell me how much different software we had two years ago than today. If so there is no way a desktop market needs 8 cores two years from now. Geez we have so many fanbois and script kiddies here with absolutely no knowledge of the industry, it is sickening.

I'll be the first to say it...

[Junior J. Junior III]

640 cores ought to be enough for anybody.

Re:well,

[koreth]

effectively using 8 cores usually requires talented programmers who have mastered multithreaded programming.

But ineffectively using 8 cores can be done by any dumbass with a C# compiler or a book on the pthreads library. Which is why we actually will need 8 cores.

Yes and no : depends on the brand

[DrYak]

Not quite exactly. Things depends on the brand.

For Intel that's exactly the case :
With current intel architecture, memory is interfaced with the NorthBridge.
With multicore and multiproc systems, all chips communicate to the NorthBridge and get their memory access from there.
So more cores and processors means same pipe must be shared by more, and there for memory bandwith per core is lower.
Intel must modify their motherboard design. They must invent QUAD-channel memory bus, they must push newer and faster memory types (that's what hapenned with DDR-II ! They needed the faster datarates, even if those come at cost of latency), etc...

But the more their pursue in this direction, the more latency they add to the system. Which in the end will put them in a dead end. (Somewhat like the deeper pipe of their quest for Gigahertz put them in dead-end of burning-hot and power-hungry P4).

For AMD that's not quite the same :
With the architecture that AMD started with the AMD64 series, memory is directly interfaced with a memory controller that is on-die with the Chip.
The multiple procs and the rest of the mother board communicate using a standarized HyperTransport.
The rest of the mother board doesn't even know what's hapenning up there with the memory.
And with the advent of HyperTransport-plugs (HTX) the mother board doesn't even realy need to know it.
Riser cards with Memory-And-CPU-Both-of-Them (à la Slot 1) is possible (and highly anticipated, because it'll make possible a much wider possibility of specialized accelerators to be plugged than currently with AM2 socket)

The most widely publicised advantages of this structure are the lower latency.
But this also makes it easier to scale up memory bandwith : Just add another on-board memory controller and voilà you have dual-channel. That was the differences between first generations of entry-level AMD64 (Athlon 64 for 7## socket : one controller - single channel, Athlon FX for 9## socket : 2 controllers, dual channel).
by the time 8 cores processors come out and if CPU riser-board with standart HTX connector appears, nothing will prevent AMD to just build riser board designed for 8 cores chips with 4 memory controllers (and Quad-channel speed). Just change the riser board, memory speed will scale. Mother board doesn't need to be re-designed. In fact, same mother board could be kept.
And this won't come at the price of latency or whatever : the memory controller is ON the cpu die, and must not be shared with anything.

In fact, that's partially already happening :
In the case of multi procsystems, instead of all procs sharing the same pipe thru the NorthBridge, each chips has it's own controller going at full speed.
And this memory can be shared over the HT bus (albeit with some latency).
It's basically 4 memory controllers (2 per proc) working together. Acheiving quad-channel alike shouldn't be that difficult.
Specially when Intel is pushing the memory standart to chips with higher latency : asking for more bandwith in parallel over the HT-bus won't be that much penalizing.

So I think AMD will be faster at developping solutions to scale against higher number of cores than Intel, due to better architecture.

Maybe, it's not a coincidence that AMD is working on technology to "bind together" cores and present them as single proc to not-enough SMP-optimized software, and that at the same time Intel is telling who ever wants to listen to them that 4 cores is enough, 8 is too much. (Yeah, sure, just tell it to the database- and Sun Niagara people. Or even to older BeOS users. This just sounds like "640k is enough for everyone")