Intel - Market Doesn't Need Eight Cores 548
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."
Re:We've heard that before. (Score:5, Interesting)
They say the biggest bottleneck of any modern computer is its user...
Do all cores have to be smart? (Score:5, Interesting)
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.
Re:We've heard that before. (Score:3, Interesting)
Re:We've heard that before. (Score:3, Interesting)
Re:We've heard that before. (Score:5, Interesting)
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:Same old 640kB joke (Score:1, Interesting)
Plus, he's probably right that the market doesn't need it. It just wants it, and will pay for it, so it will happen.
I smell a fundemental software change coming... (Score:3, Interesting)
Peak CPU speed.
For now we have topped out on this, meaning our existing software is either gonna have to get more efficient, or it's going to have to change, unless we want to just deal with the level of performance and features we currently have.
(like that's gonna ever happen --how else would the closed corps sell upgrades then?)
Additionally, some application areas do not have enough CPU power to fully realize their potential. MCAD is one of these, by way of example. Take the fastest CPU's we have today and they are still not fast enough to fully render a solid model without wasting the operators time. Current software offerings are all working toward smarter data, creative ways to manage the number of in-memory and in-computation models, better kernel solves, etc...
But it's just not enough for the larger projects to work in the way they could be working.
Most of the MCAD stuff currently is built in a linear way. That's largely because of the parametric system used by almost all software producers today. With a few changes to how we do MCAD, I could see many cores becoming very important for larger datasets.
Peak CPU and RAM are the two primary bottlenecks that constrain how engineering CAD software develops and what features it can evolve for it's users. It's not the only example either.
The bitch is that most of the software we have is more than adequate for most of the people. For those that lie outside the norm, dependance on this software (both development and just use value need), constrains their ability to make use of multi-core CPU capabilities...
Messy.
Will be interesting to see how this all goes. Will the established players evolve multi-core transitional software that can bridge the gap, or will new players arise, doing things differently to take advantage of the next tech wave?
IMHO, there is a strong case for Intel doing the, "If we build it, they will come thing." For the higher demand computing needs, there really isn't any other way to improve, but through very aggressive code optimization.
Parallelization and cache coherency (Score:3, Interesting)
Pixar's Photorealistic Renderman (perhaps one of the greatest pieces of software ever written, from an engineering point of view) is very odd in that its shading language, while interpreted, is actually much faster at accomplishing its goals than other compliant renderers which compile down to the machine level. I believe this is because of memory bottlenecks, and despite the fact that computer graphics is an "embarassingly parallel" problem, eight cores is likely to aggrevate this much more than it is to help.
What I think is needed is a more functional-programming approach to a lot of these problems, where the mathematics of an operation is more purely expressed, leaving things like ordering/scheduling up to the compiler/runtime environment. Runtime compiled languages, like Java, can sometimes outperform even the best hand-optimized C due to the fact that the runtime compiler can optimize to the cache size and specific chihp family.
Also, this type of language would benefit multi-core processing because it would help expose the most possible parallelization opportunities, and let the compiler (perhaps even through trial and error) determine exactly when and how much parallel code to create.
Currently all of my parallel supercomputing code uses Fortran and the Message Passing Interface, but it's clear that this approach leads to code that is often very hard to debug and is very programmer-intensive. Hopefully the future of programming languages will help ease us into general purpose computing on highly parallel architectures like Cell.
Re:We've heard that before. (Score:5, Interesting)
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:Question. (Score:3, Interesting)
However, these chips are designed for throughput of multiple threads; for a desktop, single threaded app, you will still have the same memory bottlenecks we have now.
Re:We've heard that before. (Score:4, Interesting)
A webpage, for example, need not be parsed serial, though the performance of current systems is high enough that you get nothing in attempting to parallelize the renderer. A printer, however, can trivially be designed to be parallel, especially if you have unusually high DPI. Think of a printer rendering to a paper in the same way that a graphics card renders to a framebuffer. If you can use multiple pipelines, GPUs, and cards to accelerate video display, why wouldn't the same be possible for printing? The neat thing about printers and printed data is that there is no dependence, the image in the upper right exists independent of the image on the lower right, and etc etc. In theory you could have a core assigned to every PIXEL printed on a page, and a corresponding printhead with a printhead for each core, and you would be able to print an entire page in a cingle CPU cycle. Technically.
So there are plenty of other things that could be executed on multiple cores:
Decoding video (playback)
Encoding video (storage, rendering, chat)
AI for games (imagine simulating a multitasking AI on multiple cores)
Physics for games (uncoupled events can be processed independently and coupled events require access to the same data)
Yes, everything has a serial bottleneck, such as data access, but once properly set up most things can also be set up to be multicore as well. Saving a file, for example, can be multicore if you imagine the write as happening all at once, rather than serially, with each core assigned to a write head, each write head then operating independently... Etc.
Re:We've heard that before. (Score:3, Interesting)
Re:We've heard that before. (Score:3, Interesting)
Audio processing is the classic example of trivially massively parallel processing on the desktop. Let's say you have 40 tracks with four or more effects slots, plus a few effects on a bus, plus a few effects on the master output. Each one of those is a separate computation unit.
That's not to say that there aren't dependencies, of course. Within each channel chain, each plug-in has a dependency on data from the previous plug-in. Each of the bus mixers (including the master) has a dependency on having received output from all of its inputs. The effects that follow have a dependency on the bus mixer.
The point is that with a small amount of communication, it is possible to run each of these plug-ins on a separate thread and process it as a separate execution unit, and start processing the next batch far enough ahead to generally keep the pipeline completely full on a very large number of CPU cores. The I/O is still relatively high performance compared to the amount of processing being done (particularly if you include things like convolution plug-ins). In a well-written audio app, you are limited primarily by CPU speed. Of course, some folks offload this to specialized DSP hardware, but for those of us who aren't made of money, it's nice to be able to get a really beefy stock desktop computer that can handle it.
I do my audio work on a quad G5. It will do for now, but I'm guessing I'll want more than four cores within a low single digit number of years....
Re:We've heard that before. (Score:5, Interesting)
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.
Re:We've heard that before. (Score:3, Interesting)
Indeed. Even with multiple applications, there is rarely more than 1 CPU-bound thread on a desktop system.
Not that I doubt the ability of the industry to produce applications that warrant increased numbers of cores, but this will take time and in the current landscape anything more than 2 goes to waste for most people. There are some applications that need it already, and those people will no doubt be happy about increasing the core count, but I think this is going to be one of those "build it and they will come" things for the most part.
Re:We've heard that before. (Score:4, Interesting)
So imagine a situation where a webpage was DESIGNED to be parsed in parallel. The page hierarchy would be formatted into independent chunks that could be assigned to different threads and cores without first preparsing it. It would be like having an index built into the webpage such that different elements on the page could automatically, without additional effort, be spun off to different cores. A navigation bar, a banner, the main content, a link-box, and a footer, for example, could all be defined in a webpage such that as soon as the render saw that there exists five elements on the page each element is spun off to a different core to be handled.
The same with a printer; if the printing language were designed up front to be parallel, rather than serial, you could see speedups in rendering, though such gains is probably negligible. An image, such as an embedded jpeg in a document, would be split into four, for four cores, and then rendered into the appropriate printing language, which might come in handy when 10 megapixel pictures become common. Imagine a printer with four print heads, now. You could conceivably send four streams of data at once, which again could be fed by four cores (or a single core of course, if it pre-computed the data needed to be sent to the printer).
Decoding video: Uh, take a look at HD... that's pretty hardcore
Encoding video: Imagine now encoding an HD video chat on the fly
AI: I think you misunderstand. One AI enemy which formulates, simultaneously, five DIFFERENT responses from the same data structures... in other words, an AI of split mind. In the same way I can imagine writing four different responses to you, but only acting on one of them, an AI with multiple responses, but only a single action, becomes much richer, more unpredictable, and unbelievably more complex.
Physics: Physics is really a generic superset of graphics. Graphics is merely how light interacts with the data structures. Throw in gravity, sound, friction, and mass, and you have physics. The same reason why graphics can use multiple cores, then physics can too. Imagine if the 3d sound effects were split among two CPUs, just like frames are? Sound can be trivially represented as frames, much like graphics. Imagine the same with gravity being calculated by two CPUs every other frame, or friction, etc. You can calculate, for example, the spray pattern of a shotgun in time; the trajectory is known, the number of pellets are known, and the environment is known. Right now we approximate the intersection of a shotgun blast with the intersection of a player or a structure, but with additional compute resources you can actually trace each pellet individually!
The same with falling rocks, a flooding room, etc.
Most problems ARE parallelizable, I think, the only real question is approaching the problem from the onset with multiple cores in mind.
People It's JUST Marketing*Speak (Score:3, Interesting)
Let me translate from marketing-speak to plain English for y'all:
droid: two are enough for now, four will be mainstream in three years and eight is something the desktop market does not need.
translation: We have a two core product available now, we will have a 4 core product available in three years but we don't yet have a plan for an eight core product.
Re:We've heard that before. (Score:3, Interesting)