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!

Research Shows RISC vs. CISC Doesn't Matter

timothy posted about a month ago | from the just-a-couple-of-letters dept.

Intel 161

fsterman writes The power advantages brought by the RISC instruction sets used in Power and ARM chips is often pitted against the X86's efficiencies of scale. It's difficult to assess how much the difference between instruction sets matter because teasing out the theoretical efficiency of an ISA from the proficiency of a chip's design team, technical expertise of its manufacturer, and support for architecture-specific optimizations in compilers is nearly impossible . However, new research examining the performance of a variety of ARM, MIPS, and X86 processors gives weight to Intel's conclusion: the benefits of a given ISA to the power envelope of a chip are minute.

cancel ×

161 comments

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

isn't x86 RISC by now? (5, Informative)

alen (225700) | about a month ago | (#47773753)

i've read the legacy x86 instructions were virtualized in the CPU a long time ago and modern intel processors are effectively RISC that translate to x86 in the CPU

Re:isn't x86 RISC by now? (3, Interesting)

Z80a (971949) | about a month ago | (#47773771)

As far i'm aware since the pentium pro line, the intel CPUs are RISCs with translation layers and AMD been on this boat since the original athlon.

Re:isn't x86 RISC by now? (2)

cheesybagel (670288) | about a month ago | (#47773849)

Actually AMD did that way back in the K5 time. The K5 was a 29k RISC processor with a x86 frontend.

Re:isn't x86 RISC by now? (1)

Z80a (971949) | about a month ago | (#47773887)

Interessing.
I was thinking the Atlhon that was the 29k.

Re:isn't x86 RISC by now? (5, Informative)

cheesybagel (670288) | about three weeks ago | (#47774121)

After AMD lost the license to manufacture Intel i486 processors, together with other people, they were forced to design their own chip from the ground up. So they basically used one of the 29k RISC processors and put an x86 frontend on it. Cyrix did more or less the same thing at the time also coming with their own design. Since the K5 had good performance per clock but could not clock very high and was expensive AMD was stuck and to get their next processor they bought a company called NexGen which designed the Nx586 processor which was Intel compatible. AMD then worked on the successor of Nx586 as a single chip which was the K6. The K7 Athlon was yet another design made by a team headed by Dirk Meyer who used to be a chip designer at Digital Equipment Incorporated i.e. DEC. He was one of the designers of the Alpha series of RISC CPUs and the Athlon resembles an Alpha chip internally a lot because of that.

Re: isn't x86 RISC by now? (2)

the_humeister (922869) | about three weeks ago | (#47774241)

Actually, Nexgen was the first to do x86 -> RISC. Then Intel with Pentium Pro. Then AMD with K5. As far as I recall, Cyrix never did x86 -> RISC back then until they were acquired by VIA (ie, Cyrix M series chips executed x86 directly, but VIA Epia and later translate).

Re: isn't x86 RISC by now? (1)

cheesybagel (670288) | about three weeks ago | (#47774441)

Right NexGen released their chip first but it is hard to compare because it was a dual-chip solution where the FPU came in a separate package while the K5 had its own FPU. NexGen only did a single-chip product later. K5 development process was highly protracted and difficult and the release was delayed many times. The Cyrix 5x86 was also similar in a lot of regards to the Pentium Pro. In fact I remember the Pentium Pro designer himself stating that they had a lot of interesting insights during Pentium Pro chip design after doing low-level reverse engineering of a Cyrix processor.

Re: isn't x86 RISC by now? (0)

Anonymous Coward | about three weeks ago | (#47777061)

FWIW, I don't think the Cyrix 5x86 was very similar at all to the Pentium Pro.

Although the Cyrix 5x86 and Pentium Pro both had a scheme which decoded x86 to micro-ops, the similarities pretty much end there. As I recall the 5x86 had a very basic micro-op fusion scheme (address gen) and was out-of-order only for loads/stores, where the Pentium Pro was a much more advanced (for it's time) super-scalar out-of-order machine.

As one of the 5x86 architects put it, they used superscalar architectural features in a scalar configuration...

Of course P6 pipeline was something like 14 stages where the 5x86 was closer to 9 which means the broken branch prediction on the 5x86 didn't matter as much...

Re:isn't x86 RISC by now? (1)

hkultala (69204) | about three weeks ago | (#47774469)

After AMD lost the license to manufacture Intel i486 processors, together with other people, they were forced to design their own chip from the ground up. So they basically used one of the 29k RISC processors and put an x86 frontend on it.

This was their plan, but it ended up being quite much harder than they originally thought, and K5 came out much later, much different and much slower than planned. There are quite a lot of thigns that have to be done differently (some of them are explained in my another post)

Re:isn't x86 RISC by now? (2)

funwithBSD (245349) | about three weeks ago | (#47774921)

When the DEC Alpha was killed, many of the engineers were picked up by AMD.

Re:isn't x86 RISC by now? (4, Insightful)

Anonymous Coward | about a month ago | (#47773941)

Yes. As noted by the study (That by the way isn't very good.) "When every transistor counts, then every instruction, clock cycle, memory access, and cache level must be carefully budgeted, and the simple design tenets of RISC become advantageous once again."
Essentially meaning that "If you want as few transistors as possible it doesn't help to have the CISC to RISC translation layer in x86"

They also claim things like "The report notes that in certain, extremely specific cases where die sizes must be 1-2mm2 or power consumption is specced to sub-milliwatt levels, RISC microcontrollers can still have an advantage over their CISC brethren." which clearly indicates that their idea of "embedded" systems is limited to smartphones.
The cases where you have a battery that can't be recharged on daily basis is hardly an extremely specific case. Not that any CPU they tested is suitable for those applications anyway. They have essentially limited themselves to applications where "not as bad as P4" is acceptable.

Re:isn't x86 RISC by now? (2, Interesting)

Anonymous Coward | about a month ago | (#47773791)

x86 instructions, are in fact, decoded to micro opcodes, so the distinction isn't as useful in this context.

Re:isn't x86 RISC by now? (4, Interesting)

RabidReindeer (2625839) | about a month ago | (#47773997)

x86 instructions, are in fact, decoded to micro opcodes, so the distinction isn't as useful in this context.

They're not the only ones. The IBM mainframes have long been VMs implemented on top of various microcode platforms. In fact, one of the original uses of the 8-inch floppy disk was to hold the VM that would be loaded up during the Initial Microprogram Load (IMPL), before the IPL (boot) of the actual OS. So in a sense, the Project Hercules mainframe emulator is just repeating history.

Nor were they unusual. In school I worked with a minicomputer which not only was a VM on top of microcode, but you could extend the VM by programming to the microcode yourself.

The main differences between RISC and CISC, as I recall were lots of registers and the simplicity of the instruction set. Both the Intel and zSeries CISC instruction sets have lots of registers, though. So the main difference between RISC and CISC would be that you could - in theory - optimize "between" the CISC instructions if you coded RISC instead.

Presumably somebody tried this, but didn't get benefits worth shouting about.

Incidentally, the CISC instruction set of the more recent IBM z machines includes entire C stdlib functions such as strcpy in a single machine-language instruction.

CISC - reduced memory access ... (3, Interesting)

perpenso (1613749) | about three weeks ago | (#47774185)

x86 instructions, are in fact, decoded to micro opcodes, so the distinction isn't as useful in this context.

Actually it is. Modern performance tuning has a lot to do with cache misses and such. CISC can allow for more instructions per cache hit. The strategy of a hybrid type design, CISC external architecture and RISC internal architecture definitely has some advantages.

That said, the point of RISC was not solely execution speed. It was also simplicity of design. A simplicity that allowed organization with less money and resources than Intel to design very capable CPUs.

Re:isn't x86 RISC by now? (1)

wiredlogic (135348) | about a month ago | (#47773837)

This. The x86 ISA is roughly analogous to ARM Thumb compressed instructions. It is just a front end to a register rich RISC core.

Re:isn't x86 RISC by now? (2)

bill_mcgonigle (4333) | about a month ago | (#47773905)

I have to assume the wisc.edu folks know this and somebody gummed up the headlines along the way.

Re:isn't x86 RISC by now? (4, Interesting)

drinkypoo (153816) | about a month ago | (#47773925)

That is correct. Every time this comes up I like to spark a debate over what I perceive as the uselessness of referring to an "instruction set architecture" because that is a bullshit, meaningless term and has been ever since we started making CPUs whose external instructions are decomposed into RISC micro-ops. You could switch out the decoder, leave the internal core completely unchanged, and have a CPU which speaks a different instruction set. It is not an instruction set architecture. That's why the architectures themselves have names. For example, K5 and up can all run x86 code, but none of them actually have logic for each x86 instruction. All of them are internally RISCy. Are they x86-compatible? Obviously. Are they internally x86? No, nothing is any more.

Re:isn't x86 RISC by now? (1)

yayoubetcha (893774) | about three weeks ago | (#47774117)

You just saved me five minutes for typing the same reply. Well said and thanks!

This is a myth that is not true (5, Informative)

hkultala (69204) | about three weeks ago | (#47774375)

That is correct. Every time this comes up I like to spark a debate over what I perceive as the uselessness of referring to an "instruction set architecture" because that is a bullshit, meaningless term and has been ever since we started making CPUs whose external instructions are decomposed into RISC micro-ops. You could switch out the decoder, leave the internal core completely unchanged, and have a CPU which speaks a different instruction set. It is not an instruction set architecture. That's why the architectures themselves have names. For example, K5 and up can all run x86 code, but none of them actually have logic for each x86 instruction. All of them are internally RISCy. Are they x86-compatible? Obviously. Are they internally x86? No, nothing is any more.

This same myth keeps being repeated by people who don't really understand the details on how processors internally work.

You cannot just change the decoder, the instruction set affect the internals a lot:

1) Condition handling is totally different on different instruciton sets. This affect the banckend a lot. X86 has flags registers, many other architectures have predicate registers, some predicate registers with different conditions.

2) There are totally different number of general purpose and floating point registers. The register renamer makes this a smaller difference, but then there is the fact that most RISC's use same registers for both FPU and integer, X86 has separate registers for both. And this totally separates them, the internal buses between the register files and function units in the processor are done very differently.

3) Memory addressing modes are very different. X86 still does relatively complex address calculations on single micro-operation, so it has more complex address calculation units.

4) Whether there are operations with more than 2 inputs, or more than 1 output has quite big impact on what kind of internal buses are needed, how many register read and write ports are needed.

5) There are a LOT of more complex instructions in X86 ISA which are not split into micro-ops but handled via microcode. the microcode interpreter is totally missing on pure RISCs ( but exists on some not-so pure RISC's like Powe/PowerPC).

6) Instruction set dictates the memory aligment rules. Architectures with more strict alignment rules can have simples load-store-units.

7) Instruction set dictatetes the multicore memory ordering rules. This may affect the load-store units, caches and buses.

8) Some instructions have different bitnesses in different architectures. For example x86 has N x X -> 2N wide multiply operations which most RISC's don't have. So x86 needs bigger/different multiplier than most RISCs.

9) X87 FPU values are 80-bit wide(truncated to 64-bit when storing/loading). Practically all the other CPU's have maximum of 64-bit wide FPU values (though some versions Power have support for 128-bit FP numbers also)

Re:This is a myth that is not true (0)

drinkypoo (153816) | about three weeks ago | (#47774949)

Some of what you said is legitimate. Most of it is irrelevant, since it does not speak to the postulate. You're speaking of issues which will affect performance. So what? You'd have a less-performant processor in some cases, and it would be faster in others.

Re:This is a myth that is not true (4, Informative)

hkultala (69204) | about three weeks ago | (#47775093)

Some of what you said is legitimate. Most of it is irrelevant, since it does not speak to the postulate. You're speaking of issues which will affect performance. So what? You'd have a less-performant processor in some cases, and it would be faster in others.

No.

1) if the codition codes work totally differently, they don't work.

2) The data paths needed for separate and compined FP and integer regs are so different that it makes absolutely NO sense to have them together in chip that runs x86 ISA, even though it's possible.

3) If you don't have those x86-compatible address calculation units, you have to break most of memory ops into more micro-ops OR even run them with microcode. Both are slow. And if you have a RISC chip you want to have only the address calculation units you need for your simple base+offset addressing.

4) In the basic RISC pipeline there are two operands, one output/instruction. There are no data paths for two results, you cannot execute operations with multiple outputs such as x86 muliply which produces 2 values(low and high part of result), unless you do something VERY SLOW.

6) IF your RISC instruction set says you have aligned memory operations, you design your LSU to have only those, as it makes the LSU's much smaller, simpler and faster. But you need unaligned accesses for x86.

9) If your FPU calculates with different bit width, it calculates wrongly.

And

Re:This is a myth that is not true (1)

Bengie (1121981) | about three weeks ago | (#47775701)

9) This is how x86 has been doing it for decades. Does not matter if it's wrong, it's how it's done.

Re: This is a myth that is not true (0)

Anonymous Coward | about three weeks ago | (#47776993)

Put simply, the decoder is optimised for the front-end.

Microcode switching (2)

DrYak (748999) | about three weeks ago | (#47775413)

This same myth keeps being repeated by people who don't really understand the details on how processors internally work.

Actually, YOU are wrong.

You cannot just change the decoder, the instruction set affect the internals a lot:

All the reason you list could all be "fixed in software". The fact that silicon designed by Intel handles opcode in a way a little bit better optimized toward being fed from a x86-compatible frontend is just specific optimisation. Simply doing the same stuff with another RISCy back-end, i.e: interpreting the same ISA fed to the front-end, will simply require each x86 ISA being executed as a different set of micro-instructions. (some that are handled as single ALU opcode on Intel's silicon might require a few more instruction, but that's about the different).

You could switch the frontend and speak a completely different instruction set. Simply if the two ISA are radically different, the result wouldn't be as efficient as a chip designed with that ISA in mind. (You would need a much bigger and less efficient microcode, because of all the reasons you list. They won't STOP intel from making a chip that speaks something else. Intel will simply produce a chip where the front-end is much more clunky, inefficient, waste 3x more opcode per instruction, and waste much time waiting that some bus gets free or copying values around, etc.).

  And to go back to the parent...

You could switch out the decoder, leave the internal core completely unchanged, and have a CPU which speaks a different instruction set. It is not an instruction set architecture. That's why the architectures themselves have names.

Not only is this possible, but this was INDEED done.

There was an entire company called "Transmeta" whose business was centered around exactly that:
Their chip, the "Crusoe" was compatible with x86.
- But their chip was actually a VLIW chips, with the front-end being 100% pure software. Absolutely as remote from a pure x86 core as possible.
- The frontend was entirely 100% pure software.

The advantage touted by Transmeta was that, although their chip was a bit slower and less efficient, it consumed a tiny fraction of the power and was field-upgradeable (in theory just issue a firmware upgrade to support newer instruction.) Transmeta had demos of Crusoe playing back MPEG video on a few watts, whereas Pentium 3 (the then lower-power Intel chip) would consume way much more.

Saddly, it all happened in an era where pure raw performance was the king, and where use a small nuclear plant to power an Pentium IV (the then high performance flagship) and needing a small lake nearby for cooling was considered perfectly acceptable. So Crusoe didn't see that much success.

Still, Crusoe was successfully used as a test bed for a few experimental CPU to test their ISA before actual test-bed where available. (If I remember correctly, Crusoe where used to test running x86_64 code before actual Athlon 64 where available for developers), and there were a few experimental proof-of-concept running PowerPC ISA.

In a way modern way, this isn't that much dissimilar from how Radeon handle compiled shared, except that the front-end is now a piece of software which run inside OpenGL on the main CPU: intermediate instruction a compiled to either VLIW or CGN opcode which are 2 entirely different back-ends.
(Except that, due to the highly repetitive nature of a shared, instead of decoding instruction on the fly as they come, you optimise it once into opcode, store it into a cache and you're good).

Again, on a similar way ARM can switch between 2 different types of instruction set (normal and thumb mode), 2 different sets, one back-end.

Re:Microcode switching (2)

hkultala (69204) | about three weeks ago | (#47776257)

This same myth keeps being repeated by people who don't really understand the details on how processors internally work.

Actually, YOU are wrong.

You cannot just change the decoder, the instruction set affect the internals a lot:

All the reason you list could all be "fixed in software".

No, they cannot. OR the software will be terible slow , like 2-10 times slowdown.

The fact that silicon designed by Intel handles opcode in a way a little bit better optimized toward being fed from a x86-compatible frontend is just specific optimisation.

Opcodes are irrelevant. They are easy to translate. What matters are the differences in the semantics of the instructions.
X86 instructions update flags. This adds dependencies between instructions. Most RISC processoers do not have flags at all.
This is semantics of instructions, and they differ between ISA's.

Simply doing the same stuff with another RISCy back-end, i.e: interpreting the same ISA fed to the front-end, will simply require each x86 ISA being executed as a different set of micro-instructions. (some that are handled as single ALU opcode on Intel's silicon might require a few more instruction, but that's about the different).

The backend, the micro-instrucions in x86 CPUs are different than the instructions in RISC CPU's. They differ in the small details I tried to explain.

You could switch the frontend and speak a completely different instruction set. Simply if the two ISA are radically different, the result wouldn't be as efficient as a chip designed with that ISA in mind. (You would need a much bigger and less efficient microcode, because of all the reasons you list. They won't STOP intel from making a chip that speaks something else.

Intel did this, they added x86 decoder to their first itanium chips. And. They did not only add the frontend, they added some small pieces to their backend so that it could handle those strange x86 semantic cases nicely.
But the perfromance was still so terrible that nobody ever used it to run x86 code, and then they created a software translator that translated x86 code into itanium code, and that was faster, though still too slow.

Not only is this possible, but this was INDEED done.

There was an entire company called "Transmeta" whose business was centered around exactly that:
Their chip, the "Crusoe" was compatible with x86.
- But their chip was actually a VLIW chips, with the front-end being 100% pure software. Absolutely as remote from a pure x86 core as possible.'

The backend of Crusoe was designed completely x86 on mind, all the execution units contained the small quirks in a manner which made it easy to emulate x86 with it. The backend of Crusoe contains things like:

* 80-bit FPU,
* x86-compatible virtual memory page table format(one very important thing I forgot from my original list couple of posts ago; Memory accesses get VERY SLOW if you have to emulate virtual memory)
* support for partial register writes(to emulate 8- and 16-bit subregisters like al, ah,ax )

All these were made to make binary translation from x86 easy and reasonable fast.

Re:Microcode switching (0)

drinkypoo (153816) | about three weeks ago | (#47776883)

All these were made to make binary translation from x86 easy and reasonable fast.

And herein lies the proof that you know you are wrong, but are continuing to argue. Those things didn't make x86 translation possible, they made it easy and fast. Which is what I said previously. Thanks for the confirmation.

Re:isn't x86 RISC by now? (4, Insightful)

enriquevagu (1026480) | about three weeks ago | (#47775259)

This is why we use the terms "Instruction Set Architecture" to define the interface to the (assembler) programmer, and "microarchitecture" to refer to the actual internal implementation. ISA is not bullshit, unless you confuse it with the internal microarchitecture.

Re:isn't x86 RISC by now? (0)

drinkypoo (153816) | about three weeks ago | (#47776981)

This is why we use the terms "Instruction Set Architecture" to define the interface to the (assembler) programmer,

No, no we do not. That is called the instruction set. The programmer does not use the instruction set architecture, they simply issue instructions which the processor then executes as it sees fit, especially in [OoO] architectures with branch prediction. The architecture is the silicon, and the programmer isn't sitting on the die flipping switches.

Re:isn't x86 RISC by now? (1)

morgauxo (974071) | about three weeks ago | (#47776419)

Does that mean that the Transmeta Crusoe wasn't anything special?

It's a question that WAS relevant (3, Insightful)

i kan reed (749298) | about a month ago | (#47773765)

Back when compilers weren't crazy optimized to their target instruction set, people coding things in assembler wanted CISC, and people using compilers wanted RISC.

But nowadays almost no one still does the former, and the latter uses CISC chips a lot better.

This is now a question for comp sci history, not engineers.

Re:It's a question that WAS relevant (5, Funny)

TWX (665546) | about a month ago | (#47773835)

You mean, my Github project on Ruby on Rails with node.js plugins isn't optimized to use one versus the other?

Re:It's a question that WAS relevant (1)

Rich0 (548339) | about a month ago | (#47773845)

I actually wonder how relevant CISC even is to people doing assembly programming these days. There is no reason you can't pull an LLVM-like move and target something other than the native instruction set when you are programming.

That is basically all the x86 does anyway - convert CISC instructions into microcode. There is no reason that an assembler couldn't do the same thing, further blurring the lines between assembly and compiled code. If the whole point of writing assembly is to optimize your code, and a RISC processor could run your code faster after low-level-compilation than a CISC processor could run it natively, then RISC is what you really want anyway.

Re:It's a question that WAS relevant (1)

i kan reed (749298) | about a month ago | (#47773967)

Usually, if you're coding in assembly, it's because you're trying to bring some very basic core functionality into a system, be it an OS component, a driver, or a compiler, and usually that means that you're engaged in enough system-specific behaviors that virtualization does you no good.

Java and .NET benefit from a virtual machine language precisely because they're high level languages, and it's easier to compile assembly to assembly in multiple ways than to compile high level languages to multiple assembly languages.

Re:It's a question that WAS relevant (1)

ebno-10db (1459097) | about a month ago | (#47774057)

easier to compile assembly to assembly in multiple ways than to compile high level languages to multiple assembly languages.

In other words, they don't want to be bothered writing real compilers.

Re:It's a question that WAS relevant (1)

Zero__Kelvin (151819) | about three weeks ago | (#47775081)

No. In other words, assembly language programmers don't use compilers; they use assemblers.

Re:It's a question that WAS relevant (1)

TangoMargarine (1617195) | about three weeks ago | (#47774739)

virtual machine language

Don't mind me; I'm just twitching over here and fighting down the urge to vomit.

Re:It's a question that WAS relevant (2)

i kan reed (749298) | about three weeks ago | (#47774985)

Oh no. A technology exists.

Let me rephrase that. I cannot comprehend your objections.

Re:It's a question that WAS relevant (1)

TangoMargarine (1617195) | about three weeks ago | (#47775589)

"Virtual" anything means there's at least one layer of abstraction between the thing and anything the layperson would consider remotely close to the hardware. "Machine" would imply something that is inversely quite close to the hardware. To my ears, it sounds like saying "pure hybrid"...you can't be both at the same time.

Maybe I'm mixing up (virtual (machine language)) and ((virtual machine) language). From the perspective of the Java/.NET compiler it conceptually resembles machine language but it sure doesn't from the perspective of the actual hardware. I can see how Java being in a VM to begin with presents a similar model to running assembly on the actual machine but comparing the two in terms of efficiency and overhead is laughable. I was signalling my cognitive dissonance of conflating Java and assembly so directly.

There's a lot more going on... (1)

Anonymous Coward | about a month ago | (#47774041)

The benefit to CISC instructions is the ability to get the processor to do more work with less instructions.

While it may seem like a compiler can negate that, for a non-trivial number of programs you can get much higher code density using CISC instructions, which in turn frees up memory cycles for data instead of code. One of the key arguements I head back in the late 90s/early 00s however was that Hybridized chips was where it was at. If you go and look at previously 'CISC' and 'RISC' chips and look at the instruction sets, the majority of RISC chips have added a number of CISC-like instructions for certain types of operations (notably floating point and byte array/string handling stuff) while CISC chips have basically just turned into a translation layer over a slightly more complicated RISC core that is only really optimized for say the top 50-100 operations, and everything else is 2+x slower than the old CISC implementations (instructions that used to take say 2 cycles due to dedicated circuitry may now take 4+ due to reuse of micro-ops).

Re:There's a lot more going on... (0)

Zero__Kelvin (151819) | about three weeks ago | (#47775115)

No, the benefit of RISC is that you have many more on chip registers that can be used to store data, manipulate data, etc sans a cache hit. With CISC the minute you want to keep more than a handful of data elements in an array to operate on in parrallel, you're taking a cache hit. Several actually.

Re:There's a lot more going on... (1, Insightful)

Rockoon (1252108) | about three weeks ago | (#47776135)

No, the benefit of RISC is that you have many more on chip registers

Nothing about RISC makes more registers inherent, and nothing about CISC makes less registers inherent. Now shut the fuck up and let the real nerds discuss.

Re:It's a question that WAS relevant (3, Interesting)

Nyall (646782) | about a month ago | (#47774071)

I think a large part of the confusion is that CISC often means accumulator architectures (x86, z80, etc) vs RISC which means general purpose register (ppc, sparc, arm, etc) In between you have variable width RISC like thumb2.

As an occasional assembly programmer (PowerPC currently) I far prefer these RISC instructions. With x86 (12+ years ago) I would spend far more instructions juggling values into the appropriate registers, then doing the math, then juggling the results out so that more math could be done. With RISC, especially with 32 GPRs, that juggling is near eliminated to the prologue/epilogue. I hear x86 kept taking on more instructions and that AMD64 made it a more GPR like environment.

-Samuel

Re:It's a question that WAS relevant (2)

mlts (1038732) | about three weeks ago | (#47774785)

Even though Itanium is all but dead, I did like the fact that you had 128 GP registers to play with. One could do all the loads in one pass, do the calculations, then toss the results back into RAM. The amd64 architecture is a step in the right direction, and I'd say that even though it was considered a stopgap measure at the time, it seems to have been well thought out.

Re:It's a question that WAS relevant (0)

Anonymous Coward | about three weeks ago | (#47775747)

Yes, it was great, but then you have the cost of 128 GP registers to pay for (both in money and power).

Modern x86-like processors also have lots of registers (more like 64), although not directly addressable. They're used internally to improve parallelism by removing write dependencies. Something like:

mov eax, ebx
add eax, 3
mov ecx, eax
add eax, 7

Would prevent parallelization completely if it weren't for register renaming (which is how processors tap into the extra registers). So, an i7 would, for instance:

mov eax, ebx
add eax, 3
add eax, 7 into eax2 + mov ecx, eax

Increasing performance 50% (at least, in this little piece of useless code).

Don't check my assembly too much, I never remember the exact syntax, but the idea is that x86 processors also have lots of GP registers. It's just not all are directly accessible, and x86-64 has a bunch more directly accessible ones as well (16, instead of 8). The extra registers also help a lot for Hyper Threading, btw.

Re:It's a question that WAS relevant (0)

Anonymous Coward | about three weeks ago | (#47775841)

AC posting again, a PD:

The benefit of having virtual registers is that you're not locked in by your ISA in the number of registers you have to provide. They're free to increase or decrease, and they have done it as the need for more renaming arises to improve IPC counts. So having lots of GPR is not necessarily good for the ISA.

Re:It's a question that WAS relevant (1)

Eravnrekaree (467752) | about three weeks ago | (#47775153)

An all the way CISC architecture would allow you to have both operands of an instruction to be pointers to memory, the CPU would have the circuitry to load values into a register in the background. That would eliminate manual register loading. You would also have 3 operand versions of the instructions, as well. x86 is not the most CISC architecture out there or take the concept as far as it could. This would be a very programmer friendly environment. AMD expanded the number of registers, they could add even more, I dont know what the reasons are for not having at least 32 GPRs.

Re:It's a question that WAS relevant (1)

mlts (1038732) | about three weeks ago | (#47774667)

With Moore's law flattening out, the pendulum might end up swinging back that way.

Right now, for a lot of tasks, we have CPU to burn, so the ISA doesn't really matter as much as it did during the 680x0 era.

But who knows... Rock's law may put the kibosh on Moore's law eventually, so we might end up seeing speed improvements ending up being either better cooling (so clock speeds can be cranked up), or adding more and more special purpose cores [1]. At this point, it might be that having code optimized by a compiler for a certain ISA may be the way of developing again.

[1]: High-power CPUs, low-energy CPUs, GPUs, FPUs, FPGAs, and even going from there, CPUs intended for I/O (MIPS.) It might be that we might have a custom core just to run the OS's kernel, another to run security sensitive code, and still others for applications.

Re:It's a question that WAS relevant (1)

shoor (33382) | about three weeks ago | (#47774877)

Back in the 1970s I worked at a computer manufacturer, writing code for their product's instruction set in assembler. The computers were designed and built around AMD2901 bit slices. The hardware guys implemented the instruction sets using microcode and, as the computers got bigger and more complicated some of the instructions got so elaborate that programmers found ways to do an operation faster using a few simpler instructions instead of one complicated one.

Nowadays, with the kind of speedups from using cache memory, branch prediction, and so on, I reckon it could be a whole different ballgame. I suspect though, that proving correctness might become the most important criteria, and simpler would make proving correctness easier.

Asses? (-1)

Anonymous Coward | about a month ago | (#47773773)

Or Assess?

Re:Asses? (1)

TWX (665546) | about a month ago | (#47773841)

This is a discussion forum on the Internet. Definitely the former.

Nobody (-1)

Anonymous Coward | about a month ago | (#47773775)

Will ever need more than 640K.

- Bill Gates

Re:Nobody (1)

creimer (824291) | about three weeks ago | (#47775657)

A computer instructor in 1992 told my class that computers won't ever need more than 4GB (the 32-bit memory limit). IIRC, 8MB was the norm back then.

Not what my last GF said to me (0, Funny)

Anonymous Coward | about a month ago | (#47773781)

She said, boy, you need to put some CISC into your RISC or I am gone, she said.

Re: Not what my last GF said to me (0)

Anonymous Coward | about three weeks ago | (#47774591)

Thats just because I put some RISC into her CISC earlier that day.

Its as if... (1)

bazmail (764941) | about a month ago | (#47773797)

...a million smug old school douche-nozzle Mac users cried out and suddenly fell silent.

Re:Its as if... (1)

TWX (665546) | about a month ago | (#47773865)

Mac users ... fell silent.

I think that the movie you paid homage to was more realistic unfortunately...

Re: Its as if... (0)

Anonymous Coward | about a month ago | (#47773897)

They are still clinging to their Altivec units.

so why is intel's 14nm haswell still at 3.5 watts? (0, Troll)

lkcl (517947) | about a month ago | (#47773819)

ok, so the effect of RISC vs CISC has absolutely *no* relation to power, right? so why in god's green earth is, for example, the allwinner a20 1.2ghz processor - which is still in 40nm btw - maxing out at 2.5 watts and delivering great 1080p video, reasonable 3D graphics and so on - yet intel is having to go to 14nm and, even at 14nm they STILL can't release a processor that, if you run it in a very limited configuration, is STILL listed as 3.5 watts??

there's a quad-core rockchip 28nm SoC. maximum (actual) top power consumption: below 3.0 watts. intel's haswell tablet SoC is 20nm: it's 4.5 watts "Scenario" Design Power i.e. if you only run certain apps in certain ways it *might* keep below 4.5 watts.

i really _really_ want to know why it is that intel cannot deliver an SoC that has an absolute peak limit of 2.5 watts.

Re:so why is intel's 14nm haswell still at 3.5 wat (1)

Anonymous Coward | about a month ago | (#47773901)

You seem to be conveniently ignoring Intel's Atom and Quark lines. They're all x86 and none of them has a TDP larger than 3w.

Re:so why is intel's 14nm haswell still at 3.5 wat (4, Insightful)

timeOday (582209) | about a month ago | (#47773951)

Here is your answer [7-cpu.com] , the A20 is freakishly slow compared to anything Intel would put their name on.

Granted, you can build a tablet to do specific tasks (like decoding video codecs) around a really slow processor and some special-purpose DSPs. But perhaps the companies in that business aren't making enough profit to interest Intel.

Re:so why is intel's 14nm haswell still at 3.5 wat (0)

Anonymous Coward | about three weeks ago | (#47774577)

Whaddya mean? The A20 beats the pants off of a Pentium 2....

Re:so why is intel's 14nm haswell still at 3.5 wat (0)

Anonymous Coward | about a month ago | (#47773957)

FYI

http://en.wikipedia.org/wiki/List_of_CPU_power_dissipation_figures#Intel_Atom

Below 2.5 watts for roughly 25% of the steppings. And since there's not really a significant advantage to the SoC configuration you describe above (CPU + 3D graphics), unless you're trying to squeeze your system into a thimble, if any of those Atom CPUs don't come with 3D graphics, throw a cheap lower-power 3D graphics chip into the mix and you're still probably under 2.5 watts.

so why is intel's 14nm haswell still at 3.5 watts? (1)

Anonymous Coward | about a month ago | (#47773963)

The examples you described(3D graphics and video decoding) are both handled by the GPU which breaks the data sets down through SIMD. One algorithm single dataset optimization. That really has little to do with anything having to do with this discussion of CPUs.

When comparing the CPU cores between the Allwinner a20 and a broadwell atom. The broadwell atom is more performant by a wide margin.

Re:so why is intel's 14nm haswell still at 3.5 wat (1)

Bill, Shooter of Bul (629286) | about a month ago | (#47773973)

Well, the power consumption of various processor architectures are a *bit* more complicated than RISC vs CISC which is the point of this story.

Re:so why is intel's 14nm haswell still at 3.5 wat (0)

Anonymous Coward | about a month ago | (#47773991)

I have not RTFA but my guess is that Intel is trying to compare apples to apples and that would mean (and again I am assuming) that at the same process (14nm, for instance) and with similar circuit design densities that the power envelope is more or less the same. I am still not convinced, but trying to figure out how they came to that conclusion given that Intel has not come that close to the power efficiencies found in modern RISC designs. I also don't get their scaling argument either as some of the largest (by number of cores) supercomputers in the world are (still) RISC based or are using GPUs that would be closer to RISC designs than CISC given their limited instruction set. Sooo, this sounds like Intel we-are-so-awesome-aren't-we BS.

so why is intel's 14nm haswell still at 3.5 watts? (0)

Anonymous Coward | about a month ago | (#47773999)

If the ISA does not actually affect the performance of a modern processor, then why does the 64-bit ARM architecture outperform the 32-bit. Surely 32-bit ARM code is at least comparable to x86 in architectural elegance.

Re:so why is intel's 14nm haswell still at 3.5 wat (0)

Anonymous Coward | about a month ago | (#47774017)

As ARM chips creep up in processing power and power consumption, there's no good reason to develop in the opposite direction. Intel wants to be where ARM is headed, not where it has been.

1080p video and reasonable 3D graphics are nice to look at, but they're terrible CPU benchmarks, because the CPU only shuffles data into and out of special purpose hardware. You can do high definition video and 3D graphics with a shitty single core ARM processor, provided the dedicated coprocessors do all the work: You've probably heard of the most famous incarnation of that concept, the Raspberry Pi. The Broadcom chip at the core of the Raspberry Pi doesn't even boot using the CPU. The graphics core starts first and loads the firmware. Only then does the CPU start. That's where the ARM world is coming from: Powerful special purpose hardware together with a "microcontroller" of a CPU. Intel is coming from the opposite end of the spectrum, where general purpose processing is king, and special purpose hardware is seen as an optional add-on.

Re:so why is intel's 14nm haswell still at 3.5 wat (0)

Anonymous Coward | about a month ago | (#47774047)

Wait, what? These chips aren't at all comparable in performance. For instance, consider a 7-zip lzma benchmark from http://www.7-cpu.com/:
    A20: 2 cores: 1 ghz: 880 mips compressing, 1560 mips decompressing
    Haswell: 8 cores: 3.4 ghz: 20500 mips compressing, 21000 mips decompressing

Re: so why is intel's 14nm haswell still at 3.5 wa (2)

the_humeister (922869) | about three weeks ago | (#47774159)

No relation to energy used. It's in the article: Haswell will get it's work done faster and use about the same energy as the slower chips that take longer. What matters is architecture, not ISA (Atom is lower power than Haswell at the same process node).

It's a general purpose vs dedicated thing (2, Interesting)

Anonymous Coward | about a month ago | (#47773891)

The CPU ISA isn't the important aspect. Reduced power consumption mostly stems from not needing a high end CPU because the expensive tasks are handled by dedicated hardware. What counts as top of the line ARM hardware can barely touch the processing power of a desktop CPU, but it doesn't need to be faster because all the bulk processing is handled by graphics cores and DSPs. Intel has for a long time tried to stave off the barrage of special purpose hardware. The attempts to make use of ever more general purpose CPU power sometimes bordered on sad clown territory (Remember Intel's attempt to make raytracing games look like something worth pursuing? Guess why: Raytracing is notoriously difficult to implement on graphics hardware due to the almost random data accesses.)

Complexity (0)

Anonymous Coward | about a month ago | (#47773911)

TFA measures how much energy is used for each processor to complete certain tasks, but it ignores how complex each processor is. Unsurprisingly, the processors with more transistors do better. Manufacturing cost is also ignored.

I think it's safe to say... (0)

Type44Q (1233630) | about a month ago | (#47773927)

I think it's safe to say that if a modern RISC processor were manufactured using Intel's latest process tech and given an x86-comparable number of transistors (how many are in Haswell? Or Vishera?) and put to use running a "bare metal" app that was optimized to take advantage of the architecture, it would blow the doors off the equivalent x86 solution.

However, in the real world, x86's flexibility and versatility (including the plethora of developer tools available) win the day.

Re:I think it's safe to say... (0)

Anonymous Coward | about three weeks ago | (#47774161)

It's just inertia, there is a huge legacy base of x86 software that no one wants to rewrite. It's nothing to do with x86's flexibility or versatility, unless you mean Intel's engineering teams' ability to keep slapping on extensions to their 1970's era ISA.

Re:I think it's safe to say... (1)

armanox (826486) | about three weeks ago | (#47774701)

Honest question:

What can you do on x86, that you can't do on POWER or MIPS?

Re:I think it's safe to say... (2)

Type44Q (1233630) | about three weeks ago | (#47774767)

That's easy: maintain compatbility with fucktons of legacy code; arguably more of which exists for x86 than every other architecture combined...

Re:I think it's safe to say... (0)

Anonymous Coward | about three weeks ago | (#47774941)

It's safe to say that you are deeply in denial and ignoring the facts being presented in this article and throughout the media for many years now. You've got some kind of David and Goliath narrative running in your head and you let it smother any objective information that conflicts with your desired outcome. I've often rooted for the little guy, and loved it when I could get a better or more niche product than what Intel offered in large volume, but I had to be honest and recognize when Intel matched them and made them irrelevant.

For many years, I have been using a wide range of hardware, both micro-benchmarking and observing them in general use with Linux and my own development efforts. In the PC, workstation and server space with Linux and many flavors of Unix, I've used Intel and AMD for nearly every generation from the 286 to present, including Xeon/Opteron variants; DEC Alpha; IBM POWER; SPARC and UltraSPARC; MIPS from R2000 to R4400; and even Motorola 68k. In the embedded and SoC space I've used MIPS, ARM, and Atom. I've used variants where nearly the same generation processor core was available in different system configurations with different on-die caches, different system memory buses, and different system I/O bridges.

What I've seen is that the most observable differences in performance and power usage were due total system integrator choices, driven more by economics and product marketing plans than pure technology availability. Very expensive, high margin products could offer better performance by combining the latest in every tech category, but their benefits were often short-lived as the following mid-market products would overtake them in a very small number of years. Similarly, lower power systems could be produced by optimizing the system choices in the other direction, reducing performance.

Individual products have stood out for a moment in time or deviated in performance/watt compared to their peers, but the general trend has been the entire industry converging as economies of scale brought the most exotic tech to the mainstream. This includes cache memory hierarchies; wider word sizes and memory addresses; on-chip memory controllers; MMU and IOMU; SIMD instruction set extensions; multi-core SMP packaging; the abandonment of parallel for high-speed serial I/O as exemplified in SATA and PCIe; 2D and 3D accelerators and GPUs; and the advancement of all of these through semiconductor process improvements and Moore's Law effects.

As a bleeding-edge Linux adopter, I've also seen how much software/OS support is required to get the most out of each platform's capabilities. I've experienced before/during/after as new support was added for every power-saving function from the first kernel use of idle instructions; APM; ACPI; CPU frequency scaling; sleep states for peripheral controllers, disks, and monitors; display back-light control; and aggressive sleeping in Android. Similarly for performance features I experienced as new support was added for DMA; 2D accelerators; SMP; 3D accelerators and GPUs; SIMD instructions; 64-bit; NIC offload; NUMA; hardware virtualization; and again CPU frequency scaling.

None of these major influences in total system performance or power usage would have changed much in either direction if a RISC design was substituted for CISC or vice versa. I can say that confidently because I witnessed how these changes improved systems with the same CPU ISA and core design/process. At the same time, differences between brands at a similar price point were often no larger than these bumps within each product line. Trying to comparison shop for large purchases was often an exercise in frustration as by the time your quotes and procurement went through to delivery, newly released products had once again flipped all your value matrices and price points upside-down.

not now, but it certainly did in the past. (2)

nimbius (983462) | about a month ago | (#47773935)

as a greybeard I remember when choosing Intel over Sun meant the project wasnt completed on time, and your electrical/mechanical engineering group lived in the breakroom while their jobs chugged along. Intel was a toy train compared to the power you'd get with RISC. however I can somewhat confidently say the RISC CISC battle is moot these days because x86 has largely caught up to power, sparc, and others. a competent argument could be made however that if it werent for AMD, most servers would probably still be running some flavour of RISC. The foolhardy nature of SUN and SGI can also be argued as a cause of their demise, but ill not flame. Intel wouldn't have bothered to get off their duff without a poke in the ribs from AMD; they had partnerships with RISC manufacturers anyhow and their own RISC-ish processor called itanium. outside of performance though there is another reason people stick with Power and others just as they have in the past. Lock-in.

you see, applications like Oracle Business Objects and JD Edwards come with a quid-pro-quo of exacting standards to which most businesses must adhere. Namely, IBM or Sun/Oracle hardware. You may only need accounting and payroll, but you'll have to clear a corner of the room for the circus to set up their hardware and make sure everything is "just so." Their hope is that their quiet mandate becomes your quiet mandate, and before you know it other systems that interact with JDE are now required to be Power-based because "thats what runs JDE." The only way out of this is to realize that any business that doesnt explicitly do payroll or metrics for profit, doesnt need the kind of horsepower decreed by things like SAP.

Re: not now, but it certainly did in the past. (1)

the_humeister (922869) | about three weeks ago | (#47774623)

Intel has had several RISC chips (eg i960), but Itanium is VLIW (ie not RISC or CISC).

Certainly it can be argued that it's AMD's fault for the current dominance of x86, but it's also true that none of the other architectures were cheap enough for the general populace to adopt, hence the abundance of ARM nowadays and POWER, SPARC, and currently on life support

Re:not now, but it certainly did in the past. (0)

Anonymous Coward | about three weeks ago | (#47776027)

In the light desktop workstation performance race Intel started to make their mark when they released the original Pentium against the then available RISC competitors and the i486s. I fondly remember how supreme the HP RISC's floating point performance was then, compared to the others at that specific point in time.

efficiency matters (2)

bzipitidoo (647217) | about a month ago | (#47774093)

This study looks seriously flawed. They just throw up their hands at doing a direct comparison of architectures when they try to use extremely complicated systems and sort of do their best to beat down and control all the factors that introduces. One of the basic principles of a scientific study is that independent variables are controlled. It's very hard to say how much the instruction set architecture matters when you can't tell what pipelining, out of order execution, branch prediction, speculative execution, caching, shadowing (of registers), and so on are doing to speed things up. An external factor that could influence the outcome is temperature. Maybe one computer was in a hotter corner of the test lab than the other, and had to spend extra power just overcoming the higher resistance that higher temperatures cause.

It might have been better to approach this from an angle of simulation. Simulate a more idealized computer system, one without so many factors to control.

Don't be silly (1)

tobiasly (524456) | about three weeks ago | (#47774125)

RISC architecture is going to change everything.

Re:Don't be silly (1)

mean pun (717227) | about three weeks ago | (#47774561)

RISC architecture is going to change everything.

Agreed, as soon as they can do submicron technology. By the way, for some strange reason I feel like I've been sleeping a decade.

Re:Don't be silly (1)

Java Pimp (98454) | about three weeks ago | (#47774825)

RISC is good!

Re:Don't be silly (1)

jellomizer (103300) | about three weeks ago | (#47774915)

They did... 20 years ago... CISC had changed its ways to be more RISCy

Re:Don't be silly (0)

Anonymous Coward | about three weeks ago | (#47774995)

It's okay, I get the reference.

The article is bad - mfg technology dominates (2)

hkultala (69204) | about three weeks ago | (#47774131)

They are seriously comparing some 90nm process with much better intel 32nm and 45 nm processes.

They have just taken some random cores made on random (and uncomparable) manufacturing technologies, throw couple of benchmarks and try to declare universal results based on these.

Few facts about the benchmarks setup and the cores cores:

1) They use ancient version of GCC. ARM suffers this much more than x86.
2) Bobcat is relatively balanced core, no bad bottlenecks. mfg tech is cheap, not high performance but relatively small/new.
3) Cortex A8 and A9 are really starved by bad cache design. Newer A7 and A12 would be similar in area and powet consumption but much better in performance and performance/power. There are also manufactured on old cheap mfg processes, which hurt them. Use modern manufacturing tech and results are quite much better
4) Their loonson is made on ANCIENT technology. With modern mfg tech it would be many times better on performance/power.
5) The cortex A15, even though made on 32nm process, is cheap process, not much better than intel's 45nm process and much worse than intel's 32nm. Also it's known to be a "power hog"-design. Qualcomm's Krait has similar performance level, but with much lower power.

Re:The article is bad - mfg technology dominates (1)

WorBlux (1751716) | about three weeks ago | (#47776085)

Yes, the Ingenic MIPS are a good example of modern MIPS design, with quad core at 1GHZ comeing in at a one watt TDP. The loonbson 3B probably could have beat the i7 on some workloads if it had come out on schedual and a modern process. Now that intel has openCL support it's less likely as half the cores in the loongson 3 series are/were supposed to bed dedicated vector processing units. Another interesting comparison would be the MIPS Tilera design vs. Intel's x86 Knights/table Many Integrated Cores (x86-MIC) design. I would think it's easier to fits lots of MIPS cores on a chip, but then again the x86-MIC leaves a lot of the fancier parts out of the cores.

Re:The article is bad - mfg technology dominates (1)

edxwelch (600979) | about three weeks ago | (#47776087)

From the origonal paper www.cs.wisc.edu/vertical/papers/2013/hpca13-isa-power-struggles.pdf (which ExtremeTech does not link to):

Technology scaling and projections:
Since the i7 processor is 32nm and the Cortex-A8 is 65nm, we use technology node characteristics from the 2007 ITRS tables to normalize to the 45nm technology node in two results where we factor out tech-
nology; we do not account for device type (LOP, HP, LSTP).
For our 45nm projections, the A8â(TM)s power is scaled by 0.8Ã-- and
the i7â(TM)s power by 1.3Ã--. In some results, we scale frequency
to 1 GHz, accounting for DVFS impact on voltage using the
mappings disclosed for Intel SCC [5]. When frequency scal-
ing, we assume that 20% of the i7â(TM)s power is static and does
not scale with frequency; all other cores are assumed to have
negligible static power. When frequency scaling, A8â(TM)s power is
scaled by 1.2Ã--, Atomâ(TM)s power by 0.8Ã--, and i7â(TM)s power by 0.6Ã--.
We acknowledge that this scaling introduces some error to our
technology-scaled power comparison, but feel it is a reasonable
strategy and doesnâ(TM)t affect our primary findings (see Table 4).

Final nail in the Itanium coffin (1, Interesting)

Christian Smith (3497) | about three weeks ago | (#47774165)

20 years ago, RISC vs CISC absolutely mattered. The x86 decoding was a major bottleneck and transistor budget overhead.

As the years have gone by, the x86 decode overhead has been dwarfed by the overhead of other units like functional units, reorder buffers, branch prediction, caches etc. The years have been kind to x86, making the x86 overhead appear like noise in performance. Just an extra stage in an already long pipeline.

All of which paints a bleak picture for Itanium. There is no compelling reason to keep Itanium alive other than existing contractual agreements with HP. SGI was the only other major Itanium holdout, and they basically dumped it long ago. And Itaiums are basically just glorified space heaters in terms of power usage.

Re:Final nail in the Itanium coffin (1)

trparky (846769) | about three weeks ago | (#47774815)

You can't add too many stages to the pipeline or you end up with the Intel NetBurst Pentium 4 Prescott mess again. It had an horrendously long 31-stage pipeline. Can you say... Branch Prediction Failure? The damn thing produced more branch prediction failures than actual work. That's essentially why the NetBurst was completely scrapped and why they went back to the drawing board.

Re:Final nail in the Itanium coffin (1)

phantomfive (622387) | about three weeks ago | (#47775347)

As the years have gone by, the x86 decode overhead has been dwarfed by the overhead of other units like functional units, reorder buffers, branch prediction, caches etc. The years have been kind to x86, making the x86 overhead appear like noise in performance. Just an extra stage in an already long pipeline.

And all that long pipeline takes power to run (recently this argument comes up in discussions of mobile devices more than in the server room, because battery life is hugely important, and ARM in the serverroom is still a joke). ARM chips sometimes don't even have cache, let alone reorder buffers, and branch prediction. When you remove all that stuff, the ISA becomes more important in terms of power consumption.

Of course, as someone else pointed out, they were comparing 90nm chips to 32nm and 45nm. Why that is a problem will be left as an exercise for the reader.

Re:Final nail in the Itanium coffin (0)

Anonymous Coward | about three weeks ago | (#47775953)

RISC has another, more serious problem.

It relies on the myth that you can either:
Depend on programmers to right theoretically awesome code
or
One can write a magic compiler that can do the above for you automatically

We all know what the answer to these questions are. Code is, by and large, crap. Modern processors spend most of their time effectively de-crapping code and predicting what crap will come down the wire next (TO avoid really slow main memory fetching). Actual execution is almost secondary.

When it comes down to it, in general purpose computing you'll do a lot better betting on your hardware engineers than you will your programmers.

GENERALLY SPEAKING: The guys that make the processors are brilliant. The average programmer is a bullshit artist in comparison. (Market forces cause this)

The best computing platform will be the one that can run bad code the best. Nobody has time to right clean, perfect, mathematically sound, arch specific code for every application.

Re:Final nail in the Itanium coffin (2)

WuphonsReach (684551) | about three weeks ago | (#47776197)

All of which paints a bleak picture for Itanium. There is no compelling reason to keep Itanium alive other than existing contractual agreements with HP. SGI was the only other major Itanium holdout, and they basically dumped it long ago. And Itaiums are basically just glorified space heaters in terms of power usage.

Itanium was dead on arrival.

It ran existing x86 code much slower. So if you wanted to move up to 64bit (and use Itanium to get there), you had to pay a lot more for your processors, just to run your existing workload.

Okay, you say, but everyone was supposed to stop running x86 and start running Itanium binaries! Please put down the pipe and come back to reality. No company is going to repurchase all of their software to run on a new platform, just because Intel says this is the way forward.

Maybe, maybe! If all of the business software was open-source and easily ported to a different CPU architecture it might have worked. But only if you'd gain a 3x-5x improvement in wall clock performance by porting from x86 to Itanium instruction sets. (An advantage that never materialized.)

And once AMD started shipping AMD64 and Opterons that could run your existing x86 workload, on a 64bit CPU, at slightly fastter speeds then your old kit for the same price - that buried any chance of Itanium ever succeeding in the market. Any forward looking IT person, when it came time to upgrade old kit, chose AMD64 - because while they might be running 32bit OS/progs today, the 64bit train was rumbling down the tracks. So picking a chip that could do both, and do both well, was the best move.

REAL RISC? (1)

gelfling (6534) | about three weeks ago | (#47774297)

Because years and years ago it was obvious that what manufacturers were calling RISC wasn't really that. It was typically some middle ground between REAL RISC and something else. Back in the day x86 had about 374 instructions and a SUN or analogous IBM chip had about 150-175 instructions. But according to the actual science, a RISC chip should only have 30-45 instructions. So for the sake of flexibility manufacturers split the difference and built chips that were neither fish nor fowl. If someone to actually have a real high power chip that ran only 40 instructions I wonder if the benchmarks would come out differently. Or maybe they wouldn't because the benchmarks themselves make some attempt to model the complexity of real world scenarios. And if that's the case then the REAL RISC chips would be stumbling trying to execute most things in software not the instruction set.

Re:REAL RISC? (1)

VTBlue (600055) | about three weeks ago | (#47774789)

I'm waiting for a 'true Scotsman' comment :)

Intel x86 CISC is converted to RISC via Microcode (1)

VTBlue (600055) | about three weeks ago | (#47774773)

As mentioned over many years of slashdot posts, x86 as a hardware instruction no longer truly exists and represents a fraction of the overall die space. The real bread and butter of CPU architecture and trade secrets rests in the microcode that is unique in every generation or edition of a processor. Today all intel processors are practically RISC.

Wrong conclusion (0)

edxwelch (600979) | about three weeks ago | (#47775313)

If you look at the graph "raw average energy normalised" you see that the ARM A9 core has the lowest energy score -> that clearly shows ARM being the most efficient and hence the conclusion is completely wrong.
Still the test is very interesting. I would like to see it updated with latest CPUs

Original sources (2)

enriquevagu (1026480) | about three weeks ago | (#47775417)

It is really surprising that neither the linked Extremetech article, nor the slashdot summary cite the original source. This research was presented in HPCA'13 [carch.ac.cn] in a paper titled "Power Struggles: Revisiting the RISC vs. CISC Debate on Contemporary ARM and x86 Architectures", by Emily Blem [wisc.edu] et al, from the University of Wisconsin's Vertical Research group [wisc.edu] , led by Dr. Karu Sankaralingam. You can find the original conference paper [wisc.edu] in their website.

The Extremtech article indicates that there are new results with some additional architectures (MIPS Loongson and AMD processors were not included in the original HPCA paper), so I assume that they have published an extended journal version of this work, which is not yet listed in their website. Please add a comment if you have a link to the new work.

I do not have any relation with them, but I knew the original HPCA work.

Research performed by Intel.... (0)

Anonymous Coward | about three weeks ago | (#47775635)

This is all brought to you by labs run by Intel. Why are were even talking about this? There's nothing here but marketing.

The real difference is commodity vs custom (1)

UnknowingFool (672806) | about three weeks ago | (#47776923)

These days the instruction set matters less than the underlying chip architecture than customization. With this, ARM has an advantage in that their business model allows for higher degree of customization. While some companies can work with Intel or AMD on their designs, for the most part, ARM allows them to change the design as much as they need depending on the licensing.
Load More Comments
Slashdot Login

Need an Account?

Forgot your password?

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>