Forgot your password?
typodupeerror
Intel Hardware IT

Intel's RISC-y Business 225

Posted by Soulskill
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?"
This discussion has been archived. No new comments can be posted.

Intel's RISC-y Business

Comments Filter:
  • by nurb432 (527695) on Monday September 19, 2011 @06:37PM (#37450044) Homepage Journal

    What the hell was the i960 then? Meatloaf?

    • Re:finally??? (Score:4, Insightful)

      by the linux geek (799780) on Monday September 19, 2011 @06:41PM (#37450100)
      A non-entity outside a few X terminals and RAID controllers.
    • Re: (Score:2, Funny)

      by Anonymous Coward

      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.

    • Re:finally??? (Score:5, Informative)

      by crankyspice (63953) on Monday September 19, 2011 @06:55PM (#37450274)

      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.

      • 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:

        Yeah, this is more about adding fault tolerance features than it is about anything that would qualify as RISC.

    • 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 kil

  • by Anonymous Coward

    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, S

    • by David Greene (463)

      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 multi

      • The SSE extensions are ugly, if you're including that in the category of x86.

        Lack of FMA support..

        Relatively starved for registers, although since it's not a load/store arch (another issue, imho) that matters less than it does in, say, ARM.

        There are also implementation issues (lack of a directory cache makes scalability suck), but architecturally, it's a pretty standard and slightly boring CISC. I don't quite understand all the hate it gets - it does tend to be slower than Power or z, and doesn'
        • Variable-length instructions are also kind of annoying. (Yes, replying to myself is bad form)
          • Why?

            When transistors were expensive, fixed-length instructions made some sense on die (although they tend to inflate system memory needs), but transistors are extraordinarily cheap today. Instruction decode is such a small part of a modern processor die, and so fast, that it makes no difference.

            Sure, the world would be aesthetically more appealing if the 68000 had won the microprocessor war rather than the 8086, but the performance difference at this stage of evolution would be infinitesimal.

            • I was always under the impression that the 68k vs 8086 architecture produced far less heat for the same throughput.

              If that was true then, and is still true, then current processors could be consuming less power under a different architecture and doing the same work. Given that my cell phone's ARM chip is more powerful than my old PC, and heats up far less no matter how much I gab on it might give some credence to the concept.

              • by Targon (17348)

                The thing is, times have changed, and you have to look back at the real-world issues, not just at low level "small" applications. The more complex things become, the less the CISC vs. RISC argument matters, especially when internally, CISC instructions get broken down into RISC-type instructions anyway.

                So, if you are doing something really complex, a well-written application done with CISC instructions won't be any better or worse than if you did the same thing under RISC. It is like the old idea that

          • by TheLink (130905)

            Variable-length instructions are also kind of annoying.

            Annoying to some, but useful in practice:
            http://en.wikipedia.org/wiki/ARM_architecture#Thumb-2 [wikipedia.org]

        • by JamesP (688957)

          The SSE extensions are ugly, if you're including that in the category of x86.

          Why? x87 is definitely ugly, but sse?

          Lack of FMA support..

          Like this? http://en.wikipedia.org/wiki/FMA_instruction_set [wikipedia.org]

          Relatively starved for registers, although since it's not a load/store arch (another issue, imho) that matters less than it does in, say, ARM.

          x86-64 improves on this

          There are also implementation issues (lack of a directory cache makes scalability suck), but architecturally, it's a pretty standard and slightly boring CISC. I don't quite understand all the hate it gets - it does tend to be slower than Power or z, and doesn't scale well, but the problems are implementation problems, not architectural ones.

          Problem is Intel has a lot of money. So even if Power or Alpha is 'better', Intel has the money to make it better (in general) than the competition (see Apple dropping the PPC because IBM couldn't make a mobile G5, amongst other things)

          • Did you read your own Wikipedia article? FMA isn't in any shipping Intel x86 CPU.
            • by JamesP (688957)

              Yes, I read it, I was just pointing out it's going to be there (hopefully)

          • by hedwards (940851) on Monday September 19, 2011 @09:03PM (#37451400)

            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?

          • x87 is definitely ugly

            x86 with it's stack based apparoach is certainly ugly. But (and here's a big but) it works internally at 80 bit for free which was fantastic. With careful coding on could write very effective and accurate single precision floating point code (or get better precision with doubles) essentially at no cost. It also supported loading and saving to memory of long-doubles so one could have hardware assisted super precision floating point numbers if needed.

            That was all very nice, but required

        • by ultranova (717540)

          Relatively starved for registers, although since it's not a load/store arch (another issue, imho) that matters less than it does in, say, ARM.

          One might argue that the whole concept of (general) registers is an ugly hack to get around limited or nonexistent cache controllers in old processors. It certainly isn't "elegant" by any stretch of imagination to divide general storage into two separate namespaces, and it also wastes memory with what are basically explicit cache control commands (load/store).

          Also, d

          • by Darinbob (1142669)

            There are new processors without cache too. RISC isn't just for high end systems. Most of the lower power chips for embedded market are RISC based, and this includes a wide variety of ARM CPUs. Even when you do have a cache you are often at the range of power where you don't want a very complicated instruction decoder because you're not building a top of the line PC. The point of RISC is to keep the entire machine design simple and straight forward and uniform, not just instruction decoding; the more sp

          • One might argue that the whole concept of (general) registers is an ugly hack to get around limited or nonexistent cache controllers in old processors.

            One might, but one could also argue that they're just another part of the memory heirachy (registers/L1/L2/L3/RAM/disk/stone-tablets). Registers usually require fewer cycles to access than even L1 cache, and can also do several more fast things, like parallel access of the two operands of some opcode and read-modify-write in a single cycle.

            Of course, many p

      • Why we hate x86 (Score:4, Insightful)

        by erice (13380) on Monday September 19, 2011 @07:34PM (#37450654) Homepage

        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.

        • by afidel (530433)
          Limited number of registers
          X86-64, with register renaming 16 is more than enough. AMD did a lot of research before settling on 16, more added significantly to complexity but on increased average program executing speed by low single digit percentages.

          Variable instruction length makes decode a headache
          Meh, who cares, the whole decoder stage is a couple percent of the non-cache transistor budget. It mattered more back in the PPro era when it was a significant amount of the budget but today it's peanuts
          • Meh, who cares, the whole decoder stage is a couple percent of the non-cache transistor budget.

            On the high end, the processor has a massive slew of very fast FPU and integer execution units, and a whole bunch of hardware dedicated to getting the absolute best use out of them possible (the out of order unit). The compute hardware tends to be very well utilised and the flops per Watt are actually rather good for a general purpose CPU. In that case, the decoder has little effect.

            On the low end, it is a very d

          • AMD did a lot of research before settling on 16, more added significantly to complexity but on increased average program executing speed by low single digit percentages.

            This is not constant, it depends a lot on the language. For a more dynamic language, like Lisp or JavaScript, more registers give you a significant benefit. For C, 16 is usually more than enough.

        • by Agripa (139780)

          No three register operations. This impacts pipelining because it is not possible not overwrite one of the source registers.

          I wonder about this one. Adding 3 register instruction support also means adding an additional set of read ports to the register file. Is it better to execute more instructions in parallel at a higher clock rate or have 3 register instructions?

      • by loufoque (1400831)

        I manage a high-performance library that contains, among others, a SIMD abstraction layer, not unlike Framewave or Accelerate (but better, of course ;))
        The SSE/AVX variants are clearly the most annoying to support, and are not really orthogonal at all.
        The PowerPC and NEON variants have much more straightforward implementations.

      • by Darinbob (1142669) on Monday September 19, 2011 @11:24PM (#37452280)

        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.

  • Itanium is not RISC in any sense of the word. It's pretty much the exact opposite of RISC - instead of using small, simple operations, it uses massive, complex instructions, often ones that produce multiple effects (most words produce three logical instructions).

    (Note for the acronym-deficient: RISC == "Reduced Instruction Set Computing", VLIW == "Very Long Instruction Word")

    • by loufoque (1400831)

      a VLIW does multiple instructions in parallel, but each of these are usually pretty small and simple.

  • by PCM2 (4486) on Monday September 19, 2011 @07:18PM (#37450504) Homepage

    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 [infoworld.com] 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 [infoworld.com] 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.

    • "RISC" and "freedom" are two of the most bent out of shape words in the computer science lexicon. When RMS designed "freedom" a new API, he fired off a scripting command to his global botnet s/freedom/free_as_in_beer/gggggggggggg/! but he missed the last "g" and it's been confusion ever since.

      RISC actually meant Reduced Implementation Team Computing. In practice it meant "this is very cool, but we are way behind the big boys, but maybe we can catch up through a policy of extreme simplification clothed in

  • by fuzzyfuzzyfungus (1223518) on Monday September 19, 2011 @07:29PM (#37450594) Journal
    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...
    • by bws111 (1216812)

      Who in this day and age has predatory pricing?

      • by Shinobi (19308)

        IBM... IBM.... Oh and IBM....

        Too bad that their top-end equipment is rather nice....

        • I'd say no. IBM isn't gaining its server marketshare with predatory pricing. Yes, their top-end equipment is nice, but IBM has also been cutting their prices regularly. (That's very easy to see in their mainframes, for example, where it's quite transparent.) Predatory pricing means less-than-superior stuff that is priced at superior rates. If I'd vote for anyone fitting that description, I'd vote for Oracle/Sun. Oracle has done nothing but squeeze the remaining Sun customers as hard as possible while doing
          • by Shinobi (19308)

            I'd define that more as malign parasite pricing.

            IBM is happy to price it high enough to make you feel it in your budget, but not high enough to negate the value of their products to your business.

  • by gstrickler (920733) on Monday September 19, 2011 @07:30PM (#37450608)

    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."

    • by LWATCDR (28044)

      Maybe that should be Intel's "next big thing". A Xeon that just supports the x64 instruction set drop real mode, drop segments, drop 286, drop the I/O instructions and make a pure 64bit ISA.

      • Great idea. Make it like a real RISC CPU, without all the x86 backwards compatibility addons. What a concept. Of course, then Intel couldn't claim "it'll run all you legacy software", and they might even have to admit it's a RISC design. And where would that leave them?

      • real mode, I/O instructions, etc. can't possibly take up that much of the transistor budget. Especially not when they can cram several cores + 30 MB of cache on one die.

        • by LWATCDR (28044)

          Wasted space is wasted space. Most of that code has been moved into microcode but why even bother with it all? Yes your Xeon will not run DOS apps but who cares.
          Where they really need to do this is on the Atom line.

  • The 64-bit x86 machines have been eating away at IBM's, HP's, and Sun's market share for years. Partnered with a good Linux distribution and VMWare, they're more than capable of taking on "the big boys."

    Oracle/Sun has been resting on their laurels for far too long. Time will tell whether Oracle manages to plug the holes in that sinking ship.

    HP's Itanium boxen have never had significant market share.

    That leaves IBM. And IBM doesn't sell you just a POWER based system -- they sell you the whole suite

  • First off, Intel went RISC in 1995 with the PentiumPro, the ISA is CISC, but the uISA is RISC. (Semantics. Bite me.)

    Second, Itanium is VLIW, not RISC.

    Third, who cares? Sun and IBM are phoning-it-in with this market, just look at the ISSCC proceedings for the past decade.

    I'm surprised Intel is even bothering. Is the market that big? Will it grow their bottom line? Anyone?

    • There was an article over at arstechnica [arstechnica.com] looking into why Itanium is still around. Apparently the Itanium market is worth $4 billion. Not exactly chump change.

  • by sl3xd (111641) on Monday September 19, 2011 @07:44PM (#37450734) Journal

    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).

    • by evilviper (135110)

      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 increm

  • by maitas (98290) on Monday September 19, 2011 @08:29PM (#37451164) Homepage

    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"

  • Sometimes I need to scale vertically and not horizontally. There are times when you need a single chassis with 200+ cores and 8TB of ram and hundreds of PCIe slots for IO. You can take my pSeries [ibm.com] from my cold dead hands.

    Intel solutions are getting there [hp.com] with 80 cores and 2TB of RAM.

    However, when it comes to moving IO, nothing beats big iron.

    • by afidel (530433)
      Unisys offers 6TB of ram, though still "only" 80 cores. Personally I think you probably need to seriously consider a redesign if you need to go bigger than that, but in the enterprise space that kind of development effort normally costs more than buying a couple million dollar box and the couple hundred thousand a year support contract to go along with it. I guess I'm fortunate in that my biggest workload runs well on a 16 core box with a couple SSD's for the main tables.
      • Agreed, I can't think of very many instances where a given type of workload can't be distributed for less outlay of cost over big iron servers. It does depend, but then again, full ACID in database servers isn't usually necessary either.
        • So if one woman can produce one baby in 9 months, does that mean if you assign 9 women to the job you'll get one baby delivered in one month?

          There are lots of workloads that are inherently single threaded (and probably always will be). If you've got a bigger, faster, more powerful CPU (or vertically scalable server, which fast shared memory and super fast I/O), that'll be a better fit for those sorts of workloads. IBM zEnterprise mainframes are the preeminent examples of the type, and they're selling extre

          • by Shinobi (19308)

            Another reason the z10 sells well is native BCD calculations, meaning that in some tasks coupled with their massive I/O, they are so much faster than Intel/AMD offerings that you'd need AT LEAST 10-15 times more Intel/AMD hardware, with the requisite floorspace, networking, power cabling, cooling and UPS's for all that to compare merely on the theoretical side. In practice, it can get even worse, since the tasks don't parallellize well.

  • by bored (40072)

    Anyone buying POWER or SPARC is a lost cause anyway. Sure Intel might gain a few sales, but frankly the RISC volumes are pretty small and a huge number of them are "stuck" because they have existing applications that they are unwilling/unable to port to an alternative. Or the IT guys are religious zealots. This is the same reason you find AS400s/i5, Nonstops, OpenVMS, zos, etc machines running in data centers the world over. Its not because those OS's or the hardware actually provide some huge benefit that

    • by Relayman (1068986)
      Nothing runs Linux like PowerPC. Nothing can handle virtualization like PowerPC. Intel only dreams of doing what IBM does every day.
      • by styrotech (136124)

        POWER and PowerPC are two different things.

        Maybe you meant "nothing runs Mac OS 9 like PowerPC"? Or "nothing can hold up Steve Jobs plans like PowerPC"?

    • by Shinobi (19308)

      You're just showing how little you know.

      When it comes to for example IBM's mainframes, for the jobs where they are used, they massively outperform any Intel/AMD cluster both in raw performance and in operational costs over the years.

      • by bored (40072)

        That is what IBM tells you, try generating your own numbers for once instead of spouting the ones the IBM sales guy tells you.

        Sure, some of those machines have very high raw performance numbers... But a very large percentage of the installs actually partition that expensive machine up into a dozen or so smaller system images. Which of course negates a lot of the argument about operational costs because the majority of long term operational costs is related to the number of system images you are maintaining.

        • by Shinobi (19308)

          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 th

  • " days of IT organizations being forced to deploy expensive, closed RISC architectures for mission-critical applications are nearing an end"

    Indeed, the days of IT organizations being forced to deploy expensive, closed, sorta-RISC is upon us! Happy days!

The IQ of the group is the lowest IQ of a member of the group divided by the number of people in the group.

Working...