Intel Expands Core Concept for Chips

Aziabel writes "As most of you have probably heard, Intel plans to come out with chips containing two processing cores next year, but that's just the start. The Santa Clara, Calif.-based chip giant intends to exploit the concept of using multiple processor cores; chips with four cores and eight cores will eventually join dual-core chips, which will begin to appear from Intel next year. The company's research department is also looking at the feasibility of creating chips with hundreds of cores to assist servers and supercomputers with large numbers of relatively repetitive calculations, said Steve Smith, vice president of the desktop platforms group at Intel. The focus on multiple cores arises from Moore's Law, which dictates that the number of transistors on a chip doubles every two years. I say, the more the better. Keep 'em coming, chip-makers!"

Comments

Cell Processor

[News for nerds]

It's nothing more than a catch-up move to Sony/Toshiba/IBM Cell, just like EMT64 to catch up AMD. Those late and awkward moves are of bad omen for Intel, IMO.

Re:Cell Processor

[skids]

Agreed. And in addition, really what they need to start doing is specializing the cores. Either that, or following the cell paradigm in reducing the complexity of each core to increase the number of cores, such that you can combine several into a special-function unit.

But we all know that nothing really changes until memory access changes. Memory continues to be the bottleneck, so if the only thing a processor with more cores can do fast is crunch numbers, you'd get more bang for the buck with better/more vector processing units.

Now, if/when they come out with memory that can be reorganized on-the-fly, perform large-scale simple massively-parrallel operations, and do some content-addressable tricks, that will be a signifigant development. I don't know how long it would take that to make it into higher level programming languages, though. It kinda of turns the job of writing programs on it's head.

Re:Cell Processor

[Psychofreak]

How about putting a significant amount of RAM on the die with the 2 (4 or 8) processors? From my understanding of space and volume it should be possible to put at least 256 MB on the die with 2 processors in an L3 or similar arrangement. Yes the complexity is higher but the overall speed of the system would increase much by having a significant amount of RAM at (or near) chip speed.

This coupled with about 1 GB of system RAM would (hopefully) provide superior performance.

As a side note, I guess my next box will be SMP, I like SMP machines!

Phil

Re:Cell Processor

[lukasz]

>Now, if/when they come out with memory that can be reorganized on-the-fly, perform large-scale
>simple massively-parrallel operations, and do some content-addressable tricks, that will be a
>signifigant development. I don't know how long it would take that to make it into higher level
>programming languages, though. It kinda of turns the job of writing programs on it's head.

Have you ever stumbled on FPGAs ? It's already there. The problem is, as I see it, it does turn writing programs on it's head. Thus, very few people outside of the hardware design crowd know what to do with them.
Just think how many people do get exposed to digital design vs programming. How many people do go beyond a vague idea of a processor working on data sitting in memory ? How many CS graduates are utterly unhappy about digital design classes ?

Re:Cell Processor

[wik]

This increases the fabrication costs for the silicon die because the processes used to create high-performance CMOS logic and high-density DRAM are different. Because of the cost, it's not likely to happen for commodity microprocessors any time soon.

Long-term strategy of this?

[OccidentalSlashy]

I am beginning to suspect that Intel does things like this simply to make x86's instruction set harder and harder to emulate well.

Kind of like to what I suspect Microsoft has been trying to do against Lindows for a while now, namely complicate their API more and more. And with IE and HTML.

Of course they're well within their rights to try. We'll just build a better idiot savant. Or let Steve Jobs keep making Apples that no one can really imitate in the first place.

Re:Long-term strategy of this?

[Decaff]

I am beginning to suspect that Intel does things like this simply to make x86's instruction set harder and harder to emulate well.

Why should this have anything to do with the instruction set? The principle is exactly the same as for existing multi-processor systems, but on the same chip.

Have we hit a wall for computational ability?

[Anonymous Coward]

This does not bode well for problems that mathmatically cannot be executed in parallel.

Great

[Anonymous Coward]

Now I can do away with my furnace.

Performance rateing

[Barny]

The problem is with what they (both intel and amd) plan to do is saying a dual core 1.5 centrino (for example) cpu is actually a 3Ghz machine (from the pr they have allready put out about these chips).

