5 ms·

Memory model, execution units, simd instructions...

oblio 6y ago
The real question is, can you compile for ARM and move the binary around as easily as you can for x86? I'm reasonably sure that you can take a binary compiled with GCC on a P4 back in the day and run it on the latest Zen 3 CPU.
- easton 6y ago
  As far as I can tell, yes. Docker images compiled for arm64 work fine on the Macs with M1 chips without rebuilding. And as another commenter said, you can compile a binary on a Raspberry Pi 4 and move it to a EC2 graviton instance and it just works.
- cozzyd 6y ago
  it will probably be a similar situation to x86, with various vendors implementing various instructions in some processors that won't be supported by all. I guess the difference is that there may be many more variants than in x86, but performance-critical code can always use runtime dispatch mechanisms to adapt.
  - oblio 6y ago
    It's true that there are extensions to x86, but 99,99% of software out there (the one you'd commonly install on Windows or find in Linux distribution repos) doesn't use those instructions or maybe just detects the features and then uses it. I don't recall encountering a "Intel-locked" or "AMD-locked" application in more than 20 years of using x86. Ok, maybe ICC, but that one kind of makes sense :-)
    - cozzyd 6y ago
      Encountering SIGILLs is not super uncommon on heterogeneous academic computer clusters (since -march=native). But yeah, typically binaries built for redistribution use a reasonably crusty minimum architecture. Reminds me of this discussion for Fedora: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/MPFXH4Y5LDC5L2VXWKUHAX3WAKBQXR4U/ https://lists.fedoraproject.org/archives/list/devel@lists.fe...
    - mitjam 6y ago
      Audio software usually runs better on Imtel than on AMD.
  - ndesaulniers 6y ago
    That doesn't mean compilers will emit such instructions; maybe hand written assembler will become less portable if such code is making use of extensions...but that should be obvious to the authors...and probably they should have a fallback path.
- volta87 6y ago
  > can you compile for ARM and move the binary around as easily as you can for x86? Yes.
rapsey 6y ago
The vast majority of code running is in python, js, jvm, php, ruby, etc. Far removed these concerns.
- jlawer 6y ago
  Some of those languages (especially python & php) utilise C based modules or packaged external binaries. Both of which have to be available / compatible with ARM. When you run pip or composer on Amd64 they often pull these down and you don't notice, but if you try on arm you discover quickly that some packages don't support ARM. Sometimes there is a slower fallback option, but often there is none.
  - rapsey 6y ago
    Those are pretty minor issues that will be fixed as arm servers get more popular

The real question is, can you compile for ARM and move the binary around as easily as you can for x86? I'm reasonably sure that you can take a binary compiled with GCC on a P4 back in the day and run it on the latest Zen 3 CPU.

easton 6y ago
As far as I can tell, yes. Docker images compiled for arm64 work fine on the Macs with M1 chips without rebuilding. And as another commenter said, you can compile a binary on a Raspberry Pi 4 and move it to a EC2 graviton instance and it just works.
cozzyd 6y ago
it will probably be a similar situation to x86, with various vendors implementing various instructions in some processors that won't be supported by all. I guess the difference is that there may be many more variants than in x86, but performance-critical code can always use runtime dispatch mechanisms to adapt.
- oblio 6y ago
  It's true that there are extensions to x86, but 99,99% of software out there (the one you'd commonly install on Windows or find in Linux distribution repos) doesn't use those instructions or maybe just detects the features and then uses it. I don't recall encountering a "Intel-locked" or "AMD-locked" application in more than 20 years of using x86. Ok, maybe ICC, but that one kind of makes sense :-)
  - cozzyd 6y ago
    Encountering SIGILLs is not super uncommon on heterogeneous academic computer clusters (since -march=native). But yeah, typically binaries built for redistribution use a reasonably crusty minimum architecture. Reminds me of this discussion for Fedora: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/MPFXH4Y5LDC5L2VXWKUHAX3WAKBQXR4U/ https://lists.fedoraproject.org/archives/list/devel@lists.fe...
  - mitjam 6y ago
    Audio software usually runs better on Imtel than on AMD.
- ndesaulniers 6y ago
  That doesn't mean compilers will emit such instructions; maybe hand written assembler will become less portable if such code is making use of extensions...but that should be obvious to the authors...and probably they should have a fallback path.
volta87 6y ago
> can you compile for ARM and move the binary around as easily as you can for x86? Yes.

rapsey 6y ago

The vast majority of code running is in python, js, jvm, php, ruby, etc. Far removed these concerns.

jlawer 6y ago
Some of those languages (especially python & php) utilise C based modules or packaged external binaries. Both of which have to be available / compatible with ARM. When you run pip or composer on Amd64 they often pull these down and you don't notice, but if you try on arm you discover quickly that some packages don't support ARM. Sometimes there is a slower fallback option, but often there is none.
- rapsey 6y ago
  Those are pretty minor issues that will be fixed as arm servers get more popular