5 ms·

Because they are not there yet...

rbanffy 10y ago
When an ARM chip reaches the performance of a Xeon, it'll draw about as much power as a Xeon. There is no magic - computation has a minimum energy cost. What can happen is to make chips simpler in that less computation is spent in instruction decoding, tracking, scheduling and more is spent on actual execution.
- kodfodrasz 10y ago
  Yes, I implied this.
- anodin3 10y ago
  >When an ARM chip reaches the performance of a Xeon, it'll draw about as much power as a Xeon. There is absolutely no reason to reach that conclusion.
  - bsder 10y ago
    Power goes as C v^2 f. At best. That doesn't change. If you look at a particular technology node, one of the best correlations of power consumption is chip area. It's pretty much a straight line. Now, that has probably changed a bit with how aggressively we turn chip areas off nowadays. So, we probably have to alter that to power consumption vs active chip area--but it's still a fixed line for a technology node.
    - rbanffy 10y ago
      Speaking of chip area, one possible path is designing ISAs that require less silicon to efficiently decode, reorder and retire. It'd be, of course, totally incompatible with what we have now.
      - bsder 10y ago
        We call that MIPS or Alpha, and it lost to x86 compatibility. Whose only competitor is ARM, which is little better in terms of decoding complexity.
        wolfgke 10y ago
        > Whose only competitor is ARM, which is little better in terms of decoding complexity. T32 indeed has this problem, but not A32. With ARMv8 ARM released the A64 instruction set, which is designed new from ground up and is to my knowledge also not hard to decode. Nevertheless decoding complexity is not that relevant anymore. What is much harder and involves more die area is (super-)pipelining the execution, out-of-order execution etc. But even all this together: What consumes most die area are typically the caches.
        rbanffy 10y ago
        Caches are transistor-dense, it's hard to optimize them further. Maybe something like Transmeta's architecture, a hybrid software/hardware approach would yield some improvement.
  - dom0 10y ago
    Actually there is plenty of precedent for that conclusion. Scaling CPU cores up (=efficient but high performance cores) is super-hard -- making low-power cores is pretty simple in comparison --; almost everyone fails or failed at it. Currently there are two companies on the planet that do that sort of thing, and not so long ago it was only one. Notable names that failed hard in this are: Intel, DEC, Sun, Fujitsu, AMD, IBM, HP, Intel, as well as SGI, IBM and AMD.
    - rbanffy 10y ago
      It's not unlike designing a race car. You can put a monster engine, but it'll add weight, require more fuel, add inertia which will demand a more complicated suspension and wider, heavier tires to be able to do fast curves, and so on. The careful balance of every aspect of a modern CPU is an art very few people practice. I'd say IBM and Sun have't left this game just yet for very high performance platforms, but don't expect a Core i3 coming out of either.
      - dom0 10y ago
        True, IBM and Fujitsu/Sun are still competitive in some niches, but not on power efficiency and not for general purpose application. Last time I looked IBM was 3-5 times worse perf/Watt in SAP benchmarks. Of course IBM is still an option in these specialized applications if you just need that raw power, but no one's going to run a data centre on that silicon.
    - Scuds 10y ago
      If everything gets cracked to micro-ops anyway, how much effect does your general instruction(not SIMD/Altivec/Thumb etc) set _really_ have on performance and power consumption?
- Someone 10y ago
  I would think that, nowadays, reading and writing memory are major bottlenecks, too, to the extent that spending time decoding instructions can be a gain if it allows for a denser instruction stream. For machine learning applications, I don't think the end game is to have complex CPUs, though. Assuming that brains have managed to find more than a local optimum and that our understanding of them is somewhat accurate, ditching all those caches, translation buffers, etc. most of the bus bandwidth, and moving computation towards memory is the way to (eventually; we need to learn a lot before that's feasible) go for machine learning applications. Does the brain even have instruction decoders?
  - copperx 10y ago
    > Does the brain even have instruction decoders? I can't even begin to understand this question. It makes no sense at all.
- Zaak 10y ago
  Back in the 80s, instruction decode was a large part of the logic in a CPU (thus the motivation for RISC). Currently, it's a tiny fraction. It's been many years since a simpler instruction set was useful for reducing the complexity of the CPU.
  - wtallis 10y ago
    But that portion of the power budget hasn't shifted at all back toward the computational units. It's been taken over by register renaming and instruction reordering and all manner of caches.
    - adrianratnapala 10y ago
      But is RISC the solution to that problem? Having lots of registers helps, I guess. But the amd64 already has quite a lot. These problems seem to be what VLIW architectures like tried to to solve. Is that sort of architecture going to make a comeback? Will even that help?
      - rbanffy 10y ago
        > But the amd64 already has quite a lot. 16 registers is not a lot when compared to other architectures. POWER, SPARC, Arm64 and MIPS have 32 (SPARC is weird, but 32 are always visible). Itanium has 128.
        luca_ing 9y ago
        I'm far from an expert on CPU architectures, but I suppose there are diminishing returns. Most of my functions use less than 16 values, and those that do may well iterate over more than 128. Also you're probably aware that modern CPUs have many more physical registers, they just don't expose them all at the same time. E.g. AMD Zen physically has 168 integer and 160 floating-point registers. Of which you can only use 16 at a time, but to my uninformed eye that looks like a reasonable trade-off.
    - Zaak 10y ago