Read overclockers.com for some good speculation on what the good/bad/ugly features are likely to be.

Not that kind of law!

[melonman]

The focus on multiple cores arises from Moore's Law, which dictates that the number of transistors on a chip doubles every two years.

I don't think non-compliance with Moore's Law is a felony. It's an observation, not a statute. Moore's Law arises from the fact that transistor counts keep doubling, not the other way around.

Also, doubling the number of transistors in any way possible doesn't necessarily translate into double the power for any given application. In this case, multiple cores are good news for multi-threaded or forking server apps, but rather less interesting for a lot of desktop apps. Intel obviously has a vested interest in pushing ever larger die sizes, because it does large dies better than anyone else. Whether this will always be in the interests of the rest of the industry, let alone the end user, is less obvious.

Re:Not that kind of law!

[analog_line]

Gordon Moore, the guy the "law" was named after, works for Intel. Intel puts a fair bit of weight behind the notion behind it, and they even have a page on their research section about it.

hmm

[mattyrobinson69]

if a kernel is written to take advantage of multiple cores, would this mean applications written ontop of it would start using the multiple cores?

if not, how feasable is a multicore > single core emulation in linux.

Re:hmm

[jackb_guppy]

A core ~= A processor today. So multi-processor OS is nothing new. Shoot Intel Hyper-Threading is not new - It looks to OS as two processors but only 1 is running at given time.

You see an OS runs multiple threads in the first place it just switches between them as each need run time.

But for given program to be written to use 2 or more threads (looks to the OS as 2 or more programs) takes work.

So take a program that is already written and place in a multi-core/processor/thread enviroment with all else being equal - it will run as fast as it did before.

What will run faster is all of it. Take two of these old programs and run them in the multi-core/processor/thread enviroment and they each take same processing time unto themself, but the obversied time is shorter because they are both actually running at SAME time.

Yet again Intel pretends to invent a technology

[Anonymous Coward]

IBM have been doing this for years - and its biggest technological success story, the POWER5 chip shows that Intel are blatantly only playing catch-up with this announcement.

http://www.theregister.co.uk/2004/11/26/ibm_power5 _moores_law/ shows this perfectly.

It reminds me of the way that Intel pretended that they invented integrated wireless technology with its Centrino chip only after Apple had been shipping laptops for nearly two years with internal wireless cards.

Normally, asking if they had no shame would be appropriate but it is unfortunately clear (without the need to ask) that they don't.

Dual cores for Intel next year?

[I_am_Rambi]

Most of the reports that I have read have said that AMD will be releasing theirs next year and Intel the following year. Intel, though didn't start talking of dual cores until AMD started talking about theirs. From research that I have done, each manufactorer has some mighty issues to overcome with the single core before dual cores can be implemented nicely.

AMD has said that dual cores will be clocked anywhere from 600Mhz to 1Ghz slower than the single core counterpart, namely because of heat issues. There are many more issues that arise with dual cores here are a few

Cache correnance
Bus contention
software implementation
plus more

It will be interesting none the less on how each manufactorer overcomes the issues with multi-core chips and the benefits to the user of of multi-core.

Re:Dual cores for Intel next year?

[phoenix_rizzen]

Cache coherance, cache access, and bus contention are only problems for Intel. AMD solved most of these with the Athlon-MP and HyperTransport, and solved the reset with the Opteron's integrated memory controller.

In AMD SMP systems, each CPU has its own separate link to RAM and peripherals. Each CPU also has a link to each other CPU. If CPU A needs something in CPU B's cache, it just asks CPU A to send it that data across the inter-CPU link.

As you add CPUs in an Opteron server, you actually increase the RAM/system bandwidth. Compare that to a Xeon system where adding CPUs reduces the bandwidth available to each CPU (system/RAM bandwidth is constant).

There's a beautiful set of articles over at Ars Technica describing the SMP abilities of the Athoon, the Opteron, and the Xeon. It's amazing Intel has been able to sell any 8-way systems.

Yes they do

[Groo Wanderer]

