[tester756]

https://chipsandcheese.com/2021/07/13/arm-or-x86-isa-doesnt-...

>Another oft-repeated truism is that x86 has a significant ‘decode tax’ handicap. ARM uses fixed length instructions, while x86’s instructions vary in length. Because you have to determine the length of one instruction before knowing where the next begins, decoding x86 instructions in parallel is more difficult. This is a disadvantage for x86, yet it doesn’t really matter for high performance CPUs because in Jim Keller’s words:

>For a while we thought variable-length instructions were really hard to decode. But we keep figuring out how to do that. … So fixed-length instructions seem really nice when you’re building little baby computers, but if you’re building a really big computer, to predict or to figure out where all the instructions are, it isn’t dominating the die. So it doesn’t matter that much.

>...

>Researchers agree too. In 2016, a study supported by the Helsinki Institute of Physics[2] looked at Intel’s Haswell microarchitecture. There, Hiriki et al. estimated that Haswell’s decoder consumed 3-10% of package power. The study concluded that “the x86-64 instruction set is not a major hindrance in producing an energy-efficient processor architecture.”

[dmitrygr]

I did not talk about power - i talked about perf. No modern x86 chip can decode 6 or 7 of these long instrs per cycle. there are aarch64 chips that can

[TazeTSchnitzel]

Perhaps it's compensated by the fact a single x86 instruction does more? If a bunch of those aarch64 instructions would be loads and stores, but for x86 they're part of the arithmetic instructions, then it maybe doesn't matter?

[The_Colonel]

What impact does it have on the overall performance though? Keller's argument is that the effect is small/negligible.

[AnimalMuppet]

Keller's argument (as stated) is that it doesn't take up much die space. Hiriki's argument is that it doesn't consume much power. Neither addresses dmitrygr's argument, which is about performance and bottlenecks. (It could use very little power and very little space and still be a very big bottleneck.)

That doesn't mean that dmitrygr is correct. It means that everyone trying to answer him is arguing about the wrong thing.

[LegionMammal978]

The main issue with that argument is that the L1i cache can never realistically be exhausted fast enough to form a bottleneck, as long as the decoder is working ahead of the start of the execution pipeline.

The hard limit on instruction size is 15 bytes, so a 64-byte cache line will always be able to store at least 4 of them. (Or 3 plus the tail of an instruction from a previous line.) Meanwhile, on the other end, Intel cores can only retire up to 4 μops per cycle. Since each instruction takes at least 1 μop (except for macro-fusion, which only works on short instructions), retirement will always form a bottleneck before decoding can.

And in realistic code where you'd actually see these long instructions, i.e., hot SIMD loops, all the decoded instructions would stay warm and toasty in the μop cache (allegedly holding 6 fixed-size μops per cache line) after the first iteration.

[The_Colonel]

> It could use very little power and very little space and still be a very big bottleneck.

I believe in chip design, this doesn't really happen (often). You can optimize the bottlenecks by allocating it more space and power.

I interpret Keller's statement indirectly - given that modern x86 CPUs dedicate only a small part of its circuitry to decoding logic means that it's not a bottleneck (otherwise there would be more circuitry for it).

[IshKebab]

The total architectural difference is pretty small in general. Like, say switching a chip from Intel to ARM lets you make it 30% faster. For the last several decades that was insignificant. Not so much these days though.

The decode difficulty may make a 5% difference, but add in the other things people have mentioned and maybe it adds up to 30%. (numbers pulled out of my arse)

[StressedDev]

Do you have benchmarks showing this? People would switch to ARM if this is true. Note Linux and Windows runs just fine ARM.

[IshKebab]

Difficult to benchmark, but ... people are switching to ARM. You've heard of the M1 right?

[tester756]

Or maybe x86 CPUs were until recently designed with performance in mind instead of energy/eff and Intel+AMD were slower at going into that direction?

Just wait until Lunar Lake is released in this year. It should be x86 energy eff CPU

[watersb]

I believe that modern x86 processors store decoded micro-ops in the I$ instruction cache.

I always understood micro-ops to be fixed length.

Sure, you have to decode the variable length instructions at some point. But that extra work, relative to aarch64, is in practice amortized over the lifetime of that cache line.

[mmaniac]

That's not how it works for either Intel or AMD's current designs. Both use an L1 I$ which consists of encoded instructions, while adding a small uop cache (sometimes called L0) for recently decoded instructions.[1][2]

Intel's Netburst architecture stored decoded instruction sequences in its L1 cache, which Intel called a trace cache.[3] This didn't work out too well, so Intel reverted to a conventional L1 cache with the successor Merom[4] and introduced the uop cache shortly after with Sandy Bridge[5].

[1]https://chipsandcheese.com/2021/12/02/popping-the-hood-on-go...

[2]https://chipsandcheese.com/2022/11/05/amds-zen-4-part-1-fron...

[3]https://chipsandcheese.com/2022/06/17/intels-netburst-failur...

[4]https://chipsandcheese.com/2023/02/05/intels-dunnington-core...

[5]https://chipsandcheese.com/2023/08/04/sandy-bridge-setting-i...