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

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.

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!

[bradbury]

In fact it is neither Moore's Law nor increasing transistor count that is driving multi-core designs. It is economic and competitive pressures.

As another reader pointed out there is a serious drool factor in a dual core AMD Opteron. Other than the gamers and overclockers one does not need dual cores or multi-GHz clock speeds for most applications. My desktop system is a dual processor 200MHz Pentium Pro system (circa '97) and my web server which was /.'ed in August is a dual processor 100 MHz Pentium (circa '95). "Dual" processors is *not* new. Both systems work fine for the jobs they need to perform most of the time. The only times they don't is when clueless programmers overengineer their web sites. I guess it takes a lot more than dual cores or GHz clock speeds to make me drool. :-;

But getting back to the topic at hand. Most of my dual processor systems *rarely* use both processors. I think I've only noticed one program (a commercial OCR program) that seems to be programmed to take advantage of dual processors). I think the older versions of Netscape may have an explicit problem with dual processors if Javascript is enabled. [I suspect this is because Javascript may try to run as a separate thread and both Javascript and the HTML image display code use the memory heap at the same time without single threading the code and end up corrupting the heap. But this is just a guess on my part.]

The real reason for going to multiple cores is (a) the drool factor; and (b) competitive edge [for example Sun is pushing on 4 & 8 cores to distinguish themselves from the commodity processors]; and (c) true supercomputer applications. With respect to (c) a lot of people in government and research were pretty upset with the fact that the U.S. didn't have the #1 spot in the Top500 list for the better part of 2 years. While having multiple cores helps put you back at the top of the list -- supercomputer architectures are complex. You reduce the processor delays between the processors on the same chip but for problems which require the CPU and memory of thousands of processors (protein folding for example) you still have "speed-of-light" message passing delays between the multi-core processors. That requires a very sophisticated message passing network. [See theoretical discussion here.] You can reduce these delays by packing the processors closer together but then you have heat and reliability problems.

These problems aren't quite as significant with server farms because the data is coming from and going out into the world and interprocessor delays are not as important as they are in supercomputers and large database applications that have to be concerned with concurrency issues.

It is interesting to note that IBM is running the Blue Gene clock speeds at rates significantly below what AMD and Intel chips are at and even IBM's PPC chips are capable of. And this is from the company that used to build ECL based mainframes that had to be water cooled (so they know the technology). I presume this is because the want to keep the heat production down, reliability up and perhaps to minimize the excess space (and therefore interprocessor delays) that water cooling might require.

Re:I like

[bersl2]

Personally, I produce more drool thinking about dual dual-core Opterons. Not that that's really necessary. It's just that 4 > 2, and quad processor boards don't make very good workstations, especially in light of two-socket boards from companies like Iwill and Tyan that will also be SLI-capable. Really, all of that power is not necessary, but imagining it makes me feel good. Or is that weird feeling from having stayed up all night?

Re:Cool stuff, but...

[Anonymous Coward]

We've been hearing this for a LONG time(witness Itanium) and still they are nowhere near where they need to be. The only compilers that are acceptable today in this regard are DSP compilers, but they have a much more straightforward task.

Yeah, yeah.

[eddy]

&gtwill begin to appear from Intel next year.

Very likely this is marketing sp33k for "will be paper-launched at the last day of next year"

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.

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.

Re:Cell Processor

[getch();]

Why, praytell, does Intel need to either specialize their cores or move toward a massively parallel architecture like Cell is supposed to be? Do you have some foresight into the performance of as of yet nonexistent computing architectures?

Anyone even vaguely familiar with multithreaded programming and execution should know that it is difficult (sometimes impossible) to extract parallelism from the majority of the desktop computing applications. As such, throwing more cores at the problem doesn't necessarily help. I'm repeating myself, but it is very likely that next year's dual-core systems will perform worse than today's single core versions in most applications (which aren't multithreaded).

Forgive me if I'm somewhat skeptical of the Cell architecture as well. (We all know how hard the Sony hype machine worked for the Emotion engine.) It's not very likely that Cell will achieve some of the amazing performance numbers that have been hinted at. Perhaps Sony/IBM/Toshiba has a revolutionary SDK that allows easy multithreading of sequential applications. But nothing like that has even come up in rumormongering.

Also, cache performance will be less predictable

[stereotype441]

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.

What you're saying is, for applications with poor cache performance, multi-core processors will be no better than single-core. Personally, I can live with that. Most of the processor developments of the last 10 years have favored applications with good cache performance.

What worries me is what happens when the OS schedules a process with good cache performance on one core, and a process with poor cache performance on the other core. Unless the cache does something special to prevent it, the "bad" process will completely deplete the cache, causing the "good" process to slow way down.

I recently worked on a real-time program for the Pentium IV, and we found that our worst-case performance was actually 4-5 times worse when hyperthreading was enabled, because our process would occasionally have to share its cache with something that was heavily memory-bound.

Desktop Apps: Parallelizable? I think so.

[LionKimbro]

It seems to me like you could parallelize most desktop apps.

An MP3 player: I would think you should be able to decode one second with one processor, and the next second with the other processor.

Word processor: I would think that parts of the boot process that do not require the other parts would be able to run independently. Two processors could check alternating lines until the whole document was checked.

Spreadsheets: I would think that the first half of a giant list could be handled by one processor, the second half of the giant list handled by the second processor.

3D graphics, non-accelerated: I would think that the screen could be cut in four, and one processor rendering each part.

Games: I would think the simulation could be divided into parts, and the different parts simulated by different processors.

Compiling, Parsing: If you have 40 files to parse, each processor can handle 10 files, so you would go roughly 4x as fast. Parsers aren't just for C++, parsers are found in just about every program that reads data from a disk or the Internet.

So it seems to me that we could make major performance gains, using multiple processors.

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?