Yeah, it is called Niagara, and it is working silicon now, but far from done. expect an unveiling in February.

If you want to know a bit more about it, I wrote it up a few weeks ago here:
http://www.theinquirer.net/?article=19423

-Charlie

Intel is not doing all that well in the core races

[Groo Wanderer]

Intel just canned their 8-way chip and replaced it with a variant of Montecito, or more likely a Montvale derivative. Here is a bit on it:
http://www.theinquirer.net/?article=20270
ht tp://www.theinquirer.net/?article=20286
Needless to say, their long term strategies are a tad up in the air right now.

As for their desktop (IE P4 based) dual core plans, there are 2 generations planned. The first is a simple pairing of 2 current cores with a minimum of tweaks, basically a scared response to AMD. The second one is really the first one they planned, and it is a lot more sophisticated.

AMD was there from long before Day One, and have the most coherent philosophy on dual cores for the desktop/server.

Rather than re-write all my own articles here, here is a link where I break down all of Intel's dual core plans as well as some of AMDs.
http://www.theinquirer.net/?article=17906

Sorry for all the self links, but I don't really want to keep re-writing that stuff, links are the reason behind the web, right? :)

-Charlie

More and more cores.. less and less bandwidth

[MROD]

Although for some, non-memory intensive, highly threaded applications multiple cores can be a boon, for many applications this won't be a boost in performance at all.

Remember that each of these processing cores will have to share their memory bandwidth and possibly level 2 cache as well. As it is Intel's EM64T Xeon processors really feel the bandwidth bottleneck in their memory interface and can easily saturate it.

I can see a dual core Xeon being able to saturate its memory bus on its own. Similarly, the dual core Opteron, unlike a dual processor Opteron, will have to share a single memory bus and hence be slower than a dual processor machine.

Adding extra cores merely moves the computing bottleneck elsewhere, it's not a panacea.

Yer Laws

[Doc Ruby]

"Laws" like Moore's, Newton's, Ohm's and others, don't "dictate" anything. They "describe" observations. Intel doesn't meet integration targets based on some hoary old directive from Gordon Moore from the late 1960s. They meet production deadlines projected as close to their maximum productivity. Moore observed the logarithmic rate of transistor integration increase way back then, and described it as invariable as gravity.

Engineers especially must understand that "laws" of nature, including human innovation, are governed by an "invisible hand". Not some imaginary deity, or some government, or some mythic genius. Rather, there is a deeper order to events, like the way every triangle has 180 degrees, the Sun "comes up" every morning, controversial Slashdot posts will get mod'ded "Troll", without any false statements or duplicity. We're engineers: our job is to engage the deeper order, understand it, model it, and exploit it, without further mystifying it.

Not a problem

[Groo Wanderer]

This is much less of a problem than you might thin, not because it isn't a real problem, but because it is so obvious. Everyone already has a workaround, most of which involve FB-DIMMs.

Niagara (see my post above) is bandwidth rich, the AMD solutions are also. The only ones with a looming problem are Intel until CSI comes on in a few years, but that is manageable.

Moral, Sun OK, AMD OK, Intel solid plan.

-Charlie

Multi-core/processor programming automatically

[doc modulo]

I read that some functional programming languages can automatically multithread a program so that the task is split up over multiple processors. The programmer would just program as for a single CPU and change nothing or very little.

Functional programmming languages examples are Lisp and OCaml.

Oh, correction, from a previous /. thread:

OTOH, it is theoretically possible to automatically multithread purely functional programs, especially if they're lazy like Haskell. So it could end up being a very important language on multi-processor and distributed systems.

The only way I see multi-core processors or cluster-like processors (Cell) succeed is if programmers switch to languages like that. Any other way would introduce too many bugs in programs. Computers should make life easier, not harder. Even for programmers.

Eventually, multi-core/processor is the only way forward, long before single-processors have to heat up to supernova temperatures to increase speed.

We're just at the beginning of computing. Looking back, programmers of the future will pity us poor folk who had to make do with only 1 CPU. However, we need the right tools to move forward. Anyone know if there's an automatically multithreading (functional) programming language in existance or being invented?