Intel's Crystal Ball Calls for More Cores in Future Processors, Tells Developers to Get Ready
Posted 07/02/08 at 02:49:47 PM by Paul Lilly
The recommendation comes from a recent blog post, which Intel calls 'Unwelcome Advice.' And they're right. As Arstechnica points out, "writing programs for arbitrarily large numbers of cores is a very different task than writing programs for just a few cores." The way it stands now, developers can dissect a single-threaded application into multiple threads and assign each to a specific core. And for the time being, they can get away with doing that, but not for long.
According to Intel, developers must start writing code capable of scaling performance beyond existing core counts, so that an application that runs well on a quad-core processor will run even better on 8, 10, or even 100 cores. Like the GHz wars of yesteryear, more cores should equate to better performance. Ray tracing, a term you'll undoubtedly become more familiar with as 3D gaming continues to evolve, already scales well to additional cores, but most applications can't make the same claim, and that poses a problem.
Despite the lack of future-proof software, this isn't a case of developers being lazy. Multiple-core processors are in their infancy, and single-threaded coding has existed for so long, that both the knowledge and development tools are in need of an overhaul. Asking developers to unlearn, relearn, and create is unwelcome advice indeed, but also necessary. Otherwise, it won't matter how many cores Intel and AMD are able to squeeze under a single die, we'll still be limited by the software.
Will the software ever catch up with the hardware? Be sure and post your thoughts below.
but seriously ...
Submitted by usp211816 on Sun, 07/06/2008 - 4:42am
"What we have here is a failure to allocate."A core is a core is a core at this point. It’s not like my quad core has a GPU core a CPU core a Cell Processor and an Encryption accelerator. As awesome as that would be it just doesn’t exist.Back in the stoned age when new processors had new commands every generation programs relied on something to translate for them it was a little thing we called an Operating System. The initial function of an operating system was to allow communication between programs and hardware. Somewhere along the line OS’s Evolved into massive slow moving monsters that got in the way and people started programming around them.I think that the multi-core processor needs to get off its high horse and realize it’s just a piece of hardware. The OS should determine number of cores, track usage, and allocate threads to the least used core. Last I looked my windows not only recognizes how many cores the computer has but tracks usage as well. Several interfaces to manually assign affinity already exist. There’s not really any reason a piece of middleware or eventually the OS itself cant automate this process.
Programmers should have seen this one coming and realized when processor went to 2 and then 4 cores that manually coding for multi-cores was going to be an issue and they were going to have to adapt and find a way to identify number of cores and allocate accordingly. Much like any other advance… Lead, Follow or Get out of the way.
if all else fails...
hmmmm...
Submitted by Wildebeast on Thu, 07/03/2008 - 12:52am
I'm not a programmer or an EE, so maybe I'm just dreaming here...
Wouldn't it be cool though, to have some magical (and highly complex) piece of software, which alots CPU cycles + RAM + hard drive access??
I mean in a way that you could tell your computer to use 1 or 2 cores (and maybe which specific ones) for your music program and IM/chat, the other 498 for Crysis, and prevent the Crysis processes from being inhibited by extra load(s) in the other two? Maybe if you're 10 years from now, you can also run Folding or something on another 300 cores.
I don't know that I'm talking about any software that's currently available. It just seems like someone should be thinking that way, eventually. To me, that's the point of the last paragraph.
You've had the power to do that all along....
Submitted by Talcum X on Thu, 07/03/2008 - 4:45am
If you have 4 cores (or 40) you can set the affinity of each app (proccess) to run on a dif. core. Enjoy.
***********
Every morning is the dawn of a new error.
You know if they were
Submitted by deadBird on Wed, 07/02/2008 - 7:58pm
You know if Intel/AMD were smart enough, they'd remove such a requirement to utilize multiple cores. Expecting developers to yield to Intel's whims is never going to work out. Proc makers should find a way to remove this limitation.
I can't see how for realtime
Submitted by AndyYankee17 on Wed, 07/02/2008 - 1:50pm
I can't see how for realtime processing (games) this can be efficient. valve has already stated that it is inefficent to write code for more than 3 cores, and even with 3 cores you end up with 2 cores @ 100% and 1 @ 20%. however, for nonrealtime this could be amazing, imagine rendering in adobe primier or maya, encoding video and music. and if I'm not mistaken, don't GPUs have roughly a couple hundred "cores"?
I know the Folding crowd
Submitted by Satchboy on Wed, 07/02/2008 - 1:49pm
I know the Folding crowd would love a 500 core CPU. Farm in a box anyone? :)
I, for one, look forward to
Submitted by TheMurph on Wed, 07/02/2008 - 11:57am
I, for one, look forward to the five-hundred-core Dream Machine. I plan to play 30 games at once.
maybe then you'll be fine
Submitted by norman on Wed, 07/02/2008 - 8:21pm
maybe then you'll be fine with two 30" monitors
-- Norm
Sounds dreamy! And think of
Submitted by One4yu2c on Wed, 07/02/2008 - 12:05pm
Sounds dreamy! And think of all the lolcats a five-hundred-core rig could process.
Feature
Review
Feature
Feature
Feature






