5 ms·

As someone who has little idea about chip design: is there that much room for benefit purely from instruction set? i.e. if someone were to design the Optimum In

As someone who has little idea about chip design: is there that much room for benefit purely from instruction set? i.e. if someone were to design the Optimum Instruction Set [and perhaps it'd have to be optimum in only some types of workloads at the expense of others?] and start building chips with it, how much advantage would they really have over, say, x64? Maybe a good question to go alongside this: if two teams of equal capability with equal access to fabs, patents, etc were to both start completely fresh, one team making the best x64 chip they could and one team making the best ARM chip they could, how much difference would there be in speed and power-consumption between the end products?

alanctgardner2 14y ago
The thing is, CISC vs. RISC seems to be an ideological debate more than anything else. The only reason I suggested designing a RISC CPU is because a) ARM has made RISC for servers sexy again, and b) Intel already tried a CISC chip with Itanium, and another would scare vendors pretty badly. The big difficulty I see is designing an instruction set, architecture and compiler which can show serious performance gains for workloads that matter. Making it easy for developers to come over from x64 while juicing the performance per clock would be a big win. P.S. I'm not a CPU expert by any means. My understanding is that x86_64 has a big legacy overhead from implementing backwards compatibility with x86, and a goal of Itanium was to reduce the amount of the die dedicated to backwards compatibility. If anyone wants to correct me, feel free.
- haberman 14y ago
  I don't think Itanium was CISC, they call it "EPIC" (explicitly parallel instruction computing: http://en.wikipedia.org/wiki/Explicitly_parallel_instruction_computing http://en.wikipedia.org/wiki/Explicitly_parallel_instruction...). The basic idea of this was to move logic about what could be parallelized from the CPU to the compiler, but this turned out not to work so well. In Donald Knuth's words, "The Itanium approach...was supposed to be so terrific—until it turned out that the wished-for compilers were basically impossible to write."
ComputerGuru 14y ago
RISC vs CISC doesn't matter any more. I wrote an article (once featured on HN, when ARM first began making waves) that is basically "a crashcourse on CPU architecture for dummies" on my blog: http://neosmart.net/blog/2010/the-arm-the-ppc-the-x86-and-the-ipad/ http://neosmart.net/blog/2010/the-arm-the-ppc-the-x86-and-th... The tl;dr of it is that today, the RISC vs CISC or ARM vs x86 debate doesn't really matter - that's just a question of what "APIs" (if you will) are exposed from the CPU. Internally, they're all approaching working the same way.
MichaelSalib 14y ago
how much difference would there be in speed and power-consumption between the end products? Probably not much right away, but over time, you'd see a real difference. One key issue is that x86 decode logic takes a substantial amount of engineering time to design in each generation. My spouse is a design engineer at a CPU maker and one thing I've learned is that there's a lot less automation than you'd think. Each new generation requires a bunch of dedicated engineering resources to make the extra-painful instruction decode work on a the new process with new performance constraints, etc. Decode is not something you can design once and then just reuse indefinitely; you take the NRE hit on every design cycle.
- helmut_hed 14y ago
  Actually I would think that instruction decoding is one of the few things you can reuse... that pipeline stage is typically not the performance limiter, and the instruction set only makes small changes each generation. When I was a chip designer that block usually got assigned to the least experienced team :)
  - MichaelSalib 14y ago
    Note that actual CPU designers spend a significant amount of time doing routing and other tasks that you might think would be completely automated. So while you might have a block of verilog code that specifies the RTL for your decode unit, and you can certainly reuse that, each new chip will require you to redo routing at different levels which will require lots of engineering time. Spending time on that might be fine if x86 ISA was getting you a significant performance advantage, but since it is not, the extra NRE you blow on physical optimization of decode logic is just wasted effort that could be better spent elsewhere.
