5 ms·

I think if x86 get rid of their legacy instructions, they could reduce their core size, and a few side effects will be performance per watt gains and maybe also

I think if x86 get rid of their legacy instructions, they could reduce their core size, and a few side effects will be performance per watt gains and maybe also performance (smaller cores), and if you need the legacy instructions you could just emulate, most consumer PCs don't need those. That's the biggest difference with x86 and ARM, ARM got a lot of breaking changes with their versions, while x86 don't (I'm not sure if there was any breaking change in the las 20 years at least).

chrisseaton 4y ago
> I think if x86 get rid of their legacy instructions, they could reduce their core size Aren't those legacy instructions already emulated in microcode? I don't think they take up much physical footprint.
- emidln 4y ago
  Yes. People bandying about "legacy x86" instructions miss this often. This isn't much different, conceptually, from Apple's Rosetta, except it's provided in microcode automatically rather than a discrete transform you need to run once and cache. This is very convenient for broad x86 backwards compatibility (e.g. I can run a Java 1.4 JVM and StarOffice or a libc.so.5 to play Unreal Tournament 2004 just fine on my 5900x). Can I run x86 apps, even ones from the last couple years on an M1 with no questions asked? Well, we abandoned local dockerized development at work because Docker for Mac's qemu couldn't hook into Rosetta and qemu alone couldn't handle JIT'd instructions from a jvm11[0]. Maybe that changes with the new MacOS version and the next version of Rosetta (there seems to be a Rosetta that works like qemu's binfmt_misc translators for Linux), but it's been missing for 2 years so far and caused me to do a bunch of work on remote dev capabilities in the meantime. [0] Let me stop you right there before you suggest I recompile 15 years of operating systems, third party toolchains, and internal tools for ARM and then rebuild every intermediate container just so we can work around Rosetta shipping without necessary features. I know that you can ship a whole parallel stack of containers with ARM but that's not feasible in the slightest for anything but the most trivial use cases or entirely greenfield projects.
  - UncleEntity 4y ago
    Do you really target the Java 1.4 JVM?
    - emidln 4y ago
      No, but I used the Java 1.4 JVM to run StarOffice for compatibility with an old document that had no other reader within the last three months. I did this from my AMD Ryzen 9 5900x running Linux. For work, I still have some third-party toolchains that were originally compiled on x86_64 linux in 2012. They are dockerized these days to make running these legacy toolchains easy. There is no possibility to recompile these on ARM to provide parallel containers that are compatible with Docker for Mac.
- kersplody 4y ago
  Modern x86 processors use about 10% of their power budget for instruction decode (translate variable-length x86 machine code into one or more fixed-length microcode instructions and remap registers). The primary modern benefit of this setup is that the decode logic can optimize code at the cost of power. If x86 could get rid of the x86 instruction set and compile directly to something similar to uOPs, then some power reduction use and core area reduction could be achieved, but tooling cost would be immense.
layer8 4y ago
X86 will always be slower because it has stricter memory ordering semantics.
- kersplody 4y ago
  Not really an issue under most usage scenarios. x86 suffers mostly from the cost and complexity of the decode unit. Once decoded instructions are cached, the performance penalty mostly disappears.
- erichocean 4y ago
  Ordering semantics (TSO) that Apple's M1 implements. I guess it should be slower too?
  - layer8 4y ago
    M1 implements TSO as a special mode specifically for x86 compatibility: https://github.com/saagarjha/TSOEnabler https://github.com/saagarjha/TSOEnabler If TSO didn’t have a performance penalty, it wouldn’t need to be a separate mode. Also, it should be obvious that stricter ordering constraints inherently allow less parallelism, so lower performance.
  - hajile 4y ago
    And it is a LOT slower to run rosetta apps instead of native ones despite all the silicon thrown into emulation. If it were as simple as "they are the same once everything is decoded", then you'd expect a pre-decoded and pre-optimized program to be at least as fast, but it's not.

chrisseaton 4y ago

> I think if x86 get rid of their legacy instructions, they could reduce their core size Aren't those legacy instructions already emulated in microcode? I don't think they take up much physical footprint.

emidln 4y ago
Yes. People bandying about "legacy x86" instructions miss this often. This isn't much different, conceptually, from Apple's Rosetta, except it's provided in microcode automatically rather than a discrete transform you need to run once and cache. This is very convenient for broad x86 backwards compatibility (e.g. I can run a Java 1.4 JVM and StarOffice or a libc.so.5 to play Unreal Tournament 2004 just fine on my 5900x). Can I run x86 apps, even ones from the last couple years on an M1 with no questions asked? Well, we abandoned local dockerized development at work because Docker for Mac's qemu couldn't hook into Rosetta and qemu alone couldn't handle JIT'd instructions from a jvm11[0]. Maybe that changes with the new MacOS version and the next version of Rosetta (there seems to be a Rosetta that works like qemu's binfmt_misc translators for Linux), but it's been missing for 2 years so far and caused me to do a bunch of work on remote dev capabilities in the meantime. [0] Let me stop you right there before you suggest I recompile 15 years of operating systems, third party toolchains, and internal tools for ARM and then rebuild every intermediate container just so we can work around Rosetta shipping without necessary features. I know that you can ship a whole parallel stack of containers with ARM but that's not feasible in the slightest for anything but the most trivial use cases or entirely greenfield projects.
- UncleEntity 4y ago
  Do you really target the Java 1.4 JVM?
  - emidln 4y ago
    No, but I used the Java 1.4 JVM to run StarOffice for compatibility with an old document that had no other reader within the last three months. I did this from my AMD Ryzen 9 5900x running Linux. For work, I still have some third-party toolchains that were originally compiled on x86_64 linux in 2012. They are dockerized these days to make running these legacy toolchains easy. There is no possibility to recompile these on ARM to provide parallel containers that are compatible with Docker for Mac.
kersplody 4y ago
Modern x86 processors use about 10% of their power budget for instruction decode (translate variable-length x86 machine code into one or more fixed-length microcode instructions and remap registers). The primary modern benefit of this setup is that the decode logic can optimize code at the cost of power. If x86 could get rid of the x86 instruction set and compile directly to something similar to uOPs, then some power reduction use and core area reduction could be achieved, but tooling cost would be immense.

layer8 4y ago

X86 will always be slower because it has stricter memory ordering semantics.

kersplody 4y ago
Not really an issue under most usage scenarios. x86 suffers mostly from the cost and complexity of the decode unit. Once decoded instructions are cached, the performance penalty mostly disappears.
erichocean 4y ago
Ordering semantics (TSO) that Apple's M1 implements. I guess it should be slower too?
- layer8 4y ago
  M1 implements TSO as a special mode specifically for x86 compatibility: https://github.com/saagarjha/TSOEnabler https://github.com/saagarjha/TSOEnabler If TSO didn’t have a performance penalty, it wouldn’t need to be a separate mode. Also, it should be obvious that stricter ordering constraints inherently allow less parallelism, so lower performance.
- hajile 4y ago
  And it is a LOT slower to run rosetta apps instead of native ones despite all the silicon thrown into emulation. If it were as simple as "they are the same once everything is decoded", then you'd expect a pre-decoded and pre-optimized program to be at least as fast, but it's not.