6 ms·

Why is this interesting? Rosetta 2 is documented to not support AVX: https://developer.apple.com/documentation/apple_silicon/about_the_rosetta_translation_envi

Why is this interesting? Rosetta 2 is documented to not support AVX: https://developer.apple.com/documentation/apple_silicon/about_the_rosetta_translation_environment https://developer.apple.com/documentation/apple_silicon/abou...

thibautg 6y ago
I own a MacBook Air M1. Today, I noticed that my Homebrew Python (3.9.1 on Intel) installation had reverted to the default one (3.8 on ARM). I forced a reinstall with homebrew and I got an ‘illegal hardware instruction’ error when running python3. It was corrected by building from source (with the -s switch: brew reinstall -s python3). I found out about this issue on Github and I learned that the M1 chip does not support AVX (which is indeed documented) and that Homebrew developers assumed that all CPUs supported by Big Sur were compatible with AVX instruction set (which is true except for the M1 under Rosetta 2). I found it interesting to see how they rapidly corrected the situation by merging a partial revert. I also found their CI infrastructure interesting to watch while it was live-testing the commit.
- klodolph 6y ago
  This is fascinating. I can understand why the Homebrew devs might make the decision, but it seems the right way to do this is just to, e.g., cc -dM -E -xc /dev/null | less Anything with a preprocessor macro is supported on all OS configurations that you are targeting. You can see, for example, that __SSE4_1__ is defined, so SSE 4.1 is ok to use without checking it at runtime with e.g. sysctlbyname("hw.optional.sse4_1", &enabled, ...) I have always thought that it is worth a bit of paranoia to try and do the check for optional features the “correct” way, whatever method the OS advertises (like sysctl for macOS) rather than doing something like cpuid. After all, every once in a while it’s possible to run into a configuration where the CPU does support some particular feature but the OS does not, and if you rely on cpuid you could be up shit creek without a paddle.
  - bodyfour 6y ago
    It was a mistaken assumption from the Homebrew developers who didn't realize AVX would cause problems with Rosetta2. Within a few days problems became evident and Homebrew turned the compiler flag back off. Now it's just a question of the best way of remediating the already-compiled packages in the simplest way possible. Really the fact that this is now a front-page-of-HN story is going to cause more confusion to people. It was just a short-lived bug.
rincebrain 6y ago
It appears the decision was made to hardwire AVX support to "on" recently as all the hardware for Big Sur supposedly supported AVX, not noticing that Rosetta 2 violated this, and then the bug report(s) started coming in about precompiled binaries being broken under Rosetta 2 since that change. So I personally find it interesting because I would not have expected Rosetta 2 to be missing AVX instructions if all the supported Big Sur hardware possessed them, and this is an interesting failure mode to watch and see how the Brew developers handle.
- als0 6y ago
  > I would not have expected Rosetta 2 to be missing AVX instructions AVX can’t be emulated by Rosetta due to Intel patents.
  - trollian 6y ago
    They're implemented by other emulation systems like bochs: https://sourceforge.net/p/bochs/news/ https://sourceforge.net/p/bochs/news/
    - colejohnson66 6y ago
      bochs is probably just too small a fish for Intel to care. But Apple is a big money maker for Intel, so they’d have an incentive to push back legally. The patents aren’t on the implementation, but the function, so I’d wager that bochs is actually infringing. But IANAL, so take it with a grain of salt.
  - phire 6y ago
    Regardless of the patent issue, emulating AVX on the M1 (which only has 4-wide SIMD) would actually be significantly slower than forcing the x86 application to use it's SSE fallback path and emulating that.
    - Diggsey 6y ago
      Emulating AVX via Rosetta should be just as fast as re-compiling the original without AVX support and then emulating it. Emulating larger SIMD instructions is very easy, you just use multiple smaller SIMD instructions. On the other hand, disabling AVX for all Intel machines would make those programs significantly slower, so it's clear why there is reluctance to do that...
jabberwcky 6y ago
After what feels like a solid month of front pages cooing over the new hardware, a little counterbalance really could not hurt. I'm no longer an Apple hardware user, so this post (along with your comment) was the first time I'd heard AVX was unsupported. Pretty sure I'm not alone. [edit: this seemed like quite an uncontroversial thing to say, please understand it was not intended to hurt anyone's feelings. I was a mac user for 12 years and simply don't click those links any more. Please don't downvote comments just because you're a Mac user]
- gumby 6y ago
  They did mention it a lot (though they said a lot of things, so easy to overlook). The actual issue is that Rosetta identifies itself as a CPU without AVX so it’s clearly a homebrew bug. And in fact if you tell homebrew not to download a prebuilt binary it works fine.