MichaelSalib 14y ago
I think a bigger issue though is high clock speeds forced on the industry for marketing reasons. Current pipelines are way way to deep, but they can never come down because that would decrease clock rates and lots of people have been trained into believing that clock speeds indicate performance. If Intel & AMD could convince the world to ignore clock rates, we'd get chips that had slightly higher throughput with much lower power consumption and slightly faster design cycles.
- MichaelSalib 14y ago
  Whoah. Downvoters, care to explain your logic here? Or do you think that 30+ stage pipeline in actually optimal for improving ILP?
  - rz2k 14y ago
    I didn't downvote but: >they can never come down because that would decrease clock rates and lots of people have been trained into believing that clock speeds indicate performance is a bold statement that is not likely to be true. Casual metrics of performance change, and I doubt there are many people confused as to whether they choose a 4GHz Pentium 4 over a lower clocked Core 2, much less something like a Xeon E5.
    - wmf 14y ago
      Perhaps people are not confused simply because those older processors are no longer sold. AMD certainly felt the need to fudge their frequency back in the K7 days (although megahurtz marketing may be specific to the desktop market).
  - wmf 14y ago
    I didn't downvote you, but there is research from Intel, IBM, and others showing that very deep pipelines (they disagree on the exact numbers) are indeed optimal if power isn't a concern (which it wasn't until ca. 2003). http://web.archive.org/web/20021211202017/http://systems.cs.colorado.edu/ISCA2002/ http://web.archive.org/web/20021211202017/http://systems.cs....
rogerbinns 14y ago
There is an excellent talk titled "Things CPU architects need to think about" from Stanford's ee380 class. Go to http://www.stanford.edu/class/ee380/ay0304.html http://www.stanford.edu/class/ee380/ay0304.html and pick the Feb 18'th entry (click on the old school icon on the right). It will play with vlc on Linux and Windows Media Player on Windows. Although the talk is from 9 years ago, the material covered is still very relevant today. It is also quite funny. One of the things talked about is the processing of instructions and chaos theory, including non-intuitive stuff like inserting delays to make things run faster! It should be noted that x86 processors haven't executed x86 instructions since the early nineties. They are translated into risc like micro-ops. The translation takes a very small fraction of the die area and it gets smaller which each generation of chip/process. The difference between x86 processor implementations and ARM is that x86 try to get the greatest throughput possible. This is done via techniques like having multiple execution units and executing instructions in parallel where possible (known as ILP and typical values are 2.1), executing instructions out of order where it doesn't make a difference to the results, executing multiple instructions in stages concurrently (pipelines), having tracking for branches to better predict if they will be taken, speculative execution of both parts of a branch at the same time and throwing away the one that turns out not to be taken, complex memory machinery to keep code and data flowing, high clock speeds for the die as a whole, and even higher ones for parts if not all in use and the list goes on. This is not a requirement of x86 implementations but is what most of them do. Intel goes very far down this road, AMD not quite so far, and some implementations like Atom do barely any of it. ARM processors generally do none of that. It keeps them smaller and simpler, which means lower performance and less power. For your final paragraph, the instruction set is largely irrelevant. While x86 does have some warts, ARM does too (eg condition codes). The thing you left out is compilers as they generate the code to be executed. Roughly speaking the answer is the winner will be whoever has the better compilers. BTW Moore's law predicts transistor doubling per area every 18 months which most paraphrase as performance will double every 18 months. Someone did a study on compilers and found that compilers double performance about every 18 years! Because ARM execution has been so simple for so long (eg no concurrent execution of instructions) the compilers haven't mattered that much. In a maximum performance world they matter a lot more, especially with instruction scheduling. And of course most programs would have been compiled a while ago, and probably use conservative optimisations (more aggressive ones can introduce bugs). With Itanium Intel had the idea of making the chip 6 way parallel and let the compiler figure out how to use that (ie smart compiler, dumb/simple chip). It didn't really work.
Symmetry 14y ago
The biggest advantages ARM has over Intel are all probably memory related. x86 will tend to have have more memory operations for doing a given thing, and with x86's stricter memory model it will be harder to design a system with lots of outstanding memory operations. ARM's simpler decoding is also an advantage from a power consumption standpoint, if nothing else. These aren't huge, though, and I'd give ARM a maybe 15% advantage or so? But remember that all things aren't equal, and Intel has a big lead in fabrication techniques over everyone else, and lots of huge teams of chip architects.

alanctgardner2 14y ago

The thing is, CISC vs. RISC seems to be an ideological debate more than anything else. The only reason I suggested designing a RISC CPU is because a) ARM has made RISC for servers sexy again, and b) Intel already tried a CISC chip with Itanium, and another would scare vendors pretty badly. The big difficulty I see is designing an instruction set, architecture and compiler which can show serious performance gains for workloads that matter. Making it easy for developers to come over from x64 while juicing the performance per clock would be a big win. P.S. I'm not a CPU expert by any means. My understanding is that x86_64 has a big legacy overhead from implementing backwards compatibility with x86, and a goal of Itanium was to reduce the amount of the die dedicated to backwards compatibility. If anyone wants to correct me, feel free.

