Intel Plans to Overhaul Chip Architecture

Carl Bialik from the WSJ writes "Intel is planning to announce an entirely new chip architecture later this month at the company's developer forum, the Wall Street Journal reports. The company isn't discussing details yet, but it's expected that Paul Otellini will discuss a 'technology foundation designed from scratch to improve energy efficiency and make it easier to add more than two processors.'"

Comments

Not a user-perceptable change.

[sbaker]

On NPR this morning, they mentioned that Intel had said that a typical PC user wouldn't notice any change as a result of this new architecture. So one presumes this means no major instruction set revisions or anything.

AMD's dual core offering better than Intel's

[Anonymous Coward]

According to various preliminary benchmarks from The Tech Report, Tom's Hardware and AnandTech, AMD's desktop dual-core chips are significantly better than Intel's dual-core desktop offerings in terms of performance and power consumption. This is partly due to the fact that the AMD solution has a better inter-core communication architecture and lower memory latency.

Meanwhile, Intel's desktop dual core chips seem to offer much more aggressive pricing at this time. AMD's lowest price dual core chip, the X2 4200 is almost twice as expensive as Intel's lowest cost dual core processor. However, an interview with three AMD execs on PCPerspective.com claims that "AMD would eventually have lower priced Athlon X2 processors via the waterfall effect in the future".

Semantics

[frankie]

The word "multiprocessor" should be "multicore". They're talking about 4 or 8 cores on a single CPU, which might be nice for blades but not so useful for a laptop or a gamer.

And of course, Macheads note the phrase "performance per watt".

It's called i860 :-)

[Jeremiah Cornelius]

The Itanium will be re-christened "Xeon failure edition".

Intel i860

The Intel i860 (also 80860, and code named N10) was a RISC microprocessor from Intel, first released in 1989. The i860 was (along with the i960) one of Intel's first attempts at an entirely new, high-end ISA since the failed Intel i432 from the 1980s. It was released with considerable fanfare, and obscured the release of the Intel i960 which many considered to be a better design. The i860 never achieved commercial success and the project was terminated in the late 1980s. No known applications of the chip survive and it is no longer manufactured.

Technical features

Intel i860 MicroprocessorThe i860 combined a number of features that were unique at the time, most notably its VLIW (Very Long Instruction Word) architecture and powerful support for high-speed floating point operations. The design mounted a 32-bit ALU along with a 64-bit FPU that was itself built in three parts, an adder, a multiplier, and a graphics processor. The system had separate pipelines for the ALU, adder and multiplier, and could hand off up to three instructions per clock.

One fairly unique feature of the i860 was that the pipelines into the functional units were program-accessible, requiring the compilers to carefully order instructions in the object code to keep the pipelines filled. This achieves some of the same goals as RISC microprocessor architectures, where complex microcode, a sort of on-the-fly compiler, was removed from the core of the CPU and placed in the compiler. This led to a simpler core, with more space available for other duties, but resulted in much larger code, with negative impact on cache hits, memory bandwidth, and overall system cost. As a result of its architecture, the i860 could run certain graphics and floating point algorithms with exceptionally high speed, but its performance in general-purpose applications suffered and it was difficult to program efficiently (see below).

All of the buses were 64-bits wide, or wider. The internal memory bus to the cache, for instance, was 128-bits wide. Both units had thirty-two 32-bit registers, but the FPU used its set as sixteen 64-bit registers. Instructions for the ALU were fetched two at a time to use the full external bus. Intel always referred to the design as the "i860 64-Bit Microprocessor".

The graphics unit was unique for the era. It was essentially a 64-bit integer unit using the FPU registers. It supported a number of commands for SIMD-like instructions in addition to basic 64-bit integer math. Experience with the i860 influenced the MMX functionality later added to Intel's Pentium processors.

Performance (problems)

Paper performance was impressive for a single-chip solution; however, real-world performance was anything but. One problem, perhaps unrecognized at the time, was that runtime code paths are difficult to predict, meaning that it becomes exceedingly difficult to properly order instructions at compile time. For instance, an instruction to add two numbers will take considerably longer if the data is not in the cache, yet there is no way for the programmer to know if it is or not. If you guess wrong the entire pipeline will stall, waiting for the data. The entire i860 design was based on the compiler efficiently handling this task, which proved almost impossible in practice. While theoretically capable of peaking at about 60MFLOPS for the XP versions, hand-coded assemblers managed to get only about up to 40MFLOPS, and most compilers had difficultly getting even 10.

Another serious problem was the lack of any solution to quickly handle context switching. The i860 had several pipelines (for the ALU and FPU parts) and an interrupt could spill them and need them all to be re-loaded. This took 62 cycles in the best case, and almost 2000 cycles in the worst. The latter is 1/20000th of a second, an eternity for a CPU. This largely eliminated the i860 as a general purpose CPU.

Versions, Applica

Re:It's called i860 :-)

[stripes]

Intel i860

OkiData had a short lived Unix workstation product line based around these. I used them for a while.

One fairly unique feature of the i860 was that the pipelines into the functional units were program-accessible, requiring the compilers to carefully order instructions in the object code to keep the pipelines filled.

