5 ms·

Apple has already done this to an extent. M1 has undocumented instructions and a semi-closed toolchain (Assuming they have some, M1 tuning models for LLVM and G

by mhh__ 5y ago

Apple has already done this to an extent. M1 has undocumented instructions and a semi-closed toolchain (Assuming they have some, M1 tuning models for LLVM and GCC are nowhere to be seen afaik)

ithkuil 5y ago
Are the tuning models in opensource toolchains for Intel CPUs been released by Intel or figured out over time by opensource developers?
- kolbusa 5y ago
  Intel contributes optimizations to gcc and llvm.
  - ithkuil 5y ago
    They do now; I think I remember the time when they didn't.
  - jagger27 5y ago
    Apple also contributes plenty to LLVM, more than Intel actually, naively based on commit counts of @apple.com and @intel.com git committer email addresses. This isn't very surprising given that Chris Lattner worked at Apple for over a decade.
    - mhh__ 5y ago
      LLVM is Apple's baby, beyond its genesis under Lattner. They hate the GPL, that's it. The thing about their contributions is that they upstream stuff they want other people to standardize on but aren't doing it out of love, as far as I can tell e.g. Valve have a direct business interest in having Linux kicking ass, Apple actively loses out (psychologically at least) if a non-apple toolchain is as good as theirs.
    - pjmlp 5y ago
      Apple used to contribute plenty to LLVM. Nowadays less so, for them C++ support is good enough for what they make out of it (MSL is based on C++14 and IO/Driver Kit use an embedded subset). The main focus is how well it is churning Objective-C, Swift and their own special flavour of bitcode. None of them end up upstream as one might wish for.
- mhh__ 5y ago
  Intel publish a very thick optimization manual, which is a good help. Compilers aren't great at using the real parameters of the chip (i.e. LLVM knows how wide the reader buffer is but I'm not sure if it actually can use the information), but knowing latencies for ISel and things like that is very helpful. To get those details you do need to rely on people like (the god amongst men) agner fog.
  - mhh__ 5y ago
    That should say reorder buffer above.
mancerayder 5y ago
I'm asking out of naiveté here -- how were they (kernel maintainers) able to get the Linux kernel to support M1 with undocumented instructions?
- frabert 5y ago
  A kernel doesn't need to use all the instructions a CPU offers -- only the ones it needs.
  - ithkuil 5y ago
    If the extra instructions also operate in extra state (e.g. extra registers) a kernel needs to know about their existence so it can correctly save and restore state on context switches
    - my123 5y ago
      Not necessarily/really, the custom extensions still need to be enabled by the kernel before they can be used. As such, it isn’t actually an issue.
    - ndesaulniers 5y ago
      You're confusing MSRs (which don't have to be saved/restored on context switch) with GPRs (which do).
      - saagarjha 5y ago
        Apple reserves certain MSRs that apply on a per-process basis, and thus must be applied on context switch.
      - ithkuil 5y ago
        Well if there is a truly undocumented extension, how do I know it doesn't come with it's own registers (e.g. like a floating point unit does)
  - Someone 5y ago
ant6n 5y ago
Apple M1 also has that x86 emulation mode where memory accesses have the same ordering semantics as on x86. It's probably one of the main things giving Rosetta almost 1:1 performance with x86. https://mobile.twitter.com/ErrataRob/status/1331735383193903104 https://mobile.twitter.com/ErrataRob/status/1331735383193903...
- my123 5y ago
  That’s a single ACTLR bit present in the publicly released XNU kernel source code.
- zamadatix 5y ago
  TSO support at the hardware level is a cool feature but it's a bit oversold here. Most emulated x86 code doesn't require it and usually not at every memory instruction when it does. For instance the default settings in Window's translation implementation do not do anything to guarantee TSO. Rosetta is also a long way from 1:1 performance, even you're own link says ~70% the speed. That's closer to half speed than it is to full speed. The M1's main trick to being so good at running x86 code is it's just so god damn fast for the power budget it doesn't matter if there is overhead for emulated code it's still going to be fast. This is why running Windows for ARM in parallels is fast too, it knows basically none of the "tricks" available but the emulation speed isn't much slower than the Rosetta 2 emulation ratio even though it's all happening in a VM. In a fun twist of fate 32 bit x86 apps also work under Windows on the M1 even though the M1 doesn't support 32 bit code.
  - ant6n 5y ago
    Breaking memory ordering will breaks software - if a program requires it (which is already hard to know), how would you know which memory is accessed by multiple threads?
    - my123 5y ago
      Heuristics are used. For example, memory accesses relative to the stack pointer will be assumed to be thread-local, as the stack isn’t shared between threads. And that’s just one of the tricks in the toolbox. :-) The result of those is that the expensive atomics aren’t applied to all accesses at all on hardware that doesn’t expose a TSO memory model.
szundi 5y ago
And I would like to emphasize that when Apple used Intel, even then it was not commercially viable to use their platform. Bringing in ARM did change less than one would think at first.
saagarjha 5y ago
A14 is described in LLVM: https://github.com/llvm/llvm-project/blob/9e4d72675f476386cf6555cd5a1014cdd8d9facb/llvm/lib/Target/AArch64/AArch64.td#L891 https://github.com/llvm/llvm-project/blob/9e4d72675f476386cf...
- mhh__ 5y ago
  That's for the instruction selection patterns, no? I couldn't see a pipeline model in there last time I checked. P.S. GCC descs are a goldmine for old arch's.
  - saagarjha 5y ago
    That is true, but I think this is the case for all the ARM cores. I didn't spot a scheduler for Cortex-A73, for example.