haberman 14y ago
I don't think Itanium was CISC, they call it "EPIC" (explicitly parallel instruction computing: http://en.wikipedia.org/wiki/Explicitly_parallel_instruction_computing http://en.wikipedia.org/wiki/Explicitly_parallel_instruction...). The basic idea of this was to move logic about what could be parallelized from the CPU to the compiler, but this turned out not to work so well. In Donald Knuth's words, "The Itanium approach...was supposed to be so terrific—until it turned out that the wished-for compilers were basically impossible to write."

ComputerGuru 14y ago

RISC vs CISC doesn't matter any more. I wrote an article (once featured on HN, when ARM first began making waves) that is basically "a crashcourse on CPU architecture for dummies" on my blog: http://neosmart.net/blog/2010/the-arm-the-ppc-the-x86-and-the-ipad/ http://neosmart.net/blog/2010/the-arm-the-ppc-the-x86-and-th... The tl;dr of it is that today, the RISC vs CISC or ARM vs x86 debate doesn't really matter - that's just a question of what "APIs" (if you will) are exposed from the CPU. Internally, they're all approaching working the same way.

MichaelSalib 14y ago

how much difference would there be in speed and power-consumption between the end products? Probably not much right away, but over time, you'd see a real difference. One key issue is that x86 decode logic takes a substantial amount of engineering time to design in each generation. My spouse is a design engineer at a CPU maker and one thing I've learned is that there's a lot less automation than you'd think. Each new generation requires a bunch of dedicated engineering resources to make the extra-painful instruction decode work on a the new process with new performance constraints, etc. Decode is not something you can design once and then just reuse indefinitely; you take the NRE hit on every design cycle.

helmut_hed 14y ago
Actually I would think that instruction decoding is one of the few things you can reuse... that pipeline stage is typically not the performance limiter, and the instruction set only makes small changes each generation. When I was a chip designer that block usually got assigned to the least experienced team :)
- MichaelSalib 14y ago
  Note that actual CPU designers spend a significant amount of time doing routing and other tasks that you might think would be completely automated. So while you might have a block of verilog code that specifies the RTL for your decode unit, and you can certainly reuse that, each new chip will require you to redo routing at different levels which will require lots of engineering time. Spending time on that might be fine if x86 ISA was getting you a significant performance advantage, but since it is not, the extra NRE you blow on physical optimization of decode logic is just wasted effort that could be better spent elsewhere.

MichaelSalib 14y ago

I think a bigger issue though is high clock speeds forced on the industry for marketing reasons. Current pipelines are way way to deep, but they can never come down because that would decrease clock rates and lots of people have been trained into believing that clock speeds indicate performance. If Intel & AMD could convince the world to ignore clock rates, we'd get chips that had slightly higher throughput with much lower power consumption and slightly faster design cycles.

