4 ms·

I think there are a few other legitimate problems with x86 than decode complexity: * x86_64 traditionally only has 16 registers and destructive instructions. T

I think there are a few other legitimate problems with x86 than decode complexity: * x86_64 traditionally only has 16 registers and destructive instructions. This is apparently also a problem for Intel, hence, they introduced APX which goes to 32 GPR and adds three-operand instructions. But who will use APX in the next 10 years outside specialized server software and gentoo users? Consider that most applications still target x86-64-v1, and runtime dispatch isn't really practical for this. * Piling on ever larger SIMD extensions. This is not so much a burden on the implementation, but on the software landscape. The way intel and AMD traditionally seem to implement SIMD instructions, is to have execution units that can do an operation of the largest SIMD width, and use those to also execute the smaller SIMD widths. That seems reasonable, and probably is a good tradeoff given the decode complexity, but it also means that not using the latest SIMD extension wastes a lot of compute power. If decode was easier, you could've stuck with one SIMD width, and just add more execution ports, which means that older software also gets a speedup on newer generations. This is kinda what AMD did for Zen 4, where they implemented AVX512 on top of AVX2, instead of the other way around. Or how ARM implementations that only support 128-bit wide NEON can keep up with AVX2 (256-bit) and sometimes AVX512 (512-bit). * All the legacy things may not cost much in terms of die space, because they are implemented in microcode, but I'd imagine they have significant development and verification costs. Edit: Another aspect regarding decode complexity is that the latest ARM cores started removing the uop cache, this would be pretty much impossible for a fast x86 implementation. I wonder how ARM decode width - uop cache and x86 decode width + uop cache scale for wider and wider cores.

adrian_b 3y ago
> not using the latest SIMD extension wastes a lot of compute power Not really. The unused parts of the SIMD execution units are powered down. The only problem is that Intel has not introduced instructions for switching the execution width and the attempts to detect the intentions of the executed programs can never be perfect. Therefore whenever a program starts executing wider instructions there is a large delay until the wide execution units are powered on and during that time the speed is much lower than possible. When a program stops using wider instructions, there is an even greater delay until the execution units are partially powered off and during that time there is a waste of energy. All these inefficiencies could have been trivially avoided if Intel had not tried to be so clever, but they would have just allowed the programmers to have control over the power consumption, because only they know in advance what their program will do in the future.
- camel-cdr 3y ago
  > Not really. The unused parts of the SIMD execution units are powered down True, and that helps with frequency and power, but what I meant with "wastes a lot of compute power" is that e.g. you have an avx2 capable execution unit that can do 256/32 float adds in parallel, but only a single SSE instruction can be scheduled to it, hence you can only get 128/32 float adds via SSE on that execution unit.
dan-robertson 3y ago
I read that the hardware required to decode an x86 instruction isn’t actually that bad (potentially less than certain other fixed width encodings). The problem is that it is hard to decode several instructions from the stream at once
- sweetjuly 3y ago
  This is a problem we know how to solve though. Techniques like predecoding and to a greater extent uop caches mean that you only have to do the harder parts of decode on (relatively) rare misses. On hits, you can avoid the entire problem since you already have this information stored or abstracted away.
deleted 3y ago
[deleted]
jiggawatts 3y ago
> But who will use APX in the next 10 years? There is a decent chance that the bytecode runtimes will enable this instruction set in their JIT output. This would include .NET, JVM and V8.
- pixelpoet 3y ago
  I'd like to imagine x86 OpenCL targets for this as well, unfortunately historically OpenCL codegen on AMD and Intel has been pretty weak compared to offline codegen compared to Clang, GCC and even MSVC.
