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.

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.

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?

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

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.

If you had a "sufficiently smart compiler" you wouldn't need register renaming and instruction reordering, but such a compiler has consistently failed to appear. That's a big part of the whole Itanium fiasco.

If you want your CPU to run fast, you have to pipeline instructions and you need caches that can run at full CPU speed. It's easy to design a CPU without all the complexity, but it will be slow. No one knows how to do both simple and fast. It's probably impossible.

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?

> Does the brain even have instruction decoders?

I can't even begin to understand this question. It makes no sense at all.

Yes, I implied this.

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

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.

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.

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.

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?

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.

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.

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.

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

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.