Only the floating point pipeline was directly exposed. Your first two FMULADD got garbage as the result, the third got the result of the first FMULADD... I *think* it also had a mode with more conventional stalling if you tried to do a 2nd FMULADD before the first completed (or if you used the result register).

The i860 also had a mode where you it would execute two instructions per clock, but you had to pair one integer instruction with one floating point instruction in that mode (and the pairing was static, if you put two integer instructions in a row the CPU would fault with an illegal instruction fault).

Paper performance was impressive for a single-chip solution; however, real-world performance was anything but.

It outperformed it's contemparary SPARC and MIPS CPUs by a considrable margin in FP, and by a small margin in integer heavy code. It was competitave with the HP snake systems (HPPA). It predated the Alpha, and was badly outmatched when the Alpha finally came out.

One problem, perhaps unrecognized at the time, was that runtime code paths are difficult to predict, meaning that it becomes exceedingly difficult to properly order instructions at compile time. For instance, an instruction to add two numbers will take considerably longer if the data is not in the cache, yet there is no way for the programmer to know if it is or not. If you guess wrong the entire pipeline will stall, waiting for the data.

That was extremely common at the time. The best the contemporary CPUs had was the IBM ROMP (pre-IBM POWER!) that had register scoreboarding so it didn't take a stall until the result register was used. It wasn't until five to seven years later that out-of-order CPUs were commercially available (and I can't remember who did them first, maybe the TI SuperSPARC? Or was it the MIPS R8000?)

Another serious problem was the lack of any solution to quickly handle context switching. The i860 had several pipelines (for the ALU and FPU parts) and an interrupt could spill them and need them all to be re-loaded. This took 62 cycles in the best case, and almost 2000 cycles in the worst. The latter is 1/20000th of a second, an eternity for a CPU. This largely eliminated the i860 as a general purpose CPU.

It seemed of handling disk interrupts, mouse movement, and even the relatively tiny FIFO for SoundBlaster 16 audio out. Maybe this was more a problem in theory then in practice? Clearly the i860 never got far in the embedded space though, and this couldn't have possibly helped.

The i860 did see some use in the workstation world as a graphics accelerator. It was used, for instance, in the NeXTDimension, where it ran a cut-down version of the Mach kernel running a complete PostScript. In this role the i860 design worked considerably better, as the core program could be loaded into the cache and made entirely "predictable", allowing the compilers to get the ordering right. This sort of use slowly disappeared as well, as more general-purpose CPUs started to match the i860's performance, and Intel lost interest.

I think it was also used as part of the "geometry engine" on SGI's Reality Engine product. There were something like 4 per GE, and up to 4 GEs on a Reality Engine, which was pretty impressive in 1991ish, but other then having something like 196 bits of memory per pixel falls pretty far short of today's $100 graphics cards.

Re:What does this mean?

[merpaholic]

Yep this is exactly what they've been building up to for a year or two now, ever since AMD trounced them so badly with performance per watt (and they realized there is no economical way they can scale a P4 based architecture past two cores).

I really do hope they keep the high performance per core that the pentium m architecture can offer. Having 8 cores is nice, but if they individually aren't very high performing, traditional apps like games are going to suffer badly on such an architecture.

I know game devs are being pushed this way anyways with the latest consoles, but it doesn't mean its going to work out that great (you can only parallelize something like a game engine so far before you hit severely diminishing returns or have a debugging nightmare on your hands). It'll be pretty important for quite some time to have a single core that really pump out those IPCs.

Re:My guess is a new x86

[jiushao]

AMD won the 64 bit war in the sense that their instruction set approach ended up on top, on the other hand Intel easily ships far more 64 bit x86's than AMD at this point.

Also it should be noted that the Pentium M is like the P3 in much the same way the K8 is like the K7. It is a very redesigned and improved core, so the ancestry in itself is no sign of it being an old design. As such I am not that sure that the new core wont be a Pentium M derivative as well, possibly simply a take on the Israeli Penium M by on of the US design teams.

Otherwise I very much agree with you, the CPU projects at Intel are probably all x86 at this point, so we will probably just get to see Intel "get back on the track" after the somewhat failed experiment with the P4.

Re:Obligatory obvious sighting

[blamanj]

It's pretty clear they did.

"A big emphasis is going to be performance per watt," -- Bill Calder, an Intel spokesman.

"When we look at Intel, they've got great performance, yes, but they've got something else that's very important to us. Just as important as performance, is power consumption. And the way we look at it is performance per watt. For one watt of power how much performance do you get? And when we look at the future road maps projected out in mid-2006 and beyond, what we see is the PowerPC gives us sort of 15 units of performance per watt, but the Intel road map in the future gives us 70, and so this tells us what we have to do." -- Steve Jobs, Apple CEO

Re:Attempt to scare IBM

[AKAImBatman]

Itanium didn't kill Alpha/MIPS/Sun.

Yes it did. When the hype was at it peak, it was actually preventing companies (such as the one I was working at during that time) from looking into Sun solutions, and HP made its infamous decision to ditch the Alpha line of processors in favor of the upcoming Intanic line.

At that time, Sun machines held a reasonable partiy with Intel's offerings, and Alpha NT desktops simply flew. Pentium III (Coppermine) was still in the development phase, and SGI was barely hanging on thanks to their N64 and NT Workstation deals.