zer00eyz 3y ago
>> Consider that most applications still target x86-64-v1, and runtime dispatch isn't really practical for this. https://developers.redhat.com/articles/2024/01/02/exploring-x86-64-v3-red-hat-enterprise-linux-10 https://developers.redhat.com/articles/2024/01/02/exploring-... Redhat 9 went v2 and they are pushing for v3 now... I think the drums are beating for this to change in a lot of places. Debian will end up being the hold out and (as a Debian consumer) I dont know how I feel about this...
- dralley 3y ago
  Since Red Hat has a 10 year lifecycle, it can be a little bit more aggressive than Debian, since the last version is still going to have 7+ years of support for whatever hardware is phased out in the new version. The target platforms are also a bit narrower.
  - FireBeyond 3y ago
    > Since Red Hat has a 10 year lifecycle, it can be a little bit more aggressive than Debian Huh? The longest supported Debian releases are the ELTS releases, which have 10 years too - and is not an official Debian project. Five years are the LTS release. Not sure how RHEL's 10 year life cycle is more aggressive in what it has to support.
    - dralley 3y ago
      Not an official Debian project is kind of an issue though.

adrian_b 3y ago

> not using the latest SIMD extension wastes a lot of compute power Not really. The unused parts of the SIMD execution units are powered down. The only problem is that Intel has not introduced instructions for switching the execution width and the attempts to detect the intentions of the executed programs can never be perfect. Therefore whenever a program starts executing wider instructions there is a large delay until the wide execution units are powered on and during that time the speed is much lower than possible. When a program stops using wider instructions, there is an even greater delay until the execution units are partially powered off and during that time there is a waste of energy. All these inefficiencies could have been trivially avoided if Intel had not tried to be so clever, but they would have just allowed the programmers to have control over the power consumption, because only they know in advance what their program will do in the future.

camel-cdr 3y ago
> Not really. The unused parts of the SIMD execution units are powered down True, and that helps with frequency and power, but what I meant with "wastes a lot of compute power" is that e.g. you have an avx2 capable execution unit that can do 256/32 float adds in parallel, but only a single SSE instruction can be scheduled to it, hence you can only get 128/32 float adds via SSE on that execution unit.

dan-robertson 3y ago

I read that the hardware required to decode an x86 instruction isn’t actually that bad (potentially less than certain other fixed width encodings). The problem is that it is hard to decode several instructions from the stream at once

sweetjuly 3y ago
This is a problem we know how to solve though. Techniques like predecoding and to a greater extent uop caches mean that you only have to do the harder parts of decode on (relatively) rare misses. On hits, you can avoid the entire problem since you already have this information stored or abstracted away.

deleted 3y ago

[deleted]

jiggawatts 3y ago

> But who will use APX in the next 10 years? There is a decent chance that the bytecode runtimes will enable this instruction set in their JIT output. This would include .NET, JVM and V8.

pixelpoet 3y ago
I'd like to imagine x86 OpenCL targets for this as well, unfortunately historically OpenCL codegen on AMD and Intel has been pretty weak compared to offline codegen compared to Clang, GCC and even MSVC.

zer00eyz 3y ago

>> Consider that most applications still target x86-64-v1, and runtime dispatch isn't really practical for this. https://developers.redhat.com/articles/2024/01/02/exploring-x86-64-v3-red-hat-enterprise-linux-10 https://developers.redhat.com/articles/2024/01/02/exploring-... Redhat 9 went v2 and they are pushing for v3 now... I think the drums are beating for this to change in a lot of places. Debian will end up being the hold out and (as a Debian consumer) I dont know how I feel about this...

dralley 3y ago
Since Red Hat has a 10 year lifecycle, it can be a little bit more aggressive than Debian, since the last version is still going to have 7+ years of support for whatever hardware is phased out in the new version. The target platforms are also a bit narrower.
- FireBeyond 3y ago
  > Since Red Hat has a 10 year lifecycle, it can be a little bit more aggressive than Debian Huh? The longest supported Debian releases are the ELTS releases, which have 10 years too - and is not an official Debian project. Five years are the LTS release. Not sure how RHEL's 10 year life cycle is more aggressive in what it has to support.
  - dralley 3y ago
    Not an official Debian project is kind of an issue though.