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."
We've heard that before. (Score:5, Insightful)
The desktop market is the largest market. (Score:5, Insightful)
Are you going to lead or follow?
Comment removed (Score:4, Insightful)
Question. (Score:4, Insightful)
well, (Score:4, Insightful)
Re:We've heard that before. (Score:2, Insightful)
Translation (Score:2, Insightful)
Re:well, (Score:5, Insightful)
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 (Score:5, Insightful)
Re:We've heard that before. (Score:5, Insightful)
Tom
People Will Always "Need" More (Score:5, Insightful)
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:We've heard that before. (Score:3, Insightful)
Similar to their 64-bit desktop stance? (Score:1, Insightful)
Then AMD made a huge success with it and they had to backtrack.
Re:well, (Score:2, Insightful)
But this time the new hardware would be dependent on a major overhaul of the software industry. Any programmer can write code to fill up a 1GB hard drive, but effectively using 8 cores usually requires talented programmers who have mastered multithreaded programming. This is a small fraction of the software developer population, so apps that can take advantage of an 8-core CPU will probably be few and far between for a good long while. (Not to mention, not every computing task can even be parallelized in the first place.)
Changes in software architecture seem to have a huge amount of inertia. It took almost a decade to transition from 16-bit to 32-bit desktops even though it was *easier* to program a 32-bit app than a 16-bit one. Who knows how long it would take to get most apps taking advantage of large numbers of cores when the coding will be much harder than most developers are used to?
Re:We've heard that before. (Score:5, Insightful)
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:Translation (Score:4, Insightful)
Re:Question. (Score:4, Insightful)
For Intel, they are currently using a shared bus approach. It makes sense for a lot of reasons (mainly by being very cost effective), and they are developing a point-to-point bus for the near future. In such a system, each CPU is using the bus for retrieve data. This means that they lock the bus, make their calls, finish, and unlock. The total bandwidth available is split between all parties, so if there are multiple active members (e.g. CPUs) then their effective bandwidth is split N ways. The only solution to this is to have multiple shared busses, which is expensive.
A point-to-point bus gives each member their own bus to memory. Thus, there is NxBW effective bandwidth available. As memory cells are independant, the memory system can feed multiple calls. You'll only run into issues if multiple CPUs are accessing the same memory, but models have been around for a long time. There might be a slightly higher latency, but not by much.
With multiple cores, you may get the benefit of shared caches which could remove a memory hit.
Overall, I would assume a multi-core system would scale fairly similarly to a multi-processor system.
Comparisons to 640K misguided ... (Score:4, Insightful)
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.
Re:We've heard that before. (Score:2, Insightful)
their $500 clothes sets, their personal shoppers, their $100 hair cuts.
but hey this is america, the land of capitalism.
overindulgence is expected here.
shame we are now the fatest, laziest, most uneducated country in the world but atleast you have that 50" plasma TV right?
thats all that matters, you have more "stuff" than somebody else.
Re:We've heard that before. (Score:2, Insightful)
Re:We've heard that before. (Score:3, Insightful)
You can distribute different pages for printing, different frames pro html rendering, or divs or something. Your browser could be decompressing pngs and jpegs in other cpus while one parse the html too.
Web browsing is still limited by the network anyway, increase cpu to browse the web doesn't make any sense for me. At least with my 400kbps DSL
But I at least would not want to increase cpu power for these trivial tasks. I would prefer that it happens when I do something heavier, like a game, or at least something that takes more than 1sec.
Re:well, (Score:5, Insightful)
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.
Re:The desktop market is the largest market. (Score:3, Insightful)
Second, the makers of multimedia applications already go ahead with multithreading, because it really works for that type of application. This will drive the market for more cores. In the long run, I expect the mainstream market to settle at the number of cores that works best for multimedia applications and games.
I think this will be at least four cores (in that I agree with David Perlmutter) but it may be more, depending on the progress of computer science in parallelization of the above applications. Personally, I would not be surprised to see 16 core CPUs in mainstream computers someday.
Re:We've heard that before. (Score:5, Insightful)
Utility is in the eye of the user.
Re:We've heard that before. (Score:3, Insightful)
Well, AMD did come up with a way to make their 64-bit CPUs immediately useful: they increased the number of registers at the same time (but could only make them available in 64-bit mode, to avoid breaking stuff when running in 32-bit mode). Aside from that, 64-bit isn't intrinsically useful unless you want a virtual memory address space bigger than 4 gigabytes (which, at the moment, tends not to be true for casually-used PCs).
I'm betting on just that -- I'm a CS undergrad, and I took a parallel programming specifically for that reason
Re:We've heard that before. (Score:2, Insightful)
In the future if they have some decent logic to handle context switching and thread migration then shifting to lots of small parallel operations could make computing even better as far as I'm concerned. Parallel operations on multiple cores could really benefit some types of desktop apps. Others simply wouldn't benefit because of the simple logical linear progression required by their nature.
Past 4 cores, you want NUMA anyway (Score:3, Insightful)
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.
Re:We've heard that before. (Score:5, Insightful)
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:Question. (Score:4, Insightful)
Re:We've heard that before. (Score:3, Insightful)
Video processing
photo processing
Multitrack digital audio recording with multiple real time DSP effects
And that's just what I thought about in 10 seconds. Not to mention what video games could do with all that processing power.
Re:The point is... (Score:4, Insightful)
Re:We've heard that before. (Score:2, Insightful)
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 believe '2' is a good number. '4' will be an interesting number for the high-end. 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.
and
I think that it will be two or three years until you are going to see four cores entering the mainstream.
So according to him, for the next few years anything more than four cores will not be mainstream. Sounds pretty reasonable to me.
Re:We've heard that before. (Score:4, Insightful)
Almost no desktop programs actually use 4 gigabytes of RAM. Not even allowing for rapid expansion will we reach that bottleneck anytime soon.
The Intel guys were right. What are the uses of 64 bit systems? They are removing a bottleneck that very few were hitting. The AMD64 instruction set fixes (more registers etc) are nice but not worth the hassle of losing binary compatibility. Result? Hardly anybody uses a pure64 system. Only enthusiasts.
Re:We've heard that before. (Score:3, Insightful)
If those 8 cores are from AMD, then they'll be utilizing a NUMA architecture, and provided the OS "does the right thing" then no, you won't be waiting for memory, at least not any more than you are now, and probably less so.
If those 8 cores are from intel, they'd better have improved their bullshit bus, or no, it won't help.
Re:We've heard that before. (Score:4, Insightful)
Re:We've heard that before. (Score:3, Insightful)
As with every other technological yardstick of computers, entertainment is driving the platform, not "desktop programs," for which the technology of a decade ago was adequate.
Re:Silly Perlmutter (Score:3, Insightful)
$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.
Re:Main memory of course. (Score:4, Insightful)
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.
Re:We've heard that before. (Score:3, Insightful)
Obviously, you have never tried to simualate or graph propagation of an organic virus with a 4 million node set using Matlab x64 on a desktop system.
We would be pleased to take your enthusiast money and 128 of your gaming buddies' money and build a Linux computational cluster to solve a problem that will likely save your life or the life of someone you know.
It's called dataflow (Score:3, Insightful)
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.