Slashdot Mirror

← Back to Stories (view on slashdot.org)

Intel's RISC-y Business

Posted by Soulskill on from the doubling-down dept.

Esther Schindler writes "With the Xeon 7600 line, Intel is finally using the 'R' word: RISC. With the new chips, Intel is targeting the mission-critical market dominated by Sun SPARC and IBM Power, a first. Can the Xeon E7 processor deliver Intel's final blow to the RISC market, which includes its own Itanium? 'With the launch of the E7 earlier this year, it seemed Intel was finally ready to make its final push, calling out RISC by name. "The days of IT organizations being forced to deploy expensive, closed RISC architectures for mission-critical applications are nearing an end," said Kirk Skaugen, vice president and general manager of Intel's Data Center Group, in a statement announcing the E7 line. Bold words.' Andy Patrizio interviews several experts; what do you think?"

27 of 225 comments (clear)

  1. finally??? by nurb432 · · Score: 2

    What the hell was the i960 then? Meatloaf?

    --
    ---- Booth was a patriot ----
    1. Re:finally??? by the+linux+geek · · Score: 3, Insightful

      A non-entity outside a few X terminals and RAID controllers.

    2. Re:finally??? by Anonymous Coward · · Score: 2, Funny

      What the hell was the i960 then? Meatloaf?

      Oh hell no. He'll do anything for love, but being an AMD aficiando, he won't do that.

    3. Re:finally??? by crankyspice · · Score: 4, Informative

      Intel has had several RISC chips on the market at various times; the i960, the i860, even ARM designs (XScale).

      TFA doesn't say Intel is going to be bringing out RISC technology, though, just that it's "taking aim" at markets that are still RISC strongholds:

      With the launch of the E7 earlier this year, it seemed Intel was finally ready to make its final push, calling out RISC by name. “The days of IT organizations being forced to deploy expensive, closed RISC architectures for mission-critical applications are nearing an end,” said Kirk Skaugen, vice president and general manager of Intel's Data Center Group, in a statement announcing the E7 line.

      Bold words. Can the E7 really dethrone UltraSparc/Power/PA-RISC and, of course, Intel's own Itanium processors? Intel thinks so.

      --
      geek. lawyer.
    4. Re:finally??? by NJRoadfan · · Score: 2

      It also powered the HP LaserJet 4 series of printers.

  2. Itaniums is **NOT** RISC by Anonymous Coward · · Score: 2, Interesting

    Just have to point out, Itanium is absolutely NOT RISC in any sense of the word. Other than that, it is rather unfortunate that Intel has the most money to develop new processes (i.e. die shrinks), because the actual Intel instruction set is quite inelegant, both from a programmer standpoint, and from the standpoint of implementing it in silicon. I can't argue with overall performance, if Intel tops performance than that is that; but, the fact of the matter is that any of these RISC designs (Power, Sparc, the PA-RISC, Alpha, ARM...) would clean Intel's clock if they had access to the type of processes Intel does.

    1. Re:Itaniums is **NOT** RISC by David+Greene · · Score: 2

      the actual Intel instruction set is quite inelegant, both from a programmer standpoint

      I've always been curious about this kind of statement. I hear it a lot. While I understand the complexities of silicon implementation (finding instruction lengths and decode are a PITA), I've always thought the ISA itself was rather elegant. Yes, there is cruft that could be dropped and AMD did some of that with X86-64, but overall, the day-to-day instruction set is mostly orthogonal and has a fairly regular encoding. GPR shifts, MUL and DIV are a bit quirky and the lack of a packed 64-bit integer multiply is an almost unforgivable sin, but overall, I rather like it.

      What are the things you would like to see changed? We need specifics to have an interesting discussion. :)

      --

    2. Re:Itaniums is **NOT** RISC by hedwards · · Score: 3, Insightful

      As far as x86-64 goes, isn't that mainly because AMD trotted out a 64bit processor that was backwards compatible with 32bit programs and whomped Intel's 64bit processors which required specially compiled programs to work with?

    3. Re:Itaniums is **NOT** RISC by FreonTrip · · Score: 2

      I think - in a colossal effort to refuse to acknowledge that they're eating their competitor's dog food - Intel changed from the awkward and ungainly EM64T to Intel 64 for nomenclature. The only differences between the two amount to a tiny number of instructions AMD deprecated, then inexplicably brought back after Intel had implemented the rest.

    4. Re:Itaniums is **NOT** RISC by Darinbob · · Score: 5, Informative

      The x86 architecture is horribly unorthogonal. Each register in the basic set has it's own special purpose which are required by some instruction or other, thus no register is general purpose. The instruction set is clearly CISC with variable instruction size, multiple ways to do the same operation, etc. So many instructions operate directly on memory instead of being a load-store architecture with a lot of registers. It was designed to not take up a lot of program space as opposed to being efficient to decode and execute. It's really not that elegant compared to even other CISC chips of it's era (68000 for example).

      Ie, you've got the EAX "accumulator", EBX base register, ECX counter register, EDX for division, SI source index, DI destination index, etc. The closest to a general purpose data register is EAX, and EBX is sort of like a general purpose address register, but there aren't any pure general purpose registers that can be used for anything. And so your programs tend to spend a lot of time shuffling stuff into the register that's needed or using a memory location directly as an operand.

      But that make sense since the x86 instruction set was more an evolution than a design. Start with 4004 (first microprocessor), go to 4040, 8008, 8080, 8085, then finally 8086. Along the way every new CPU was vaguely compatible (either very similar instructions, or you could write a program to convert existing code to the new CPU). Along that evolution the instruction set grew. It was important in the 8080 era to save program space since RAM was expensive. Without a cache it meant that instruction fetching was just as expensive as fetching a memory operand. The more complex instruction sets meant that most CPUs along this line were microcoded, but the performance hit from that wasn't so big since most of these early chips weren't meant to be speed demons but were for low cost designs (low cost relative to the big computers anyway). Microcode meant you could add a new instruction easily without a lot of design overhead.

      The snag is that along the way RAM got cheaper and the need for performance become the key feature. But Intel adapted because in the Pentium and later these chips really are RISC under the hood. They convert the x86 instructions on the fly into a something that's a step up from microcode which are much more suitable for a pipelined or superscalar architecture. So basically everyone uses RISC these days, it would be foolish not to. But Intel is a prisoner of it's own design. It can't change the instruction set without breaking compatibility. Every time it has a better architecture it's a flop because that's not PC compatible and they're competing with others for the same product space.

  3. Re:RISC? by Panaflex · · Score: 2

    It's definitely a RISC processor set... the problem with the Itanium was the EPIC instruction set. A complete waste of time, as the compiler is asked to generalize decisions about the thread and multi-core state of the machine during program compilation.

    I mean... who the hell thought that was a good idea? It makes for a nice benchmark, but a terrible architecture. Bring us back the Alpha chip... make it a 64 core monster.

    --
    I said no... but I missed and it came out yes.
  4. Intel not going after RISC? by PCM2 · · Score: 2

    Ehhh? The summary seems a little cockeyed. Does anyone on /. really believe this is the first time Intel is using "the R-word'? Intel has been positioning its chips against RISC for ages. Yes, in the past it was using Itanium as its "high end" chip, because it was more directly competitive with IBM's and Sun's offerings (and it probably had bigger margins). But here's an article from 2004 which claims "Intel markets the [Itanium] chip as a replacement for RISC processors from companies like Sun and IBM" -- pretty much exactly what the summary is claiming is "a first" here.

    If anything, Intel has chosen not to throw around a lot of rhetoric about x86/x64 as a replacement for RISC servers out of deference to its partners. Back in 2007, you will recall, Sun started marketing x86 servers in addition to its RISC product line. How would it look if Intel went around claiming x86 was a replacement for Sparc servers? Intel left it to Sun's marketing to clarify where it saw its x86-based products in comparison to Sparc. Similarly, around the same time HP was putting out x86 and Itanium servers -- Intel wasn't going to muddy the waters there, certainly.

    On the other hand, Red Hat and Dell would certainly talk about Linux servers (read: x86) as replacements for proprietary Unix servers (read: RISC). So it's certainly not like this is the first time anyone floated the idea, and it's certainly not like Intel has backed off from competing with RISC at any point in the past, no matter which component gets positioned against RISC chips.

    --
    Breakfast served all day!
  5. Re:Are they also gonna shut down the gibson? by crankyspice · · Score: 3, Funny

    RISC architecture is gonna change everything!

    I'm still waiting for the P6 chip. Triple the speed of the Pentium. With a PCI bus, too.

    --
    geek. lawyer.
  6. Hmmm... by fuzzyfuzzyfungus · · Score: 2

    I'd say that Intel is playing pure weasel-words with their "expensive, closed, RISC" line...

    Are most of the Big Serious Iron RISC/*NIXes available from only a single vendor, often one with rather predatory pricing philosophies? Yeah, arguably so.

    However, x86-with-Serious-RISC-level-RAS-features isn't exactly a vibrant competitive market... It's pretty much Intel and, um, *crickets*...

    The low end of x86 actually has a number of weirdo 3rd parties, in addition to the big two, the middle of the market is a duopoly, but a pretty feisty one; but x86 high enough to compete with the classical serious RISC stuff on its own ground(as opposed to on the grounds of architectural changes that favor big clusters of expendable servers) is basically a single-shop thing. AMD has some pretty decent x86 servers; but Intel is the one bringing the itanium RAS stuff down to their Xeons.

    Arguably, the lower end of RISC is substantially more competitive than that of x86: there are some huge number of ARM licencees, a whole bunch of random MIPS stuff floating around, and so forth. Only the middle-performance area, which is an effective duopoly(VIA? right...), but a pretty cutthroat one, where most people find their price/performance sweet spot, really makes x86 look like a competitive market at all...

  7. Pay no attention to the man behind the curtain by gstrickler · · Score: 4, Informative

    Remember all those slow, complex, cumbersome instructions from the 80x86, they're still around, just moved to microcode while all the simple stuff is implemented using the same techniques pioneered by RISC designers. But since this is a server, you're probably running x64 code, which was designed to be much more RISC like in the first place.

    So, I guess the real message is "Replace your non-Intel based RISC systems with Intel based RISC systems. But wait, don't answer yet! As an added bonus, Intel chips have extra hardware added so they can run all your old x86/CISC code too, that way we can pretend they're not RISC systems based on the AMD designed x64 instruction set."

    --
    make imaginary.friends COUNT=100 VISIBLE=false
    1. Re:Pay no attention to the man behind the curtain by gstrickler · · Score: 4, Informative

      You do know that x64 has a simplified instruction set, simplified addressing modes, larger registers, a larger logical register file, and a much larger physical register file with register renaming, right?

      It still supports the full x86 instruction set when running in "legacy mode", but in "long mode", it only supports a subset of instructions, and supports only 16, 32, and 64 bit registers and operands (no 8 bit support), and standardizes the instruction lengths to provide better memory alignment, and simplified instruction processing. And in either mode, all the instructions are converted to one or more macro/micro-ops before running on the "real" RISC core.

      You knew all that, right? Of course you did.

      --
      make imaginary.friends COUNT=100 VISIBLE=false
    2. Re:Pay no attention to the man behind the curtain by bws111 · · Score: 4, Informative

      IBM mainframes are z/Architecture machines, and they are certainly not RISC. z/Architecture has about 1000 opcodes, including things like 'Square Root' and 'Perform Cryptographic Operation' and 'Convert Unicode to UTF-8'.

    3. Re:Pay no attention to the man behind the curtain by gstrickler · · Score: 2

      Actually, while those extra gates do take up die space, they're probably fully power gated, drawing no power and producing no heat when in "long mode". How much die space is probably small, remember a 486 only had around 1M transistors, including it's cache. Even if there are 10M transistors dedicated to maintaining compatibility in a modern CPU, that's ~1% of a modern CPU.

      x64 mode already breaks backwards compatibility with quite a bit of x86 code, particularly x86 code that isn't 32-bit code. Anything written before the 386 was introduced wont run under 64-bit mode, almost nothing written before Windows 95 came out will run, and a whole bunch of stuff written before Windows XP came out won't run. There's some newer stuff that won't run, but by the time XP started shipping most software was moving to a 32-bit model, and so will likely run (some may require some minor tweaks and/or a recompile). So, most software written in the last 8-10 years should be ok, but most software written before '95 won't, and between '95 and 2003 it's hit and miss. They could probably save more power and/or get better performance by removing some more instructions and breaking compatibility even more, but it's probably not worth it to most users to have to replace so much software. Deprecating instructions today and removing them 6-10 years from now might be viable, but only if the customers see the benefits (as they are seeing with the move to 64-bit), and I don't see that happening unless ARM starts taking a lot of the server market from Intel.

      --
      make imaginary.friends COUNT=100 VISIBLE=false
  8. Why we hate x86 by erice · · Score: 3, Insightful

    I've always been curious about this kind of statement. I hear it a lot. While I understand the complexities of silicon implementation (finding instruction lengths and decode are a PITA), I've always thought the ISA itself was rather elegant. Yes, there is cruft that could be dropped and AMD did some of that with X86-64, but overall, the day-to-day instruction set is mostly orthogonal and has a fairly regular encoding. GPR shifts, MUL and DIV are a bit quirky and the lack of a packed 64-bit integer multiply is an almost unforgivable sin, but overall, I rather like it.

    What are the things you would like to see changed? We need specifics to have an interesting discussion. :)

    Limited number of registers
    Instructions that require certain registers or a certain subset of the registers
    No three register operations. This impacts pipelining because it is not possible not overwrite one of the source registers.
    Variable instruction length makes decode a headache

    Lots of really bad stuff that isn't used much by modern code by still must be maintained for compatiblity: segments, 286 protection, IO instructions, etc.

    I've wondered sometime what attitudes would be if a more likable contemporary instruction set had won. VAX and 68000, for instance, are much more palatable to program but they have performance flaws that are probably worse than x86.

  9. Hard to take the story seriously by sl3xd · · Score: 2, Insightful

    We live in a post-RISC world. Nearly every modern processor's "core" use the major innovations of a RISC chip. The size of the instruction set is of little importance; many so-called "RISC" architectures (such as Power) have a larger instruction set than the "CISC" x86_64.

    The main issue that spawned the development of RISC (that instruction sets were getting so large and unwieldy that instruction decode would take the lion's share of a die's transistors) turned out to be less of a problem than anticipated. At the time, many CISC chips (VAX in particular) were implementing high-level programming features in the architecture's assembly language.

    Nearly all of us have decided that efficient compilers have made a high-level, expressive assembly language unnecessary.

    Another factor is that modern processors are superscalar, with multiple execution pipelines per core - one instruction decoder then feeds several pipelines, which further reduces the relative size of the instruction decode.

    However, modern chips do implement (at least internally), other "core" ideals of the RISC processor:
    - Numerous registers
    - Load/Store memory access
    - Multi-stage Pipelines
    - One instruction per clock tick (ie. keep the complexity of an instruction down to what can execute in one tick - if something takes more than one tick, break it down into smaller pieces).

    The one thing that the so-called "RISC" chips have historically been known for is dependability: The machines that use them don't crash. This requires more than just a good CPU: It requires good hardware in general, and a good operating system. The "RISC" vendors - such as Sun (now Oracle), IBM, HP and SGI, control the quality of the entire system - from the electrical components, to the chassis, to the airflow in the chassis. Even the datacenter's abilities (power, cooling capacity, airflow) are specified.

    There are a lot of things that go into making a system that's mission-critical, and the CPU is a small part of the equation (and usually is the least troublesome). Putting an CPU on a motherboard doesn't give me guarantees about airflow, power reliability, I/O stability and speed, vibration tolerance, nonblocking I/O, and reliability - to say nothing about core OS stability.

    Intel isn't interested in doing anything other than selling chips. Unless Intel is willing to take upon themselves a whole-system approach - covering everything from the chassis, cooling and airflow, power supply, motherboard, and core operating system - they'll never play in the league.

    Making a mission-critical system is left to others who use Intel's chips, such as HP's high-end Itanium line, and SGI's Altix and Altix UV systems (using Itanium and x86_64).

    --
    -- Sometimes you have to turn the lights off in order to see.
    1. Re:Hard to take the story seriously by evilviper · · Score: 2

      There are a lot of things that go into making a system that's mission-critical, and the CPU is a small part of the equation (and usually is the least troublesome).

      That's not really true. The lack of high-end features in x86 CPUs was the weak link in getting reliable servers for some time. And when those features started being added, they appeared in servers almost immediately. Even now Xeons lag significantly behind proprietary CPUs, and Intel is just once again on a marketing push to claim every incremental improvement suddenly makes them ultra-reliable.

      Also, the main place all these features need to be is in the chipsets, which Intel also manufactures.

      --
      Slashdot gets worse every day... Pipedot: News for nerds, without the corporate slant
  10. x86 are RISC since P6 by maitas · · Score: 4, Informative

    When the PentiumPro came along (the first P6 processor) it used internal RISC architecture, and all Intel x86 cores from that time to today stilldecode the x86 instructions in what intel calls r-ops (risc operations) and then it processes them.

    Nevertheless the part where Intel says "The days of IT organizations being forced to deploy expensive, closed RISC architectures" it is a lie. You can get the UltraSPARC-T2 Verilog code to make those chips yourself and hte code is GPL. You can't do that with any Intel processor. So Intel processors are the really "closed" processor. It is true that RISC processor are more expensive, but it has nothing to do with "closed"

  11. Re:Are they also gonna shut down the gibson? by hedwards · · Score: 2

    What are you up to with all that power? I hope you're not planning to hack a Gibson...

  12. Re:RISC? by Anarke_Incarnate · · Score: 2

    125W is a gaming CPU nowadays.

  13. x86 compatible? by unixisc · · Score: 2

    That, as well as the i860 too (which was even earlier than i960, but used in the Intel Paragon supercomputer). And this new CPU - is it x86 compatible? Or are we about to see a new instruction set?

    Even aside from those, Intel had rights to the DEC Alpha once it made its settlement w/ DEC. That was still #1 in performance when Compaq/HP killed it. If this new CPU is going to be incompatible w/ x86, I don't think it has any more of a future than the Itanic, much less EM64.

    HP was out of its mind to kill PA-RISC for Itanium. Compaq was out of its mind not to aggressively push Alpha in the NT market, and extend OVMS. All RISC vendors - IBM and Oracle - should learn the lessons from Itanium and not let Intel shoot down superior and/or well established RISC platforms like Power or Sparc in favor of something totally new. And does this make Itanium an HP-only CPU, dropping even the Intel backing?

    Also, what exactly is closed RISC architectures today? OpenSparc is available, OpenPower is available, and even MIPS, as much as I understand it, is freely licensed that there are so many organizations using it. With 3 open RISC architectures, why does anyone need another?

  14. Re:WTH? Is this an Intel ad? by Ant+P. · · Score: 2

    Nah, it's just Intel admitting they lost the mobile market to ARM and the value-for-money market to AMD, so all they have left is the ricer and more-money-than-sense market.

  15. Re:Yawn.. by Shinobi · · Score: 2

    Actually, it is the numbers we generated on our own that I'm running. For the project I worked on, a single loaded mainframe outperformed the Altix, off-the-shelf Dell cluster and a couple of other solutions the client looked at. Hardware support for BCD and the massive external I/O.

    As for partitioning, in secure environments, the low overhead and the ease with which you can do it on IBM's mainframe reduces the operational costs.

    The biggest operational cost over the years is floorspace+cooling+power, and that's where the real gain in, and that's where my clients really learned the difference. The primary and the backup system, complete with their storage arrays, cost just slightly more than just the primary off-the-shelf Dell system when factoring in the number of spares that have to be running just to keep the primary system operational in case of failures. Add to that the state of immaturity of reliable failover systems in the Linux world and the operational costs skyrocket.

    As for Westmere, it has nice performance for FP math or non-BCD integer math, and it has nice I/O to RAM/local devices, but external I/O is.. lackluster compared to what a z10 can do.

    My personal workstation is a dual quad-core Xeon with a crapload of RAM, because it fits the tasks I personally work with better than a z10 would, but if I were to actually work fulltime with the sort of stuff my last client uses their systems for, it'd be mainframes all over, because the performance and reliability for those tasks is just unparallelled by anything x86-based.