- EricE 6y ago
  Counterbalance? The Homebrew team made a lazy assumption and it bit them. That's hardly Apple's fault.

thibautg 6y ago

I own a MacBook Air M1. Today, I noticed that my Homebrew Python (3.9.1 on Intel) installation had reverted to the default one (3.8 on ARM). I forced a reinstall with homebrew and I got an ‘illegal hardware instruction’ error when running python3. It was corrected by building from source (with the -s switch: brew reinstall -s python3). I found out about this issue on Github and I learned that the M1 chip does not support AVX (which is indeed documented) and that Homebrew developers assumed that all CPUs supported by Big Sur were compatible with AVX instruction set (which is true except for the M1 under Rosetta 2). I found it interesting to see how they rapidly corrected the situation by merging a partial revert. I also found their CI infrastructure interesting to watch while it was live-testing the commit.

klodolph 6y ago
This is fascinating. I can understand why the Homebrew devs might make the decision, but it seems the right way to do this is just to, e.g., cc -dM -E -xc /dev/null | less Anything with a preprocessor macro is supported on all OS configurations that you are targeting. You can see, for example, that __SSE4_1__ is defined, so SSE 4.1 is ok to use without checking it at runtime with e.g. sysctlbyname("hw.optional.sse4_1", &enabled, ...) I have always thought that it is worth a bit of paranoia to try and do the check for optional features the “correct” way, whatever method the OS advertises (like sysctl for macOS) rather than doing something like cpuid. After all, every once in a while it’s possible to run into a configuration where the CPU does support some particular feature but the OS does not, and if you rely on cpuid you could be up shit creek without a paddle.
- bodyfour 6y ago
  It was a mistaken assumption from the Homebrew developers who didn't realize AVX would cause problems with Rosetta2. Within a few days problems became evident and Homebrew turned the compiler flag back off. Now it's just a question of the best way of remediating the already-compiled packages in the simplest way possible. Really the fact that this is now a front-page-of-HN story is going to cause more confusion to people. It was just a short-lived bug.

rincebrain 6y ago

It appears the decision was made to hardwire AVX support to "on" recently as all the hardware for Big Sur supposedly supported AVX, not noticing that Rosetta 2 violated this, and then the bug report(s) started coming in about precompiled binaries being broken under Rosetta 2 since that change. So I personally find it interesting because I would not have expected Rosetta 2 to be missing AVX instructions if all the supported Big Sur hardware possessed them, and this is an interesting failure mode to watch and see how the Brew developers handle.

als0 6y ago
> I would not have expected Rosetta 2 to be missing AVX instructions AVX can’t be emulated by Rosetta due to Intel patents.
- trollian 6y ago
  They're implemented by other emulation systems like bochs: https://sourceforge.net/p/bochs/news/ https://sourceforge.net/p/bochs/news/
  - colejohnson66 6y ago
    bochs is probably just too small a fish for Intel to care. But Apple is a big money maker for Intel, so they’d have an incentive to push back legally. The patents aren’t on the implementation, but the function, so I’d wager that bochs is actually infringing. But IANAL, so take it with a grain of salt.
- phire 6y ago
  Regardless of the patent issue, emulating AVX on the M1 (which only has 4-wide SIMD) would actually be significantly slower than forcing the x86 application to use it's SSE fallback path and emulating that.
  - Diggsey 6y ago
    Emulating AVX via Rosetta should be just as fast as re-compiling the original without AVX support and then emulating it. Emulating larger SIMD instructions is very easy, you just use multiple smaller SIMD instructions. On the other hand, disabling AVX for all Intel machines would make those programs significantly slower, so it's clear why there is reluctance to do that...

jabberwcky 6y ago

After what feels like a solid month of front pages cooing over the new hardware, a little counterbalance really could not hurt. I'm no longer an Apple hardware user, so this post (along with your comment) was the first time I'd heard AVX was unsupported. Pretty sure I'm not alone. [edit: this seemed like quite an uncontroversial thing to say, please understand it was not intended to hurt anyone's feelings. I was a mac user for 12 years and simply don't click those links any more. Please don't downvote comments just because you're a Mac user]

gumby 6y ago
They did mention it a lot (though they said a lot of things, so easy to overlook). The actual issue is that Rosetta identifies itself as a CPU without AVX so it’s clearly a homebrew bug. And in fact if you tell homebrew not to download a prebuilt binary it works fine.
EricE 6y ago
Counterbalance? The Homebrew team made a lazy assumption and it bit them. That's hardly Apple's fault.