Intel's RISC-y Business 225
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?"
finally??? (Score:3)
What the hell was the i960 then? Meatloaf?
Re:finally??? (Score:4, Insightful)
Re: (Score:3)
Re: (Score:2)
I thought the Paragon [wikipedia.org] used the i860-- a different, later chip.
Re: (Score:2, Funny)
Oh hell no. He'll do anything for love, but being an AMD aficiando, he won't do that.
Re:finally??? (Score:5, 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:
Re: (Score:2)
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.
...and z/Architecture (Score:2)
Actually
Re: (Score:2)
x86 compatible? (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 kil
Itaniums is **NOT** RISC (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, S
Re: (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 multi
Re: (Score:2)
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'
Re: (Score:2)
Re: (Score:2)
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.
Re: (Score:2)
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.
Re: (Score:2)
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
Re: (Score:2)
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]
Re: (Score:2)
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)
Re: (Score:2)
Re: (Score:2)
Yes, I read it, I was just pointing out it's going to be there (hopefully)
Re: (Score:2)
Because multiplications by a constant that's but an entry in a list having a couple of powers of two are all the rage these days.
Re:Itaniums is **NOT** RISC (Score:4, 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?
Re: (Score:3)
Re: (Score:2)
They STILL refuse to call it AMD64, which is what AMD calls the architecture
AMD called it x86-64. People called it AMD64 because IA64 was used for Itanium. AMD64 is misleading, since x86-64 is a relatively small set of tweaks to x86, yet it gives all of the credit (or, perhaps, blame) to AMD. Calling it x86-64 is vendor neutral and descriptive.
Re: (Score:2)
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
Re: (Score:2)
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
Re: (Score:2)
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
Re: (Score:2)
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)
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.
Re: (Score:2)
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
Re: (Score:2)
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
Re: (Score:2)
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.
Re: (Score:2)
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?
Re: (Score:2)
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.
Re:Itaniums is **NOT** RISC (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.
Re: (Score:2)
I'd like to add to your comment that the x86 front end, although hideously ugly compared to say, the 68k mentioned above, acts basically as an instruction compression engine.
So you have all the advantages of dense CISC-y instructions with a powerful RISC engine under the hood. Memory is still expensive and very small --> is a cache huge? is it cheap? No, and no. CISC-style instructions pack more easily into those tiny spaces, making cache misses less often and less expensive.
RISC didn't win. CISC di
Re: (Score:2)
Actually that's 4G address space in the original 68000.
The address registers were fully populated with 32 bits with the very first 68k. Only 24 address lines were actually connected (er, 23, was something odd with the odd addresses if I recall correctly), or 20 address lines in the 68008. Motorola (and Commodore, but NOT Apple) documentation said not to use the upper 8 bits of the address registers as they would one day be connected to address lines.
Lo and behold, the 68020 came out, and it had a full 32
VLIW != RISC (Score:2)
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")
Re: (Score:2)
a VLIW does multiple instructions in parallel, but each of these are usually pretty small and simple.
Intel not going after RISC? (Score:3)
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 was born as RITC (Score:2)
"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
Hmmm... (Score:3)
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...
Re: (Score:2)
Who in this day and age has predatory pricing?
Re: (Score:2)
IBM... IBM.... Oh and IBM....
Too bad that their top-end equipment is rather nice....
Re: (Score:2)
Re: (Score:2)
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.
Pay no attention to the man behind the curtain (Score:5, 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."
Re: (Score:2)
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.
Re: (Score:2)
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?
Re: (Score:2)
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.
Re: (Score:2)
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.
Re:Pay no attention to the man behind the curtain (Score:5, 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.
Re: (Score:2)
I don't remember hearing about this part... what significant chunk of instructions was removed?
Re: (Score:2)
Re: (Score:2)
Re: (Score:3)
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 wri
Re: (Score:2)
From what I've gathered they also have a form of "soft depreciation" where obsolete instructions are implemented in microcode, meaning the code still runs but much slower and a smart compiler wouldn't use those instructions anymore. That's pretty effective without breaking compatibility left and right.
Re: (Score:2)
As far as I know, all instructions are implemented in microcode... aside from in 6502s.
Re:Pay no attention to the man behind the curtain (Score:5, 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'.
Re: (Score:2)
More exactly, 894 opcodes, of which 3/4 are implemented in hardware. That's a bit less than 700 "classic" CISC opcodes.
Those are the figures for the newest z/Architecture CPU, the z10 microporcessor.
Re: (Score:2)
All recent IBM computers, from what I understand, are based on Power7. Or am I mistaken?
http://en.wikipedia.org/wiki/IBM_z196_(microprocessor) [wikipedia.org]
It's just spin (Score:2)
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
Re: (Score:2)
Re: (Score:2)
and POWER7 does seem to kick ass too, no?
Wow, what a terrible article (Score:2)
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?
Re: (Score:2)
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.
Re: (Score:2)
x86 isn't RISC if they decode microcode into smaller RISC like operations; an internal RISC. The outside instructions must be RISC; how they pull those off internally is not really part of it. Its a black box.
You do realize that even IBM's POWER chips (the final bastion of "RISC") decode instructions into uops too, right? So, are you willing to concede that POWER isn't RISC?
Hard to take the story seriously (Score:3, 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).
Re: (Score:3)
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
x86 are RISC since P6 (Score:5, 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"
It's not the CPU, it's the whole product. (Score:2)
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.
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
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
Re: (Score:2)
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.
Yawn.. (Score:2)
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
Re: (Score:2)
Re: (Score:2)
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"?
Re: (Score:2)
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.
Re: (Score:2)
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.
Re: (Score:3)
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
Good news everyone! (Score:2)
" 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!
Re: (Score:2)
Re: (Score:2)
it's always just a few years from evicting the RISC and mainframe architectures from their niches, no matter when you ask.
I think it's pretty damn close to evicting RISC today -- or at least, putting it into a niche, when I'd hardly have called RISC/Unix a "niche market" ten or more years ago. Mainframes are definitely a niche, but where they exist they are well entrenched.
Re: (Score:2)
Re: (Score:2)
Re: (Score:3)
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.
Re: (Score:2)
not to defend itanium, but by not foisting it on the compiler, you foist it onto an interpreter running on the CPU. Although the interpreter was wasteful enough, it had no opportunity to usefully work around the kind of dependence shown by:
mov xyz, %eax
add %eax, %ebx
sub %ebx, %ecx
or %rcx, %edx
It could only insert bubbles until the each op finished.
That was the crazy solution to the CPU:Memory speed imbalance. Multi cor
Re: (Score:2)
Why does it need bubbles? Can't an X86 keep its other ALUs busy simultaneously doing other instructions nearby that sequence using standard register renaming and opcode reordering techniques?
At any rate, from what I've read it's the branch prediction that really bottlenecks performance with today's deep pipelines. The advanced runtime branch prediction in the latest CPUs (which can see and react to the actual data at hand) just plain outperforms static compile-time branch analysis.
Re: (Score:2)
The mini example was a set of interlocked instructions, where the source operand of each is dependent upon the previous insn; thus everything is forced to be in-order. Compilers are smart enough not to do this, and the real difference in a 'wide' architecture is that it doesn't insert an interpreter (renaming, stalling, bubbling, etc..). The program ( compiler ) has to know that copying R1 to R2 has an N instruction latency before R2 is valid. If it tries to use R2 earlier, it gets junk.
The x86 trend,
Re: (Score:2)
The mini example was a set of interlocked instructions, where the source operand of each is dependent upon the previous insn; thus everything is forced to be in-order. Compilers are smart enough not to do this, and the real difference in a 'wide' architecture is that it doesn't insert an interpreter (renaming, stalling, bubbling, etc..). The program ( compiler ) has to know that copying R1 to R2 has an N instruction latency before R2 is valid. If it tries to use R2 earlier, it gets junk.
Yes, that sequence of instructions would have to executed sequentially whether for EPIC, Power, or x86, and compilers for any architecture know that they need to expose the maximum amount of ILP to the processor.
However only compilers for EPIC need to know the latency of every operation, the number of each type of functional unit, and any slot restrictions that may apply, so that the VLIW instructions can be assembled optimally. Because only by doing so can the ILP be exploited. Otherwise, like in the ex
Re: (Score:2)
125W is a gaming CPU nowadays.
Re: (Score:2)
125W is a gaming CPU nowadays.
An i5-2500 at stock speeds takes about 60W at full load.
But yeah, if you buy AMD then all bets are off.
Re: (Score:2)
Re:Are they also gonna shut down the gibson? (Score:4, 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.
Re: (Score:3)
What are you up to with all that power? I hope you're not planning to hack a Gibson...
Re: (Score:2)
Or more to the point: why organizations are picking RISCs at all?
Either Intel or author of RTFA is missing the point. Most organizations use RISC based systems which come as part of the business critical solutions. Hardware rarely accounts for 10% of the deal. Software licenses, deployment, testing and long term support are where the real money are.
Unless Intel introduces an architecture which it commits to support for at least one decade, I do not see a thing changing on corporate landscape. The pro
Re: (Score:2)
GPUs are routinely 256 bit for both integer and floating point instructions. The Cell processor of Sony PS3 fame has seven 128 bit SPEs (Synergistic Processing Elements), which are controlled by a 64 bit PPE (PowerPC Processing Element).
Re: (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.