Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Intel's RISC-y Business

Soulskill posted about 3 years ago | from the doubling-down dept.

Intel 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?"

cancel ×

225 comments

Sorry! There are no comments related to the filter you selected.

finally??? (2)

nurb432 (527695) | about 3 years ago | (#37450044)

What the hell was the i960 then? Meatloaf?

Re:finally??? (3, Insightful)

the linux geek (799780) | about 3 years ago | (#37450100)

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

Re:finally??? (1)

kungfuj35u5 (1331351) | about 3 years ago | (#37450156)

Heh slow raid controllers at that

Re:finally??? (2)

NJRoadfan (1254248) | about 3 years ago | (#37450462)

It also powered the HP LaserJet 4 series of printers.

Re:finally??? (0)

Anonymous Coward | about 3 years ago | (#37451376)

Didn't spend much time using supercomputers in the 90s eh?

Intel Paragon used the i960 in a massively parallel architecture.

The coolest thing about it was the led bar graphs on each processor node. Vertical was cpu load, horizontal was inter-node communication. You could instantly see crappy code. better yet, you could make designs and such on the front panel by increasing/decreasing comm/processor. Good times.

Re:finally??? (2, Funny)

Anonymous Coward | about 3 years ago | (#37450122)

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??? (4, Informative)

crankyspice (63953) | about 3 years ago | (#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.

Re:finally??? (1)

Jah-Wren Ryel (80510) | about 3 years ago | (#37450400)

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.

Re:finally??? (0, Interesting)

Anonymous Coward | about 3 years ago | (#37451220)

... closed RISC architectures ???

What the effing bull crap is that? RISC is an open standard. I am reminded of the "dim wits at the top of the Corps" /. article from a few days ago.

Re:finally??? (0)

Anonymous Coward | about 3 years ago | (#37451684)

What the hell are you talking about? RISC isn't a "standard" of any sort. It's more like an architectural style, used by many very different companies (MIPS, Sun, etc.)

Re:finally??? (0)

Anonymous Coward | about 3 years ago | (#37451082)

Meatloaf? No. Chopped Liver? Yes.

Re:finally??? (1)

dvdwholesale3 (2432850) | about 3 years ago | (#37451760)

blu raydvds wholesaler p90x [slashdot.org] is an extremely intense program.Sheer will and determination may get you to the finish line,but to achieve the best results,youâ(TM)ve got to have the proper quality and quantity of nutrition.We make these supplements optional,so you have a choice.But know that P90x supplements were designed for this program and will supply your body with the necessary nutrients to give you added strength energy,and stamina for each workout. As you may notice from the math on the following pages, blu raydvds wholesaler p90x [slashdot.org] is not bulit around adaily âoecalorie deficitâ for weight loss like the general Beachbody plans found in Power 90,Kathy Smitsâ(TM)s Project :You!Type 2,and Slimin 6.Itâ(TM)s important that you understand why ,so you have the right training mentality with this program ,with the right expectations.

RISC was never an architecture (1)

Osgeld (1900440) | about 3 years ago | (#37450098)

It is a design philosophy, you the chip makers are the ones who made it expensive and closed (even though its not our day to day CPU's have been "RISC" for a while now) .

RISC? (0)

Anonymous Coward | about 3 years ago | (#37450128)

I don't believe itanium is considered RISC, unless you're selectively redefining RISC to mean anything that's not x86/x86-64.

Re:RISC? (0)

the linux geek (799780) | about 3 years ago | (#37450142)

How does Itanium not qualify? It's a load-store ISA with fixed-length instructions. Is that not the normal definition of RISC?

Re:RISC? (1)

Relic of the Future (118669) | about 3 years ago | (#37450308)

Because it's EPIC. I guess you could argue whether having multiple fixed-length instructions is "different enough" to justify calling it something different, but Intel's marketers (and at least some of their engineers) thought so.

Re:RISC? (1)

the linux geek (799780) | about 3 years ago | (#37450346)

I'd say it qualifies as both RISC and EPIC/VLIW. It fits both categories. They aren't mutually exclusive.

Re:RISC? (2)

Panaflex (13191) | about 3 years ago | (#37450328)

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:RISC? (1)

i.am.delf (1665555) | about 3 years ago | (#37450866)

My god could you imagine the heat dissipation of a 64 core alpha processor. I had a desktop with an EV7 in it. That thing was a space heater. I just looked it up. The spec was 125W for that thing.

Re:RISC? (2)

Anarke_Incarnate (733529) | about 3 years ago | (#37451616)

125W is a gaming CPU nowadays.

Re:RISC? (1)

0123456 (636235) | about 3 years ago | (#37451720)

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:RISC? (1)

mevets (322601) | about 3 years ago | (#37451050)

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 core has won the day, but modern high speed processing (eg. GPUs) often use this architecture.

Re:RISC? (1)

Waffle Iron (339739) | about 3 years ago | (#37451264)

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:RISC? (1)

mevets (322601) | about 3 years ago | (#37451654)

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, since Prescott, has been shorter pipelines + more cores to break the bottleneck.

CISC (0)

Anonymous Coward | about 3 years ago | (#37450188)

"expensive, closed RISC architectures"

Is the E7 less expensive or closed, or just less RISC?

Itaniums is **NOT** RISC (2, Interesting)

Anonymous Coward | about 3 years ago | (#37450190)

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.

Re:Itaniums is **NOT** RISC (0)

Anonymous Coward | about 3 years ago | (#37450362)

I was thinking the same thing. I recall Itaniaum was VLIW (http://en.wikipedia.org/wiki/Very_long_instruction_word), where the onus is on the compiler to create massive single instructions that do a great deal in a single clock tick. While, from the compiler's standpoint, there are RISC like issues to contend with-- it is otherwise very much the opposite of RISC.

Re:Itaniums is **NOT** RISC (2)

David Greene (463) | about 3 years ago | (#37450410)

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

Re:Itaniums is **NOT** RISC (1)

the linux geek (799780) | about 3 years ago | (#37450454)

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't scale well, but the problems are implementation problems, not architectural ones.

Re:Itaniums is **NOT** RISC (1)

the linux geek (799780) | about 3 years ago | (#37450484)

Variable-length instructions are also kind of annoying. (Yes, replying to myself is bad form)

Re:Itaniums is **NOT** RISC (1)

FrankSchwab (675585) | about 3 years ago | (#37450592)

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:Itaniums is **NOT** RISC (0)

Anonymous Coward | about 3 years ago | (#37452208)

It does make a difference, particularly for energy efficiency. This is why Intel's newer processors contain a significant complexity in auop cache, to bypass x86 decoders. In lower end devices, "x86 tax" is said to be anywhere from 10-20%, which is huge.

Variable length instructions are actually good, to improve code density, but they should be done in a sane way. Thumb 2 is a reasonable example.

Re:Itaniums is **NOT** RISC (0)

Anonymous Coward | about 3 years ago | (#37450990)

Agreed on SSE extensions, FMA support was originally included in AVX, but has since been removed, don't ask me why.

Register starvation was a real problem on 32 bit version, generated code was spilling to and reloading from stack slots like mad, even for fairly simple code, and this ate into usable memory bandwidth. 64 bit gives 8 or 9 (in relocatable code) more general purposes registers and is much less prone to the reload hell. Actually 64 bit mode has the same number of GPR as Z and ARM (actually more since PC is separate on x86) . Thankfully the x87 floating point stack nightmare is a thing of the past.

Implementation problems? Intel has by far the largest budgets and implementation teams in the industry, and also the best processes (although I have a feeling that their lead is shrinking a bit). The real problem is that the architecture is now reaching the limit, after all the latest Core are not that different conceptually from the Pentium Pro, over 15 years old now. Only the P4 was really different, but it was a mistake.

I believe that the real test for x86 will be when Intel can no more come with a new process shrink every 2 years. This might be around 2018.

Re:Itaniums is **NOT** RISC (1)

JamesP (688957) | about 3 years ago | (#37451062)

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:Itaniums is **NOT** RISC (1)

the linux geek (799780) | about 3 years ago | (#37451390)

Did you read your own Wikipedia article? FMA isn't in any shipping Intel x86 CPU.

LEA? (0)

Anonymous Coward | about 3 years ago | (#37451568)

got one word for you, buddy. LEA.

Re:LEA? (1)

tibit (1762298) | about 3 years ago | (#37451682)

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 (3, Insightful)

hedwards (940851) | about 3 years ago | (#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?

Re:Itaniums is **NOT** RISC (1)

Anarke_Incarnate (733529) | about 3 years ago | (#37451626)

Yes. Intel wanted the MERCED to trickle down and replace the aging x86. They STILL refuse to call it AMD64, which is what AMD calls the architecture (This caused confusion at my job, because people assumed AMD64 was only for AMD CPUs and the servers they were downloading code for were intel based). Intel instead calls their version EM64T, which is based on, but a lesser variant of, AMD64.

Re:Itaniums is **NOT** RISC (2)

FreonTrip (694097) | about 3 years ago | (#37452238)

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.

Re:Itaniums is **NOT** RISC (0)

Anonymous Coward | about 3 years ago | (#37451192)

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

SSE2 in the minimum requirement for that AMD64 thingy. FMA is coming both from AMD and Intel. The inclusion of directory cache is a processor architecture level decision which both of the x86 players are making or have made a while ago.

Re:Itaniums is **NOT** RISC (1)

ultranova (717540) | about 3 years ago | (#37451924)

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, don't forget that the more registers you have, the more state the OS has to save and restore at task switch time.

Re:Itaniums is **NOT** RISC (1)

Darinbob (1142669) | about 3 years ago | (#37452318)

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 space you save the more you can use for something that really does help your performance (bigger cache, more ALUs).

Why we hate x86 (3, Insightful)

erice (13380) | about 3 years ago | (#37450654)

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:Why we hate x86 (1)

afidel (530433) | about 3 years ago | (#37451666)

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 and the more verbose ISA makes better use of cache lines which are a much more limited resource in modern designs.

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.
Most of it's effectively gone on x86-64 processors even if it's still there for backwards compatibility, if you're writing modern code it has no effect on you.

Re:Itaniums is **NOT** RISC (1)

loufoque (1400831) | about 3 years ago | (#37451382)

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 (5, Informative)

Darinbob (1142669) | about 3 years ago | (#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.

RISCy Business Cycles (1)

Anonymous Coward | about 3 years ago | (#37450200)

  • RISC dominates servers and high end workstations
  • CISC takes desktops and makes steady inroads into workstations
  • RISC dominates low power devices
  • CISC takes high end servers
  • RISC makes inroads into notebooks and desktops

Lather, rinse, repeat, profit? and yawn!

Are they also gonna shut down the gibson? (0)

cb8100 (682693) | about 3 years ago | (#37450234)

RISC architecture is gonna change everything!

Re:Are they also gonna shut down the gibson? (3, Funny)

crankyspice (63953) | about 3 years ago | (#37450586)

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:Are they also gonna shut down the gibson? (0)

Anonymous Coward | about 3 years ago | (#37450840)

IBM already released a P7. P6 was released a few years ago :-)

Re:Are they also gonna shut down the gibson? (2)

hedwards (940851) | about 3 years ago | (#37451408)

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

Re:Are they also gonna shut down the gibson? (0)

Anonymous Coward | about 3 years ago | (#37451814)

No, he's planning to hack THE PLANET.

Re:Are they also gonna shut down the gibson? (0)

Anonymous Coward | about 3 years ago | (#37451574)

don't forget the million psychedelic colors..

Re:Are they also gonna shut down the gibson? (0)

Anonymous Coward | about 3 years ago | (#37451744)

Yeah. RISC is good.

Now, bring on the teenage Angelina Jolie frontal nudity!!

Probably a bullshit story (1)

oldhack (1037484) | about 3 years ago | (#37450262)

The summary stinks of spam with content-free verbiage.

Re:Probably a bullshit story (1)

the linux geek (799780) | about 3 years ago | (#37450296)

It's just yet another attempt of Intel to make x86 chips take over the high-end server market, as they've been trying to do since the early or mid 90's. x86 is like fusion power in that regard - it's always just a few years from evicting the RISC and mainframe architectures from their niches, no matter when you ask.

Re:Probably a bullshit story (1)

PCM2 (4486) | about 3 years ago | (#37450726)

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.

VLIW != RISC (1)

gman003 (1693318) | about 3 years ago | (#37450310)

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

Intel not going after RISC? (2)

PCM2 (4486) | about 3 years ago | (#37450504)

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.

Hmmm... (2)

fuzzyfuzzyfungus (1223518) | about 3 years ago | (#37450594)

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

Re:Hmmm... (0)

Anonymous Coward | about 3 years ago | (#37450712)

My thoughts, exactly. But when Intel will have killed the remaining competitors (Power, Z, Sparc if it's still around), they will be the only game in town and able to charge even higher prices.

Fight the x86 monoculture!

This said, for some commercial workloads, x86 is far from Power and Z with their decimal units, and that's where the real money is. Will Intel add another couple hundred instructions to the already bloated (but almost infinitely expandable thanks to a very flexible but disgusting encoding) instruction set?

Re:Hmmm... (1)

bws111 (1216812) | about 3 years ago | (#37450856)

Who in this day and age has predatory pricing?

WTH? Is this an Intel ad? (1)

Anonymous Coward | about 3 years ago | (#37450606)

This is hardly the first time intel has used the 'R-word' in marketing of Xeons.... Article brings nothing new to the table, hell this has been the Xeon marketing campaign for a decade...

Pay no attention to the man behind the curtain (4, Informative)

gstrickler (920733) | about 3 years ago | (#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."

Re:Pay no attention to the man behind the curtain (1)

RightSaidFred99 (874576) | about 3 years ago | (#37450822)

probably running x64 code, which was designed to be much more RISC like in the first place.

That doesn't even make sense. You do know that adding more registers doesn't make something "much more RISC like" right?

Re:Pay no attention to the man behind the curtain (0)

Anonymous Coward | about 3 years ago | (#37450978)

You do know that adding more registers doesn't make something "much more RISC like" right?

Eliminating a bunch of instructions would, tho..

Re:Pay no attention to the man behind the curtain (4, Informative)

gstrickler (920733) | about 3 years ago | (#37451020)

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:Pay no attention to the man behind the curtain (1)

rbarreira (836272) | about 3 years ago | (#37451168)

You do know that x64 has a simplified instruction set (...)

I don't remember hearing about this part... what significant chunk of instructions was removed?

Re:Pay no attention to the man behind the curtain (1)

chuckymonkey (1059244) | about 3 years ago | (#37451228)

It's not that it was removed, you only use the more complex and crappy legacy stuff when you're not running in legacy x86 mode. So yes the instructions are still there, but if you're running x64 then you're not using them.

Re:Pay no attention to the man behind the curtain (1)

rabun_bike (905430) | about 3 years ago | (#37452040)

But, sadly, the logic gates are still taking up space on the chip to support all the "baggage" and anyone who has seen the x86 instruction set knows there is lots of baggage going all the way back to the 8088 with the lovely big-endian data segment implementation. Those historic junk logic gates take up space, create heat, and burn power. Since shrinking chips and increasing Mhz isn't cutting it we went to multi-core. Now we are seeing limitation of multi-core so we bump up the bus speed and add more fast cache. All this juxtaposition eats up power. At some point the path forward will be a to break legacy code. I think we are fast moving towards that possibility with the wide adoption of ARM. If consolation data centers see large energy savings with a true RISC processor the market will move that direction.

Re:Pay no attention to the man behind the curtain (0)

Anonymous Coward | about 3 years ago | (#37451276)

No, true RISC does not run CISC in legacy mode, you're thinking of intel's rendition of it: x86-64 or whatever you want to call it.

You want to see RISC as it was? Look at DEC Alpha, Sun's older servers before they became intel's bitch, and IBM mainframe CPUs. While beautiful, they were different.

Re:Pay no attention to the man behind the curtain (4, Informative)

bws111 (1216812) | about 3 years ago | (#37451434)

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:Pay no attention to the man behind the curtain (0)

Anonymous Coward | about 3 years ago | (#37452204)

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

My best guess is Anonymous hacked this page and replaced every instance of RAS with RISC. None of it makes any sense to me.

Re:Pay no attention to the man behind the curtain (1)

LWATCDR (28044) | about 3 years ago | (#37451412)

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:Pay no attention to the man behind the curtain (1)

gstrickler (920733) | about 3 years ago | (#37451946)

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?

It's just spin (1)

msobkow (48369) | about 3 years ago | (#37450636)

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 of applications, support, and data center integration. They maintain their market share by making it EASY for business to buy a SOLUTION instead of a computer.

Re:It's just spin (0)

Anonymous Coward | about 3 years ago | (#37451170)

That leaves IBM. And IBM doesn't sell you just a POWER based system -- they sell you the whole suite of applications, support, and data center integration. They maintain their market share by making it EASY for business to buy a SOLUTION instead of a computer.

LOL. I want some of what you're smoking. IBM will leave with you an army of useless consultants, professional bullshitters, providing you with complete solutions that will take a shitfuck of time to make it work (I will concede the point that after it works it generally works fine, but it takes a amount bizarre time and patience to get it up and running). They maintain their market by playing golf with your CEO, like everyone else does.

Well, although I'm far from being a C-level monkey IBM has paid me a few very nice golf classes. Nobody ever gets fired for buying IBM!

Re:It's just spin (1)

the linux geek (799780) | about 3 years ago | (#37451406)

HP Integrity's been in second place behind IBM Power and ahead of SPARC for a while.

Re:It's just spin (1)

Lawrence_Bird (67278) | about 3 years ago | (#37452030)

and POWER7 does seem to kick ass too, no?

Itanium && RISC (0)

Anonymous Coward | about 3 years ago | (#37450666)

Strange, last I heard, the Itanium processor line wasn't RISC at all...but rather EPIC and/or VLIW...not sure which applies.

--AC

CLOSED? (0)

Anonymous Coward | about 3 years ago | (#37450668)

Oh no, somebody better tell sparc.org to cease and decist!

Wow, what a terrible article (1)

Sebastopol (189276) | about 3 years ago | (#37450676)

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?

real RISC (0)

Anonymous Coward | about 3 years ago | (#37451474)

RISC isn't literally about having fewer instructions or smaller instruction sets. Its a design philosophy where the instructions are reduced down to practical sizes where 1 simple operation takes 1 simple cycle and are simple to implement in hardware; extra registers and cache are benefits of keeping things simple (plus you could use them more since you are running more ops.) I would argue that many things that have been added are RISC as long as they maintained the design -- doesn't matter if they add more instructions; if you literally thought it was just keeping instruction counts down then nothing could be RISC anymore.

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.

Of course they will end up with smaller operations internally; the die sizes would be much larger if they didn't do that.... they could do it-- if you don't put out a RISC interface it is not RISC.

For me, it generally needs load/store instructions to be RISC; combined load store instructions are really non-RISC thinking on something as fundamental as memory. prefetch is ok. FPU is ok. MMX, SSE, those are not RISC like. Power's VMU's I would argue are RISC in that they act like another unit; although, a few instructions may take a couple clocks... its not like those units are simple to make; back when I was learning it most everything was 1 clock and newer ones lowered it-- the goal was 1 clock (these few slow ops were not practically broken down into smaller ops... again its not the literal RISC rule but the design...)

Re:real RISC (0)

Anonymous Coward | about 3 years ago | (#37451950)

I think you're arguing that if the programmer's view isn't RISC-like, it isn't a RISC processor. That's ridiculous. RISC has just as much to do with the internal implementation.

Having said that, there's no such thing as a pure RISC processor. Early RISC were completely load-store, single cycle execution, with no pipeline interlocks (leaving a lot of the dependency checking / instruction scheduling to the compiler). But as things evolved, "RISC" processors adopted CISC features (SIMD instructions, complex hardware dependency checking, etc.) while CISC added RISC features. In order to get higher performance, each camp picked features from the other.

The only reason anyone even mentions "CISC vs. RISC" is because IA32 still lives on, and because some of IBM's current processors still support stuff from the 360 mainframes.

Re:real RISC (1)

the_humeister (922869) | about 3 years ago | (#37452350)

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?

Re:Wow, what a terrible article (0)

Anonymous Coward | about 3 years ago | (#37451486)

No. It will not grow their bottom line.

and YES. Intel went RISC with the Pentium Pro.

Re:Wow, what a terrible article (1)

the_humeister (922869) | about 3 years ago | (#37452332)

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.

Hard to take the story seriously (2, Insightful)

sl3xd (111641) | about 3 years ago | (#37450734)

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:Hard to take the story seriously (2)

evilviper (135110) | about 3 years ago | (#37452052)

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.

+gn4a (-1)

Anonymous Coward | about 3 years ago | (#37450880)

all over America Be on a wrong projeCt returns found out about the Survival prospects Have their moments

x86 are RISC since P6 (4, Informative)

maitas (98290) | about 3 years ago | (#37451164)

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

HockeyPuck (141947) | about 3 years ago | (#37451444)

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:It's not the CPU, it's the whole product. (1)

afidel (530433) | about 3 years ago | (#37451852)

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.

Re:It's not the CPU, it's the whole product. (1)

aztracker1 (702135) | about 3 years ago | (#37452244)

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.

But 15 years ago.... (0)

Anonymous Coward | about 3 years ago | (#37451618)

10-15 years ago, Alpha and POWER were RISC processors, x86 was usually considered CISC with a RISC core powering it, and Itanium was EPIC. If memory serves, EPIC cpu hardware differed notably from either of the former in at least some significant ways, thus garnering its own space on the processor-family shelf. By blurring the boundaries with this story, Intel has pretty much proven that the cross-pollination of processor architectures over the last 15 years has made the processor-family-wars moot.

All Intel chips have been RISC for a while now (1)

boddhisatva (774894) | about 3 years ago | (#37451922)

Intel's chips have been running on a RISC core for quite a while. The rest of the CISC instruction set is converted by microcode into RISC instructions. Just noticed the person before me said the same thing.

Yawn.. (1)

bored (40072) | about 3 years ago | (#37451976)

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 outweighs the 5x (or more, the sky is the limit in some cases) price difference between them and a basic Intel system. Its because companies have 8 and 9 figure investments in software running on them. They will probably still be in datacenters for decades into the future if IBM/Oracle/HP/etc don't decide to kill them off. They zombie on, as long as the original manufacturer supports them and the perceived/actual cost to port the application out weights the cost of buying a new machine/os every 5 years or so.

Re:Yawn.. (1)

Relayman (1068986) | about 3 years ago | (#37452080)

Nothing runs Linux like PowerPC. Nothing can handle virtualization like PowerPC. Intel only dreams of doing what IBM does every day.

4core = CISC+3*RISC (0)

Anonymous Coward | about 3 years ago | (#37452296)

For compatibility with BOTH the future+past: Multicore == 1 Legacy Core + 2^n-1 AMD64 Cores (64bit *only*)

Timing would have been perfect: the multicore transition took place right after AMD64. Noone would be hurt by having only one 32bit core. All parallel code would be 64bit.

Alas, Fear rules management.

So now we await the first brave (=least fearful) soul to produce 64bit only CPUs. It would do 32 bit by emulation, no big deal. /jm

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?