Slashdot Mirror
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."
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.
I don't give a damn for a man that can only spell a word one way.
Mark Twain
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?
"Our multiprocessor technology doesn't scale, but we don't want to scare investors away, so we'll pretend it doesn't matter."
Does having multiple cores do anything about the memory bottleneck? Does this make the machine balance better or worse?
I don't want to insult the person but saying that 8 is something that will not be needed seems very short sighted. People were saying only a few years ago "1GB is too big for a hard-drive"... Never under estimate the increasing need for power in computers, even for home users
*''I can't believe it's not a hyperlink.''
Intel saying "The market doesn't need 8 cores" = Intel saying "We can't really engineer 8 cores right now, we've hit some trouble". Of course the market would like 8 cores. Markets are greedy for new stuff, that's how you keep on making money. Intel's covering their ass for putting 8 cores on their roadmap for anytime soon.
There is nothing interesting going on at my blog
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.
"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.
Previously they said there is no need for 64-bit on the desktop.
Then AMD made a huge success with it and they had to backtrack.
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.
What quite a few other posters are failing to understand is that he is referring to diminishing returns. 1 to 2 give you some fractional improvement, 2 to 4 gives you a smaller fractional improvement, 4 to 8 gives you an even smaller fractional improvement, etc. At some point the cost, size, heat, noise (for the cooling), etc is not worth the fractional improvement. For most users that will probably be dual or quad.
For those extremely rare apps and jobs that are highly parallelable 8 and above will be useful. However this will be very rare and this is why the comparisons to the infamous 640K quote are misguided. Increasing RAM is easy, software naturally consumes RAM with no additional work necessary, just do more of what you are alraedy doing. Multiprocessing is something completely different, the code must be designed and written quite differently, and it is often very difficult to retrofit existing code for multiprocessing. Now you have the practical problem that not all problems are parallelable.
Strangely enough, I think one case where 8 cores could be useful in a home environment would be a bit retro. A multiuser/centralized system. One PC with the computational power for the entire family, dumb terminals for individual users, connections to appliances for movies, music, etc. Such a machine might go into the basement, garage, closet, or other location where noise is not an issue. Of course, I'm not sure such a centralized machine would be cost effective.
Once you have 8 cores, it becomes advantageous to have memory which is faster for each group of 4. At 8, you're on the edge where the advantage exists, but isn't sufficient to justify the additional architectural complexity. For 16 and up, it's much better to have 4-processor nodes each with its own memory (and slower access to memory on other nodes). It's unlikely that improvements in chip technology will change this. It's also not something about desktop computers; existing large machines use 4-processor nodes.
So he's right; before it makes sense to have more than 4 cores on a chip, you'll want multiple chips of 4 cores each with separate memory busses, and then system RAM on the processor chip (at which point the architecture is significantly different, because the system is asking the processor for memory values, rather than the opposite), and only then does it become efficient again to put more cores on the chip, as you can have a multiple-node chip.
Not necessarily. A dual-core system is more expensive, per-core-GHz, than a single-core system. That is, $300 might buy you a 2.0GHz dual-core CPU or a 3.0GHz single-core CPU (apples-and-apples GHz here, so AMD and not Intel).
$154 - AMD Athlon 64 X2 3800+ Dual Core 2GHz
$86 - AMD Athlon 64 3200+ 2GHz
Looks pretty close to a wash in my book.
$327 AMD Opteron 165 Dual Core 1.8GHz
$170 AMD Opteron 144 - Box 1.8GHz
Not much difference here on $ per-core-GHz either.
Your statement might have been true last week, prior to the AMD price cuts. But things are a lot nicer now (and the low-end dual-cores are almost an automatic choice). $68 for the 2nd core makes a lot of sense, even for a low-end CPU because it will add a few years of usability onto the lifespan of the machine. Or at least the machine will feel snappier for a few years longer then the single-core.
And the primary reason that AMD 64bit CPUs get so much goodwill? Unlike the Itanic, AMD came up with a 64bit design that provides for the future while still providing excellent performance for 32bit applications. So why not buy a 64bit chip even if you're still running 32bit? There's no performance hit and if the landscape changes and we all need to move to 64bit, you're already there.
Pretty much a no-risk decision as a result. You're not betting on 32bit or 64bit, you're simply prepared for either.
Wolde you bothe eate your cake, and have your cake?
If you look at Intel's Core 2 Duo, the cache space is not "divided" as the number of cores increase. Each core, if running at full load, will have 2MB of cache (extreme edition anyway). That is a very respectivable cache size and would be a respectable single core processor. When one core is not running (like when running only Word), one core sleeps while the other core is given all of the cache.
Past marking ploys (GHz) were definately wrong, and trying to directly replace those metrics with the number of cores is also a bad choice. But don't you see that that is exactly what Intel is trying to prevent? The interviewee in the article is saying that more cores != more performance. Hence why desktop users will have no need for 8 cores or more. Most of the posts on this topic are along the lines of "ya right, more cores FTW!", which is a very uninformed mentality.
Space for rent, inquire within
Actualy what you described is a very specific instance of dataflow programs, where the flow can best be described by a directed "dataflow" graph. Technicaly macrodataflow since you pass data between processes; true dataflow reduces the granularity all the way down to individual instructions passing each other operands.
The reason "applications naturally parallelize" is because the language is forcing the programer to be explicit about the parallelism, something that doesn't come naturaly to your Freshman CS101 coder. Imperative languages like C, Fortran, Java, etc. that students are taught first are geared towards von Neumann machines and are incredebly hard for the compiler to parallelize.
Interestingly, functional languages like you mentioned (also try 'Id') map quite well to dataflow. This is directly due to their lack of side effects (i.e. manipulating structures in memory, which must be inherently sequential in order for the programer to reason well about program correctness.)
Dataflow had a lot more following in the 80s and early 90s. One problem was actualy an explosion of too much parallelism exposed in the application, more than the functional units could handle. The overflow then had to be shuttled back and forth to memory, making the aps bandwidth limited. Look at the MIT TTDA, Monsoon, *T, TERA, TAM, WaveScalar, and other projects. The ability to put many functional units (cores) and sufficient memory to keep them fed on a single die recently (last 5 years) reduces this limit and may allow the field to have a bit of resurgance.
"You saved 1968." - Ms. Valerie Pringle to the crew of Apollo 8