When an ARM chip reaches the performance of a Xeon, it'll draw about as much power as a Xeon. There is no magic - computation has a minimum energy cost. What can happen is to make chips simpler in that less computation is spent in instruction decoding, tracking, scheduling and more is spent on actual execution.

kodfodrasz 10y ago
Yes, I implied this.
anodin3 10y ago
>When an ARM chip reaches the performance of a Xeon, it'll draw about as much power as a Xeon. There is absolutely no reason to reach that conclusion.
- bsder 10y ago
  Power goes as C v^2 f. At best. That doesn't change. If you look at a particular technology node, one of the best correlations of power consumption is chip area. It's pretty much a straight line. Now, that has probably changed a bit with how aggressively we turn chip areas off nowadays. So, we probably have to alter that to power consumption vs active chip area--but it's still a fixed line for a technology node.
  - rbanffy 10y ago
    Speaking of chip area, one possible path is designing ISAs that require less silicon to efficiently decode, reorder and retire. It'd be, of course, totally incompatible with what we have now.
    - bsder 10y ago
      We call that MIPS or Alpha, and it lost to x86 compatibility. Whose only competitor is ARM, which is little better in terms of decoding complexity.
      - wolfgke 10y ago
        > Whose only competitor is ARM, which is little better in terms of decoding complexity. T32 indeed has this problem, but not A32. With ARMv8 ARM released the A64 instruction set, which is designed new from ground up and is to my knowledge also not hard to decode. Nevertheless decoding complexity is not that relevant anymore. What is much harder and involves more die area is (super-)pipelining the execution, out-of-order execution etc. But even all this together: What consumes most die area are typically the caches.
        rbanffy 10y ago
        Caches are transistor-dense, it's hard to optimize them further. Maybe something like Transmeta's architecture, a hybrid software/hardware approach would yield some improvement.
- dom0 10y ago
  Actually there is plenty of precedent for that conclusion. Scaling CPU cores up (=efficient but high performance cores) is super-hard -- making low-power cores is pretty simple in comparison --; almost everyone fails or failed at it. Currently there are two companies on the planet that do that sort of thing, and not so long ago it was only one. Notable names that failed hard in this are: Intel, DEC, Sun, Fujitsu, AMD, IBM, HP, Intel, as well as SGI, IBM and AMD.
  - rbanffy 10y ago
    It's not unlike designing a race car. You can put a monster engine, but it'll add weight, require more fuel, add inertia which will demand a more complicated suspension and wider, heavier tires to be able to do fast curves, and so on. The careful balance of every aspect of a modern CPU is an art very few people practice. I'd say IBM and Sun have't left this game just yet for very high performance platforms, but don't expect a Core i3 coming out of either.
    - dom0 10y ago
      True, IBM and Fujitsu/Sun are still competitive in some niches, but not on power efficiency and not for general purpose application. Last time I looked IBM was 3-5 times worse perf/Watt in SAP benchmarks. Of course IBM is still an option in these specialized applications if you just need that raw power, but no one's going to run a data centre on that silicon.
  - Scuds 10y ago
    If everything gets cracked to micro-ops anyway, how much effect does your general instruction(not SIMD/Altivec/Thumb etc) set _really_ have on performance and power consumption?
Someone 10y ago
I would think that, nowadays, reading and writing memory are major bottlenecks, too, to the extent that spending time decoding instructions can be a gain if it allows for a denser instruction stream. For machine learning applications, I don't think the end game is to have complex CPUs, though. Assuming that brains have managed to find more than a local optimum and that our understanding of them is somewhat accurate, ditching all those caches, translation buffers, etc. most of the bus bandwidth, and moving computation towards memory is the way to (eventually; we need to learn a lot before that's feasible) go for machine learning applications. Does the brain even have instruction decoders?
- copperx 10y ago
  > Does the brain even have instruction decoders? I can't even begin to understand this question. It makes no sense at all.
Zaak 10y ago
Back in the 80s, instruction decode was a large part of the logic in a CPU (thus the motivation for RISC). Currently, it's a tiny fraction. It's been many years since a simpler instruction set was useful for reducing the complexity of the CPU.
- wtallis 10y ago
  But that portion of the power budget hasn't shifted at all back toward the computational units. It's been taken over by register renaming and instruction reordering and all manner of caches.
  - adrianratnapala 10y ago
    But is RISC the solution to that problem? Having lots of registers helps, I guess. But the amd64 already has quite a lot. These problems seem to be what VLIW architectures like tried to to solve. Is that sort of architecture going to make a comeback? Will even that help?
    - rbanffy 10y ago
      > But the amd64 already has quite a lot. 16 registers is not a lot when compared to other architectures. POWER, SPARC, Arm64 and MIPS have 32 (SPARC is weird, but 32 are always visible). Itanium has 128.
      - luca_ing 9y ago
        I'm far from an expert on CPU architectures, but I suppose there are diminishing returns. Most of my functions use less than 16 values, and those that do may well iterate over more than 128. Also you're probably aware that modern CPUs have many more physical registers, they just don't expose them all at the same time. E.g. AMD Zen physically has 168 integer and 160 floating-point registers. Of which you can only use 16 at a time, but to my uninformed eye that looks like a reasonable trade-off.
  - Zaak 10y ago