MichaelSalib 14y ago
Whoah. Downvoters, care to explain your logic here? Or do you think that 30+ stage pipeline in actually optimal for improving ILP?
- rz2k 14y ago
  I didn't downvote but: >they can never come down because that would decrease clock rates and lots of people have been trained into believing that clock speeds indicate performance is a bold statement that is not likely to be true. Casual metrics of performance change, and I doubt there are many people confused as to whether they choose a 4GHz Pentium 4 over a lower clocked Core 2, much less something like a Xeon E5.
  - wmf 14y ago
    Perhaps people are not confused simply because those older processors are no longer sold. AMD certainly felt the need to fudge their frequency back in the K7 days (although megahurtz marketing may be specific to the desktop market).
- wmf 14y ago
  I didn't downvote you, but there is research from Intel, IBM, and others showing that very deep pipelines (they disagree on the exact numbers) are indeed optimal if power isn't a concern (which it wasn't until ca. 2003). http://web.archive.org/web/20021211202017/http://systems.cs.colorado.edu/ISCA2002/ http://web.archive.org/web/20021211202017/http://systems.cs....

rogerbinns 14y ago

There is an excellent talk titled "Things CPU architects need to think about" from Stanford's ee380 class. Go to http://www.stanford.edu/class/ee380/ay0304.html http://www.stanford.edu/class/ee380/ay0304.html and pick the Feb 18'th entry (click on the old school icon on the right). It will play with vlc on Linux and Windows Media Player on Windows. Although the talk is from 9 years ago, the material covered is still very relevant today. It is also quite funny. One of the things talked about is the processing of instructions and chaos theory, including non-intuitive stuff like inserting delays to make things run faster! It should be noted that x86 processors haven't executed x86 instructions since the early nineties. They are translated into risc like micro-ops. The translation takes a very small fraction of the die area and it gets smaller which each generation of chip/process. The difference between x86 processor implementations and ARM is that x86 try to get the greatest throughput possible. This is done via techniques like having multiple execution units and executing instructions in parallel where possible (known as ILP and typical values are 2.1), executing instructions out of order where it doesn't make a difference to the results, executing multiple instructions in stages concurrently (pipelines), having tracking for branches to better predict if they will be taken, speculative execution of both parts of a branch at the same time and throwing away the one that turns out not to be taken, complex memory machinery to keep code and data flowing, high clock speeds for the die as a whole, and even higher ones for parts if not all in use and the list goes on. This is not a requirement of x86 implementations but is what most of them do. Intel goes very far down this road, AMD not quite so far, and some implementations like Atom do barely any of it. ARM processors generally do none of that. It keeps them smaller and simpler, which means lower performance and less power. For your final paragraph, the instruction set is largely irrelevant. While x86 does have some warts, ARM does too (eg condition codes). The thing you left out is compilers as they generate the code to be executed. Roughly speaking the answer is the winner will be whoever has the better compilers. BTW Moore's law predicts transistor doubling per area every 18 months which most paraphrase as performance will double every 18 months. Someone did a study on compilers and found that compilers double performance about every 18 years! Because ARM execution has been so simple for so long (eg no concurrent execution of instructions) the compilers haven't mattered that much. In a maximum performance world they matter a lot more, especially with instruction scheduling. And of course most programs would have been compiled a while ago, and probably use conservative optimisations (more aggressive ones can introduce bugs). With Itanium Intel had the idea of making the chip 6 way parallel and let the compiler figure out how to use that (ie smart compiler, dumb/simple chip). It didn't really work.

Symmetry 14y ago

The biggest advantages ARM has over Intel are all probably memory related. x86 will tend to have have more memory operations for doing a given thing, and with x86's stricter memory model it will be harder to design a system with lots of outstanding memory operations. ARM's simpler decoding is also an advantage from a power consumption standpoint, if nothing else. These aren't huge, though, and I'd give ARM a maybe 15% advantage or so? But remember that all things aren't equal, and Intel has a big lead in fabrication techniques over everyone else, and lots of huge teams of chip architects.