×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Intel Says to Prepare For "Thousands of Cores"

ScuttleMonkey posted more than 5 years ago | from the viva-la-coding-revolucion dept.

Intel 638

Impy the Impiuos Imp writes to tell us that in a recent statement Intel has revealed their plans for the future and it goes well beyond the traditional processor model. Suggesting developers start thinking about tens, hundreds, or even thousand or cores, it seems Intel is pushing for a massive evolution in the way processing is handled. "Now, however, Intel is increasingly 'discussing how to scale performance to core counts that we aren't yet shipping...Dozens, hundreds, and even thousands of cores are not unusual design points around which the conversations meander,' [Anwar Ghuloum, a principal engineer with Intel's Microprocessor Technology Lab] said. He says that the more radical programming path to tap into many processing cores 'presents the "opportunity" for a major refactoring of their code base, including changes in languages, libraries, and engineering methodologies and conventions they've adhered to for (often) most of the their software's existence.'"

cancel ×
This is a preview of your comment

No Comment Title Entered

Anonymous Coward 1 minute ago

No Comment Entered

638 comments

The thing's hollow - it goes on forever (5, Funny)

stoolpigeon (454276) | more than 5 years ago | (#24035943)

- and - oh my God - it's full of cores!

Re:The thing's hollow - it goes on forever (1)

Penguinisto (415985) | more than 5 years ago | (#24036509)

Actually, I think this is the one case where you could honestly say "...it's turtles all the way down!" and not get laughed at.

/P

Not Sure I'm Getting It (5, Insightful)

gbulmash (688770) | more than 5 years ago | (#24035965)

I'm no software engineer, but it seems like a lot of the issue in designing for multiple cores is being able to turn large tasks into many independent discrete operations that can be processed in tandem. But it seems that some tasks lend themselves to that compartmentalization and some don't. If you have 1,000 half-gigahertz cores running a 3D simulation, you may be able to get 875 FPS out of Doom X at 1920x1440, but what about the processes that are slow and plodding and sequential? How do those get sped up if you're opting for more cores instead of more cycles?

Re:Not Sure I'm Getting It (5, Informative)

Delwin (599872) | more than 5 years ago | (#24036011)

Because each core is no longer task switching. Once you have more cores than tasks you can remove all the context switching logic and optimize the cores to run single processes as fast as possible.

Then you take the tasks that can be broken up over multiple cores (Ray Tracing anyone?) and fill the rest of your cores with that.

Re:Not Sure I'm Getting It (5, Funny)

Mordok-DestroyerOfWo (1000167) | more than 5 years ago | (#24036025)

My friends and I have lots of conversations about girls, how to get girls, how to please girls. However until anything other than idle talk actually happens this goes into the "wouldn't it be nice" category

Re:Not Sure I'm Getting It (0)

FinchWorld (845331) | more than 5 years ago | (#24036081)

My friends and I have lots of conversations about girls, how to get girls, how to please girls.

And as you post on slashdot (yes, yes, I'm postin too) fail on all parts?

Re:Not Sure I'm Getting It (4, Funny)

CDMA_Demo (841347) | more than 5 years ago | (#24036235)

My friends and I have lots of conversations about girls, how to get girls, how to please girls.

What, haven't you guys heard of simulation?

Re:Not Sure I'm Getting It (3, Interesting)

zappepcs (820751) | more than 5 years ago | (#24036121)

IANACS, but if your program structure changes a bit, you can process the two different styles of instructions in different ways, such that when the data needed from or to some sequential group of tasks is needed it is already there, sort of like doing things 6 steps ahead of yourself when possible. I know that makes no sense on the face of it, but at the machine code basics of it, by parsing instructions this way, 5 or 6 operations from now you will need register X loaded with byte 121 from location xyz, so while this core plods through the next few instructions, core this.plus.one prefetches the data at memory location xyz to register X.... or something like that. That will break the serialization of the code. There are other techniques as well, and if written for multicore machines, the program machine code can be executed this way without interpretation by the machine/OS.

There are more than one type of CPU architectures, and principles of execution vary between them. Same for RISC CISC. I think it is likely that the smaller the instruction set for the CPU, the more likely that serialized tasks can be shared out among cores.

Re:Not Sure I'm Getting It (4, Interesting)

Talennor (612270) | more than 5 years ago | (#24036263)

While prefetching data can be done using a single core, your post in this context gives me a cool idea.

Who needs branch prediction when you could just have 2 cores running a thread? Send each one executing instructions without a break in the pipeline and sync the wrong core to the correct one once you know the result. You'd still have to wait for results before any store operations, but you should probably know the branch result by then anyway.

Re:Not Sure I'm Getting It (3, Interesting)

zappepcs (820751) | more than 5 years ago | (#24036445)

Indeed, and any tasks that are flagged as repeating can be repeated on a separate core from cores executing serial instructions such that IPC allows things that happen serially to happen coincident with each other. A simple high level example is reading the configuration for your process that may change at any time during your process due to outside influences. Let the reading of that happen out of band on the processing as it is not part of the sequential string of instructions for executing your code. That way config data is always correct without your serially oriented code needing to stop to check anything other than say $window.size=? such that it's value is always updated by a different core.
Sorry if that is not a clear explanation. I just mean to say that since most of what we do is serially oriented, it's difficult to see how at the microscopic level of the code, it can be broken up to parallel tasks. A 16% decrease in processing time is significant. Building OS and compilers to optimize this would improve execution times greatly, just as threading does today. If threads are written correctly to work with multiple cores, it's possible to see significant time improvements there also.

Re:Not Sure I'm Getting It (5, Insightful)

Anonymous Coward | more than 5 years ago | (#24036485)

That is what most current processors do and use branch prediction for. Even if you have a thousand cores, that's only 10 binary decisions ahead. You need to guess really well very often to keep your cores busy instead of syncing. Also, the further you're executing ahead, the more ultimately useless calculations are made, which is what drives power consumption up in long pipeline cores (which you're essentially proposing).

In reality parallelism is more likely going to be found by better compilers. Programmers will have to be more specific about the type of loops they want. Do you just need something to be performed on every item in an array or is order important? No more mindless for-loops for not inherently sequential processes.

Re:Not Sure I'm Getting It (2, Interesting)

sexconker (1179573) | more than 5 years ago | (#24036493)

So instead of a pipeline you have a tree.

Great, except for the fact that it's incredibly inefficient and the performance gain is negligible.

Quantum computers will (in theory) allow us to do both at once.

Lookahead/predictive branching is one option... (4, Interesting)

Cordath (581672) | more than 5 years ago | (#24036199)

Say you have a slow, plodding sequential process. If you reach a point where there are several possibilities and you have an abundance of cores, you can start work on each of the possibilities while you're still deciding which possibility is actually the right one. Many CPU's already incorporate this sort of logic. It is, however, rather wasteful of resources and provides a relatively modest speedup. Applying it at a higher level should work, in principle, although it obviously isn't going to be practical for many problems.

I do see this move by Intel as a direct follow up to their plans to negate the processing advantages of today's video cards. Intel wants people running general purpose code to run it on their general purpose CPU's, not on their video cards using CUDA or the like. If the future of video game rendering is indeed ray-tracing (an embarrassingly parallel algorithm if ever there was one) then this move will also position Intel to compete directly with Nvidia for the raw processing power market.

One thing is for sure, there's a lot of coding to do. Very few programs currently make effective use of even 2 cores. Parallelization of code can be quite tricky, so hopefully tools will evolve that will make it easier for the typical code-monkey who's never written a parallel algorithm in his life.

Re:Lookahead/predictive branching is one option... (1)

umghhh (965931) | more than 5 years ago | (#24036517)

As for monkeys this has been tried many times. Sadly some of the monkeys I saw had degrees in computer science. Good thing about these degree monkeys - they did not defecate on the keyboard (at least the ones I knew did not) which the real monkeys did when confronted with similarly daunting task: http://www.wired.com/culture/lifestyle/multimedia/2003/05/58790 [wired.com]

It may be just a hunch but I think the parallel processing will take some time and brain power to use properly and it is going to stay this way for a while.

Re:Not Sure I'm Getting It (2, Informative)

zarr (724629) | more than 5 years ago | (#24036253)

How do those get sped up if you're opting for more cores instead of more cycles?

Algorithms that can't be parallelized will not benefit from a parallel architecture. It's really that simple. :( Also, many algorithms that are parallelizable will not benefit from an "infinite" number of cores. The limited bandwith for communication between cores will usually become a bottleneck at some point.

Re:Not Sure I'm Getting It (3, Insightful)

ViperOrel (1286864) | more than 5 years ago | (#24036279)

Just a thought, but I would say that 3 billion operations should be enough for just about any linear logic you could need solved. Where we run into trouble is in trying to use single processes to solve problems that should be solved in parallel. If having a thousand cores means that we can now run things much more efficiently in parallel, then maybe people will finally start breaking their problems up that way. As long as you can only count the cores up on one hand, your potential benefit from multithreading your problem is low compared to the effort of debugging. Once you have a lot of cores, the benefit increases significantly. (I see this helping a lot in image processing, patern recognition, and natural language... not to mention robotics and general AI...)

Re:Not Sure I'm Getting It (5, Insightful)

pla (258480) | more than 5 years ago | (#24036327)

I'm no software engineer [...] but what about the processes that are slow and plodding and sequential? How do those get sped up if you're opting for more cores instead of more cycles?

As a software engineer, I wonder the same thing.

Put simply, the majority of code simply doesn't parallelize well. You can break out a few major portions of it to run as their own threads, but for the most part, programs either sit around and wait for the user, or sit around and wait for hardware resources.

Within that, only those programs that wait for a particular hardware resource - CPU time - Even have the potential to benefit from more cores... And while a lot of those might split well into a few threads, most will not scale (without a complete rewrite to chose entirely different algorithms - If they even exist to accomplish the intended purpose) to more than a handful of cores.

How many are? (1)

spectrokid (660550) | more than 5 years ago | (#24036465)

I mean, even your average plod starting Outlook on Vista, is starting dozens of fancy visualisation thingies, anti-spam algorithms, networking things...
Properly programmed, it can be torn apart in hundreds of tasks. It is not going to speed up your terminal window, no. But does your terminal window need speeding up?

Great... (4, Funny)

Amarok.Org (514102) | more than 5 years ago | (#24035973)

As if Oracle licensing wasn't complicated enough already...

True Dat (1)

stoolpigeon (454276) | more than 5 years ago | (#24036033)

and imagine all those cores in a box running a bunch of virtual machines. every dba team will need an accountant.

Re:Great... (1)

MBGMorden (803437) | more than 5 years ago | (#24036269)

IBM is just as bad. They charge by performance unit, and a core is worth more or less depending on the number of cores present on the chip, the number of processors present in the machine, and the architecture of the chip in question.

Single core x86 chips would be 100 per core, but dual or quad core x86 chips would be 50 per core.

Then say SPARC-based chips might be worth 60 units per core regardless of how many cores per chip.

Then there are the absurdity of their AS/400 machines, which ship with a certain number of processors already in the machine anyways, but you have to pay extra (aside from extra software licensing) in order to have additional ones activated if you need them . . . .

Re:Great... (2, Interesting)

Penguinisto (415985) | more than 5 years ago | (#24036395)

...then again, I can see it as an argument for vendors to finally --finally!-- stop counting "processors" as their license limit metric. And yes VMWare, I'm talking to you too when I say that.

/P

Memory bandwidth? (5, Interesting)

Brietech (668850) | more than 5 years ago | (#24035975)

If you can get a thousand cores on a chip, and you still only have enough pins for a handful (at best) of memory interfaces, doesn't memory become a HUGE bottleneck? How do these cores not get starved for data?

Re:Memory bandwidth? (0)

Anonymous Coward | more than 5 years ago | (#24036031)

Always has, always will be.

Re:Memory bandwidth? (1)

Piranhaa (672441) | more than 5 years ago | (#24036119)

If the memory controller is built onto the silicon, each core has access to the cache directly, and there is enough bandwidth between the cache and memory, I don't see this being a problem. I'm quite sure they have this figured out :)

Re:Memory bandwidth? (2, Interesting)

smaddox (928261) | more than 5 years ago | (#24036133)

Memory would have to be completely redefined. Currently, you have one memory bank that is effectively accessed serially.

If you have 1000 cores that depend on the same data, you would have to have a way of multicasting the data to the cores, which could then select the data they want.

Basically, hardware and software architecture has to be completely redefined.

It is not impossible, though. Just look around. The universe computes in parallel all the time.

Re:Memory bandwidth? (2, Insightful)

lazyDog86 (1191443) | more than 5 years ago | (#24036151)

I would assume that if you have enough transistors to have thousands of cores that you will be able to put on a lot of SRAM cache as well - just drop a few hundred or thousand cores. You won't be able to integrate DRAM since it requires a different process, but SRAM should be integrated easily enough.

Re:Memory bandwidth? (2, Interesting)

tt465857 (1317143) | more than 5 years ago | (#24036189)

3D integration schemes, which IBM and Intel are both pursuing, help deal with this problem. As you noted, you can't put enough pins on a chip with traditional packaging to achieve a sufficient memory bandwidth. But with 3D integration, the memory chips are connected directly to the CPUs with "through-chip vias". You can have tens of thousands of these vias, and as a bonus, the distance to the memory is extremely short, so latency is reduced.

- Trevor -
[[self-construction] [blogspot.com]]: The autotherapeutic diary of a crazy geek's journey back to mental health

Re:Memory bandwidth? (2, Insightful)

Gewalt (1200451) | more than 5 years ago | (#24036361)

Not really. If you can put 1000 cores on a processor, then I don't see why you cant put 100 or so layers of ram on there too. Eventually, it will becomea requirement to get the system to scale.

Have you ever seen VPU design? (0)

Anonymous Coward | more than 5 years ago | (#24036449)

That problem was solved by VPU design a long long time ago, there is an array of memory controller each has multiplexed pipe to every core in its block. The idea is data gets pipelined between the processor and memory, requests for start of transfer and end of transfer only changes the selector on the multiplexor. Any outstanding transfer requests get queued. Further more, data gets cached which the cores have direct access to.

Re:Memory bandwidth? (1)

Penguinisto (415985) | more than 5 years ago | (#24036463)

Could be, but that could be solved (at least physically) by using daughterboards/Slot 1 like rigs and by physically breaking up the CPU into discrete chips (which in turn would offer an interesting way to upgrade... don't want to buy a whole new CPU? No problem, just buy some additional 'core pack' chips and plug 'em into empty daughterboard slots).


Never underestimate the ingenuity of an engineer when there's a potential to make shitloads of money off of the solution, even if that solution isn't the most optimal or elegant.

/P

Generic jokes (0, Redundant)

Toe, The (545098) | more than 5 years ago | (#24035977)

Maybe Program X will finally not be so slow.

It's a series of tubes; um cores.

Howabout a beowolf clust... I can't even do that one.

Re:Generic jokes (0, Redundant)

cashman73 (855518) | more than 5 years ago | (#24036157)

Once the squeeze the 10,000th core into that, most people ought to be able to run Windows Vista just fine,... maybe even Duke Nukem Forever, too? ;-)

Re:Generic jokes (0)

Anonymous Coward | more than 5 years ago | (#24036453)

In Soviet Russia, cores prepare for thousands of you!

Message from Intel to Developers (1)

daveatneowindotnet (1309197) | more than 5 years ago | (#24036001)

"Look if we are going to sell these things you need to start developing software for them, otherwise it'll look like we are trying to milk the market or something"

Disagreement about this trend (5, Interesting)

Raul654 (453029) | more than 5 years ago | (#24036015)

At Supercomputing 2006, they had a wonderful panel [supercomputing.org] where they discussed the future of computing in general, and tried to predict what computers (especially Supercomputers) would look like in 2020. Tom Sterling made what I thought was one of the most insightful observations of the panel -- most of the code out there is sequential (or nearly so) and I/O bound. So your home user checking his email, running a web browser, etc is not going to benefit much from having all that compute power. (Gamers are obviously not included in this) Thus, he predicted, processors would max out at a "relatively" low number of cores - 64 was his prediction.

Re:Disagreement about this trend (1, Flamebait)

jez9999 (618189) | more than 5 years ago | (#24036167)

How is it possible to get a good, responsive end-user e-mail experience with a mere 64 cores?

Re:Disagreement about this trend (0)

Anonymous Coward | more than 5 years ago | (#24036233)

64 cores is enough for anybody.

Even 64 sounds optimistic (2, Interesting)

Joce640k (829181) | more than 5 years ago | (#24036283)

I'd be surprised if a desktop PC ever really uses more than eight. Desktop software is sequential, as you said. It doesn't parallelize.

Games will be doing their physics, etc., on the graphics card by then. I don't know if the current fad for doing it on the GPU will go anywhere much but I can see graphics cards starting out this way then going to a separate on-board PPU once the APIs stabilize.

We might *have* 64 cores simply because the price difference between 8 and 64 is a couple of bucks, but they won't be used for much.

Re:Even 64 sounds optimistic (1)

everphilski (877346) | more than 5 years ago | (#24036325)

Our world runs in parallel; why shouldn't our computers?

64 sounds good to me. I wouldn't complain if I had more.

Re:Disagreement about this trend (3, Funny)

tzhuge (1031302) | more than 5 years ago | (#24036345)

Sure, until a killer app like Windows 8 comes along and requires a minimum of 256 cores for email, web browsing and word processing. Interpret 'killer app' how you want in this context.

Re:Disagreement about this trend (0)

clampolo (1159617) | more than 5 years ago | (#24036381)

I disagree with this guy. The average automobile has over 300 processors in it. Why would a computer max out at 64?

Part of the reason for this is that things become easier when you have a separate processor running things. Instead of having a single processor share time between the cruise control, the engine controller, turning signals, variable speed wipers, etc... you just have a different processor for each and glue them together. I suspect that once processors become ubiquitous software engineers will learn this and use up all the processors as well to make simpler code.

Re:Disagreement about this trend (4, Insightful)

RightSaidFred99 (874576) | more than 5 years ago | (#24036507)

His premise is flawed. People using email, running a web browser, etc... hit CPU speed saturation some time ago. A 500MHz CPU can adequately serve their needs. So they are not at issue here. What's at issue is next generation shit like AI, high quality voice recognition, advanced ray tracing/radiosity/whatever graphics, face/gesture recognition, etc... I don't think anyone sees us needing 1000 cores in the next few years.

My guess is 4 cores in 2008, 4 cores in 2009, moving to 8 cores through 2010. We may move to a new uber-core model once the software catches up, more like 6-8 years than 2-4. I'm positive we won't "max out" at 64 cores, because we're going to hit a per-core speed limit much more quickly than we hit a number-of-cores limit.

Re:Disagreement about this trend (3, Interesting)

the_olo (160789) | more than 5 years ago | (#24036543)

So your home user checking his email, running a web browser, etc is not going to benefit much from having all that compute power. (Gamers are obviously not included in this)

You've excluded gamers as if this had been some nearly extinct exotic species. Don't they contribute the most to PC hardware market growth and progress?

Ok.. so how do I do that? (2, Interesting)

bigattichouse (527527) | more than 5 years ago | (#24036027)

Are we just looking at crazy-ass multithreading? or do you mean we need some special API? I think its really the compiler guru's who are really going to make the difference here - 99% of the world can't figure out debugging multithread apps. I'm only moderately successful with it if I build small single process "kernels" (to steal a graphics term) that process a work item, and then a loader that keeps track of workitems .. then fire up a bunch of threads and feed the cloud a bunch of discrete workitems. Synchronizing threads is no fun.

Re:Ok.. so how do I do that? (4, Informative)

Phroggy (441) | more than 5 years ago | (#24036221)

A year or so ago, I saw a presentation on Thread Building Blocks [threadingb...blocks.org], which is basically an API thingie that Intel created to help with this issue. Their big announcement last year was that they've released it open-source and have committed to making it cross-platform. (It's in Intel's best interest to get people using TBB on Athlon, PPC, and other architectures, because the more software is multi-core aware, the more demand there will be for multi-core CPUs in general, which Intel seems pretty excited about.)

been there, done that (5, Funny)

frovingslosh (582462) | more than 5 years ago | (#24036051)

Heck, my original computer had 229376 cores. They were arranged in 28k 16 bit words.

Re:been there, done that (0)

Anonymous Coward | more than 5 years ago | (#24036201)

I thought a core only stored one bit?

Re:been there, done that (1)

frovingslosh (582462) | more than 5 years ago | (#24036515)

That's why you needed lots of them. My original math was off by a factor of 2 (damn bytes and words), so I had even more cores. Intel is so behind the times.

Where will they put... (1)

Thelasko (1196535) | more than 5 years ago | (#24036055)

all of those DIMMs of RAM. I'm thinking they will have to come up with something smaller. Maybe more than one DIMM on a... DIMM?

Downright neat (2, Funny)

Alarindris (1253418) | more than 5 years ago | (#24036069)

640K cores should be enough for anybody.

Re:Downright neat (0)

Anonymous Coward | more than 5 years ago | (#24036525)

640K cores should be enough for anybody.

"Sniff", I miss Bill already.(sigh)

We all saw it coming anyway (1)

eebra82 (907996) | more than 5 years ago | (#24036071)

It's fairly obvious that both Intel and AMD are heading this way. The transistors are shrinking, but we will soon create a transistor that cannot be shrunk further, and once this happens, we will have to think layers and cores and possibly more GHz.

So whether programmers find this move acceptable or not is irrelevant because this path is probably the only way to design faster CPU:s once we've hit the nanometer wall.

Re:We all saw it coming anyway (5, Insightful)

ClosedSource (238333) | more than 5 years ago | (#24036341)

"So whether programmers find this move acceptable or not is irrelevant because this path is probably the only way to design faster CPU:s once we've hit the nanometer wall."

I guess you should put "faster" in quotes.

In any case, it is absolutely relevant what programmers think since any performance improvements that customers actually experience is dependent on our code.

Historically a primary reason to buy a new computer is because a faster system makes legacy applications run faster. To a large extent this won't be true with a new multicore PC. So why would people buy them?

That's why Intel wants us to redesign our software - so that in the future their customers will still have a reason to buy a new PC with Intel Inside.

It's already here. (1, Informative)

GreatBunzinni (642500) | more than 5 years ago | (#24036077)

We already have systems with tens and and hundreds of cores. Those processors already go by the name of "graphics card" and those changes in languages and libraries go by the name of CUDA, C2M, brook+ and the like.

The only thing new that Intel brought to the table with this press release is the attempt to fool us into believe that there is nothing of the kind available and that Intel is somehow innovating in some aspect or another.

Face it: the age of the "CPU is the computing muscle" is long gone.

Good idea (4, Insightful)

Piranhaa (672441) | more than 5 years ago | (#24036083)

It's a good idea.. Somewhat of the same idea that the Cell chip has going for it (and well, Phenom X3s). You make a product with lots of redunant objects so that when some are bound to failure, the percentage of failure is much lower..

If there are 1000 cores on a chip, and 100 go bad... You're still only losing a *maximum* of 10% of performance versus when you have 2 or 4 cores and 1 or 2 go bad, you have a performance impact of 50% essentially.. Brings costs down because yeilds go up dramatically.

optimal & maximum (1)

Tumbleweed (3706) | more than 5 years ago | (#24036099)

The optimal # of cores will inevitably wind up being 42, but nobody should ever need more than 640K cores.

Perhaps a machine that can configure the # and type of cores it needs on the fly will come about some day.

I'm more interested in on-die RAM for now. A combined CPU/GPU/RAM hooked to SSD storage. Yum.

Where's my Singularity? I was promised a Singularity!

Useless (1)

Rinisari (521266) | more than 5 years ago | (#24036103)

What's the use until programmers start learning effective parallel programming? Right now, it's game developers who are winning that game, with graphics and movie editors right behind it.

Re:Useless (5, Insightful)

CastrTroy (595695) | more than 5 years ago | (#24036177)

Well, parallel programming is hard. It's not so hard that it can't be done, but it's harder than sequential programming. Unless your app will have a specific advantage because of this parallel programming, then it isn't worth the effort to do it in the first place. The nice thing however, would be that you could run each process on a separate core, and there wouldn't be any task switching needed. This would speed things up quite a bit. Also, if you locked a process or thread to each core, then one slow down wouldn't take out the entire system.

Re:Useless (3, Interesting)

everphilski (877346) | more than 5 years ago | (#24036387)

Parallel programming doesn't have to be hard, in fact, it comes very naturally in a number of domains. For example, in finite element analysis (used in a number of math disciplines, including CFD and various stress type calculations) the problem domain is broken down into elements which can naturally be distributed. Calculations within an element are completely independent of the domain until the system of equations are to be solved, and efficient parallelized matrix solvers is old hat.

We got to keep reminding ourselves, the world we live in runs in parallel, why shouldn't our computers?

Stupid Dyslexia (1)

FlyingSquidStudios (1031284) | more than 5 years ago | (#24036109)

I read that as 'Thousands of Crows' and had this great image of flocks of birds flying out of my ethernet port, delivering packets to the world.

Already Happening (3, Informative)

sheepweevil (1036936) | more than 5 years ago | (#24036129)

Supercomputers already have many more than thousands of cores. The IBM Blue Gene/P can have up to 1,048,576 cores [ibm.com]. What Intel is probably talking about is bringing that level of parallel computing to smaller computers.

Re:Already Happening (1)

Piranhaa (672441) | more than 5 years ago | (#24036305)

I'm thinking Intel is talking about bringing thousands of cores to minimal piece(s) of silicon. The Blue Gene still uses single cored processors, just mass amounts compacted together by a crossbar switch.. (http://en.wikipedia.org/wiki/Cyclops64). I highly doubt Intel would be referring to having a system with each core separate.. That was my take anyways

What's in it for us? (1)

ClosedSource (238333) | more than 5 years ago | (#24036181)

I understand why Intel is so interested in multiple cores - they can't make the faster single-core chips that the market wants.

The question is what's our motivation? Unless software performance is approximately linearly proportional to the number of cores (e.g. a 10 core cpu can run a software application 10x faster than it ran before it was made core-aware), it probably isn't worth converting legacy apps.

Re:What's in it for us? (1)

SeekerDarksteel (896422) | more than 5 years ago | (#24036419)

1) It doesn't necessarily have to be linearly proportional. It just has to be greater than the performance we could gain by making more complex single cores. In fact, scalability is more important in some sense than efficiency (speedup/core). The most significant advantage of parallelization isn't speedups, but opportunities. It's not that you can do the same task twice as fast, it's that you can do a problem twice as large in the same amount of time.

2) It very much is, currently, a solution in search of a problem. But that doesn't mean it's not worth pursuing. It's a chicken and the egg kind of scenario. We don't have a lot of uses for a thousand cores because we dont have thousand core systems to develop useful applications for.

Declarative languages is the answer (3, Interesting)

olvemaudal (1318709) | more than 5 years ago | (#24036183)

In order to utilize mega-core processors, I believe that we need to rethink the way we program computers. Instead of using imperative programming languages (eg, C, C++, Java) we might need to look at declarative languages like Erlang, Haskell, F# and so on. Read more about this at http://olvemaudal.wordpress.com/2008/01/04/erlang-gives-me-positive-vibes/ [wordpress.com]

just one more.. (0)

Anonymous Coward | more than 5 years ago | (#24036197)

"Oh, the fools! If only they'd built it with 6000 and 1 cores"

Is that really a good idea? (3, Interesting)

neokushan (932374) | more than 5 years ago | (#24036241)

I'm all for newer, faster processors. Hell, I'm all for processors with lots of cores that can be used, but wouldn't completely redoing all of the software libraries and such that we've got used to cause a hell of a divide in developers?
Sure, if you only develop on an x86 platform, you're fine, but what if you want to write software for ARM or PPC? Processors that might not adopt the "thousands of cores" model?
Would it not be better to design a processor that can intelligently utilise single threads across multiple cores? (I know this isn't an easy task, but I don't see it being much harder than what Intel is proposing here).
Or is this some long-time plan by intel to try to lock people into their platforms even more?

Desperation? (3, Interesting)

HunterZ (20035) | more than 5 years ago | (#24036265)

Honestly I wonder if Intel isn't looking at the expense of pushing per-core speed further and comparing it against the cost of just adding more cores. The unfortunately reality is that the many-core approach really doesn't fit the desktop use case very well. Sure, you could devote an entire core to each process, but the typical desktop user is only interested in the performance of the one progress in the foreground that's being interacted with.

It's also worth mentioning that some individual applications just aren't parallelizable to the extent that more than a couple of cores could be exercised for any significant portion of the application's run time.

Intel is building an FPGA (2, Interesting)

obender (546976) | more than 5 years ago | (#24036291)

From TFA:

Dozens, hundreds, and even thousands of cores are not unusual design points

I don't think they mean cores like the regular x86 cores, I think they will put an FPGA on the same die together with the regular four/six cores.

That's all well and good..... (1)

PontifexMaximus (181529) | more than 5 years ago | (#24036295)

but can we PLEASE work on getting apps to run on more than just ONE core/processor for now? I mean it's amazing how many apps still are not SMP aware unless you can (possibly) compile them for that purpose and even then you don't always get the kind of increase you would expect. Let's start with programming on 2 cores and then maybe go to 4 or more. For now, the kind of stuff Intel is discussing is moot. If we can't get shit to run on 2 procs, why do we bother with thinking about 12?

Re:That's all well and good..... (0)

Anonymous Coward | more than 5 years ago | (#24036323)

AMEN !

Punting again (1)

Waffle Iron (339739) | more than 5 years ago | (#24036335)

Intel tried to push the complexities of increasing computing speed off into software before. When they designed the Itanium, they figured that the software compiler would magically find extra concurrency in the apps and utilize the large number of functional units in the core, and that this would make other architectures obsolete. Well, it didn't quite work out as they planned.

Hopefully they won't spend $Billions going down the "hypothetical software will enable radical hardware changes" road again just to learn the same lesson as last time.

Start! What do they mean, start? (3, Interesting)

4pins (858270) | more than 5 years ago | (#24036339)

It has been long taught in theory classes that certain things can be solved in fewer steps using nondeterministic programming. The problem is that you have to follow multiple paths until you hit the right one. With sufficiently many cores the computer can follow all the possible paths at the same time, resulting in a quicker answer. http://en.wikipedia.org/wiki/Non-deterministic_algorithm [wikipedia.org] http://en.wikipedia.org/wiki/Nondeterministic_Programming [wikipedia.org]

Re:Start! What do they mean, start? (1)

ratboy666 (104074) | more than 5 years ago | (#24036547)

Yes, but...

Each choice point requires a core. You WILL run out of cores; it really doesn't matter how many you have... Unless, of course, you solve THAT problem, which scores you a Nobel Prize.

Microsoft's reply (1, Funny)

Anonymous Coward | more than 5 years ago | (#24036401)

Prepare for thousand core dumps!

don't trust him! (1)

nih (411096) | more than 5 years ago | (#24036439)

Anwar Ghuloum, a principle engineer with Intel's Microprocessor Technology Lab

don't trust him! he just wants the ring!

Heat issues (3, Interesting)

the_olo (160789) | more than 5 years ago | (#24036441)

How are they going to cope with excessive heat and power consumption? How are they going to dissipate heat from a thousand cores?

When the processing power growth was fed by shrinking transistors, the heat stayed at manageable level (well, it gradually increased with packing more and more elements on die, but the function wasn't linear). Smaller circuits yielded less heat, despite being much more of them.

Now we're packing more and more chips into one package instead and shrinkage of transistors has significantly slowed down. So how are they going to pack those thousand cores into a small number of CPUs and manage power and heat output?

All we need to do now... (3, Interesting)

DerPflanz (525793) | more than 5 years ago | (#24036473)

is find out how to program that. I'm a programmer and I know the problems that are involved in (massive) parallel programming. For a lot of problems, it is either impossible or very hard. See also my essay 'Why does software suck [friesoft.nl]' (dutch) (babelfish translation [yahoo.com]).

I'm not bitter. (1)

Headcase88 (828620) | more than 5 years ago | (#24036491)

Games are already so suspiciously inefficient at managing the hardware they run on in order to help hardware companies push their newer products. It's going to be fun to watch games in the future somehow slow a 1000-core cpu to a crawl on the low detail setting, to help sell the 2000-core models.

They'll have an excuse if we have 3D monitors at that point, otherwise they'll just have to bullshit about particle effects taking more power (even on the low detail settings).

Free Beer (1)

wooferhound (546132) | more than 5 years ago | (#24036503)

I sure would like to have 1000 Coors
Sure it would be nice to have 1000 cores in the CPU but it would suck if they were all 386sx 16mhz.

It's all changing too fast (2, Insightful)

blowhole (155935) | more than 5 years ago | (#24036557)

I've only been programming professionally for 3 years now, but already I'm shaking in my boots over having to rethink and relearn the way I've done things to accomodate these massively parallel architectures. I can't imagine how scared must be the old timers of 20, 30, or more years. Or maybe the good ones who are still hacking decades later have already had to deal with paradigm shifts and aren't scared at all?

Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Sign up for Slashdot Newsletters
Create a Slashdot Account

Loading...