by mhh__ 5y ago

Apple has already done this to an extent. M1 has undocumented instructions and a semi-closed toolchain (Assuming they have some, M1 tuning models for LLVM and GCC are nowhere to be seen afaik)

ithkuil 5y ago

Are the tuning models in opensource toolchains for Intel CPUs been released by Intel or figured out over time by opensource developers?

kolbusa 5y ago
Intel contributes optimizations to gcc and llvm.
- ithkuil 5y ago
  They do now; I think I remember the time when they didn't.
- jagger27 5y ago
  Apple also contributes plenty to LLVM, more than Intel actually, naively based on commit counts of @apple.com and @intel.com git committer email addresses. This isn't very surprising given that Chris Lattner worked at Apple for over a decade.
  - mhh__ 5y ago
    LLVM is Apple's baby, beyond its genesis under Lattner. They hate the GPL, that's it. The thing about their contributions is that they upstream stuff they want other people to standardize on but aren't doing it out of love, as far as I can tell e.g. Valve have a direct business interest in having Linux kicking ass, Apple actively loses out (psychologically at least) if a non-apple toolchain is as good as theirs.
  - pjmlp 5y ago
    Apple used to contribute plenty to LLVM. Nowadays less so, for them C++ support is good enough for what they make out of it (MSL is based on C++14 and IO/Driver Kit use an embedded subset). The main focus is how well it is churning Objective-C, Swift and their own special flavour of bitcode. None of them end up upstream as one might wish for.
mhh__ 5y ago
Intel publish a very thick optimization manual, which is a good help. Compilers aren't great at using the real parameters of the chip (i.e. LLVM knows how wide the reader buffer is but I'm not sure if it actually can use the information), but knowing latencies for ISel and things like that is very helpful. To get those details you do need to rely on people like (the god amongst men) agner fog.
- mhh__ 5y ago
  That should say reorder buffer above.

mancerayder 5y ago

I'm asking out of naiveté here -- how were they (kernel maintainers) able to get the Linux kernel to support M1 with undocumented instructions?

frabert 5y ago
A kernel doesn't need to use all the instructions a CPU offers -- only the ones it needs.
- ithkuil 5y ago
  If the extra instructions also operate in extra state (e.g. extra registers) a kernel needs to know about their existence so it can correctly save and restore state on context switches
  - my123 5y ago
    Not necessarily/really, the custom extensions still need to be enabled by the kernel before they can be used. As such, it isn’t actually an issue.
  - ndesaulniers 5y ago
    You're confusing MSRs (which don't have to be saved/restored on context switch) with GPRs (which do).
    - saagarjha 5y ago
      Apple reserves certain MSRs that apply on a per-process basis, and thus must be applied on context switch.
    - ithkuil 5y ago
      Well if there is a truly undocumented extension, how do I know it doesn't come with it's own registers (e.g. like a floating point unit does)
- Someone 5y ago

ant6n 5y ago

Apple M1 also has that x86 emulation mode where memory accesses have the same ordering semantics as on x86. It's probably one of the main things giving Rosetta almost 1:1 performance with x86. https://mobile.twitter.com/ErrataRob/status/1331735383193903104 https://mobile.twitter.com/ErrataRob/status/1331735383193903...

my123 5y ago
That’s a single ACTLR bit present in the publicly released XNU kernel source code.
zamadatix 5y ago
TSO support at the hardware level is a cool feature but it's a bit oversold here. Most emulated x86 code doesn't require it and usually not at every memory instruction when it does. For instance the default settings in Window's translation implementation do not do anything to guarantee TSO. Rosetta is also a long way from 1:1 performance, even you're own link says ~70% the speed. That's closer to half speed than it is to full speed. The M1's main trick to being so good at running x86 code is it's just so god damn fast for the power budget it doesn't matter if there is overhead for emulated code it's still going to be fast. This is why running Windows for ARM in parallels is fast too, it knows basically none of the "tricks" available but the emulation speed isn't much slower than the Rosetta 2 emulation ratio even though it's all happening in a VM. In a fun twist of fate 32 bit x86 apps also work under Windows on the M1 even though the M1 doesn't support 32 bit code.
- ant6n 5y ago
  Breaking memory ordering will breaks software - if a program requires it (which is already hard to know), how would you know which memory is accessed by multiple threads?
  - my123 5y ago
    Heuristics are used. For example, memory accesses relative to the stack pointer will be assumed to be thread-local, as the stack isn’t shared between threads. And that’s just one of the tricks in the toolbox. :-) The result of those is that the expensive atomics aren’t applied to all accesses at all on hardware that doesn’t expose a TSO memory model.

szundi 5y ago

And I would like to emphasize that when Apple used Intel, even then it was not commercially viable to use their platform. Bringing in ARM did change less than one would think at first.

saagarjha 5y ago

A14 is described in LLVM: https://github.com/llvm/llvm-project/blob/9e4d72675f476386cf6555cd5a1014cdd8d9facb/llvm/lib/Target/AArch64/AArch64.td#L891 https://github.com/llvm/llvm-project/blob/9e4d72675f476386cf...

mhh__ 5y ago
That's for the instruction selection patterns, no? I couldn't see a pipeline model in there last time I checked. P.S. GCC descs are a goldmine for old arch's.
- saagarjha 5y ago
  That is true, but I think this is the case for all the ARM cores. I didn't spot a scheduler for Cortex-A73, for example.