Will MacOS 15 drop support for Intel?

[Icelus]

Back-port Rosetta 2 Runtime with AVX2 support from macOS Sequoia Beta to Sonoma

From the macgaming community on Reddit: Tutorial: Back-port Rosetta 2 Runtime with AVX2 support from macOS Sequoia Beta to Sonoma

Explore this post and more from the macgaming community

redd.it

CPU	Kind	Performance
Apple M1 Pro 10-Core	AVX2 FMA FP32	34.96 GFLOPS
Apple M1 Pro 10-Core	AVX2 FMA FP64	17.37 GFLOPS
AMD Ryzen 7 7840HS	AVX2 FMA FP32	152.92 GFLOPS
AMD Ryzen 7 7840HS	AVX2 FMA FP64	76.52 GFLOPS

 

[bzgnyc2]

As there has also been talk about axing Rosetta and its connection to the decline of Intel support; Rosetta 2 actually got a major upgrade with Sequoia - It now supports AVX(2)

Wow this is great news. There are several software I use that still don't support ARM/Apple Silicon. In the case of SQL Edge, they actually dropped ARM support. Given predictions that Apple would treat Rosetta2 as a transition tool (as it did with PPC->Intel Rosetta) rather than a long-term option, I've been hesitant to commit to Apple Silicon. However between making it available not just for macOS but Docker and emulators and now this, it feels like longer-term commitment.

For people who build their own software, it's also good because if Mac/Intel-users optimize for any Haswell or later processor (and Skylake has been a minimum officially supported processor since Ventura), the resulting binary wouldn't work under Apple Silicon/Rosetta2. Now it sounds like it will which will help people migrate in the future without having to worry about whether every program they have is a fat binary.

The just posted AMD w/AVX2 versus Apple Silicon/Rosetta2 w/AVX benchmarks are interesting. I would be curious to see benchmarks comparing AVX[1] versus AVX2 on Intel or AMD versus AVX[1] on Apple Silicon/Rosetta2 versus AVX2 on Apple Silicon/Rosetta2. Enabling AVX2 instructions in LLVM for use on my Intel 8th and 10th generation processors hasn't made as big a difference over AVX as I expected and so wasn't sure it was worth creating potential incompatabilities with non-Intel processors and/or Rosetta2. Either way the compatability is good for applications/binaries that are using AVX2 for whatever reason.

 

[casperes1996]

Wow this is great news. There are several software I use that still don't support ARM/Apple Silicon. In the case of SQL Edge, they actually dropped ARM support. Given predictions that Apple would treat Rosetta2 as a transition tool (as it did with PPC->Intel Rosetta) rather than a long-term option, I've been hesitant to commit to Apple Silicon. However between making it available not just for macOS but Docker and emulators and now this, it feels like longer-term commitment.

For people who build their own software, it's also good because if Mac/Intel-users optimize for any Haswell or later processor (and Skylake has been a minimum officially supported processor since Ventura), the resulting binary wouldn't work under Apple Silicon/Rosetta2. Now it sounds like it will which will help people migrate in the future without having to worry about whether every program they have is a fat binary.

The just posted AMD w/AVX2 versus Apple Silicon/Rosetta2 w/AVX benchmarks are interesting. I would be curious to see benchmarks comparing AVX[1] versus AVX2 on Intel or AMD versus AVX[1] on Apple Silicon/Rosetta2 versus AVX2 on Apple Silicon/Rosetta2. Enabling AVX2 instructions in LLVM for use on my Intel 8th and 10th generation processors hasn't made as big a difference over AVX as I expected and so wasn't sure it was worth creating potential incompatabilities with non-Intel processors and/or Rosetta2. Either way the compatability is good for applications/binaries that are using AVX2 for whatever reason.

Definitely. Do be aware that there's a few caveats to the new AVX/2 support though.

For one thing, if the codebase dynamically checks for AVX support at runtime, either with sysctl or CPUID, it will get told the CPU does *not* support AVX, so may report an error or run in the fallback "no-avx" mode. I've tested this myself. However, if forced to run anyway, the AVX instructions execute just fine. It's unknown to me if this is a bug or intended behaviour.

Second aspect is performance. Apple Silicon has two different mechanisms that sort of do something similar to AVX. It's got NEON and it's got SME/AMX. Based on performance, I at least feel confident in saying that AVX doesn't map to AMX. Probably not SME instructions (they go to AMX units) either but that's M4 only. This is good for latency, but bad for throughput so raw GFLOPs numbers will be somewhat low compared to what'd be possible with AMX, but it has its own set of constraints like acting as a streaming mode co-processor

 

[chaosbunny]

I'm very happy that the 16" i9 mbp that I bought in May 2020 is supported by another round of Mac OS. I can edit 4k/6k footage just fine in Davinci Resolve, Lightroom/Photoshop have no problems with the raw files from my Sony a7 IV and I can boot into Windows for gaming. I'm actually surprised how well it handles Horizon Forbidden West. Performance wise I see no reason to upgrade, so it's good that Apple will not be forcing me to do so for the next 3 years. After the PPC/Intel transition, I actually expected Sequoia to drop intel support.

 

[bzgnyc2]

Definitely. Do be aware that there's a few caveats to the new AVX/2 support though.

For one thing, if the codebase dynamically checks for AVX support at runtime, either with sysctl or CPUID, it will get told the CPU does *not* support AVX, so may report an error or run in the fallback "no-avx" mode. I've tested this myself. However, if forced to run anyway, the AVX instructions execute just fine. It's unknown to me if this is a bug or intended behaviour.

Second aspect is performance. Apple Silicon has two different mechanisms that sort of do something similar to AVX. It's got NEON and it's got SME/AMX. Based on performance, I at least feel confident in saying that AVX doesn't map to AMX. Probably not SME instructions (they go to AMX units) either but that's M4 only. This is good for latency, but bad for throughput so raw GFLOPs numbers will be somewhat low compared to what'd be possible with AMX, but it has its own set of constraints like acting as a streaming mode co-processor

Yes supporting AVX/VX2 but not reporting them is kind of weird. I am reading that decision as emulating AVX/2 instructions is not as fast as emulating typical fallback code but would be curious to test that and confirm that's the why behind that decision. Maybe something to do that next time I have an M-series handy...

I can accept that Rosetta2 run programs won't be as fast as native code and likely won't take advantage of special hardware features. If it runs most things at better than 50% of native excepting things like NPU that's pretty good.

The one thing I didn't understand in my limited testing (possibly 2 years ago) was that Rosetta2 didn't seem to take advantage of native libraries. So a Rosetta2-run program using the matrix multiplication routine from Accelerate didn't even run as fast as the same running natively even though I would have thought Rosetta2 would have just substituted the call to the native version and so basically run at full native speed. As I remember it, Rosetta2 emulated C versions of matrix multiplication I had handy faster than the calls to Accelerate (while normally using routines from Accelerate are much faster than anything written in C when running natively).

In any case, as long as it is clear that Apple understands that the Intel/AMD64 ISA is important for the forseable future and it needs to keep Rosetta2 around (and ideally improving it...), that helps with commitment to a non-Intel platform. No one has to like that ISA -- just accept it is a common target and it isn't going anywhere anytime soon.

 

[casperes1996]

Yes supporting AVX/VX2 but not reporting them is kind of weird. I am reading that decision as emulating AVX/2 instructions is not as fast as emulating typical fallback code but would be curious to test that and confirm that's the why behind that decision. Maybe something to do that next time I have an M-series handy...

Yeah; I've been thinking about trying that out myself but doubt I'll find the time any time soon

The one thing I didn't understand in my limited testing (possibly 2 years ago) was that Rosetta2 didn't seem to take advantage of native libraries. So a Rosetta2-run program using the matrix multiplication routine from Accelerate didn't even run as fast as the same running natively even though I would have thought Rosetta2 would have just substituted the call to the native version and so basically run at full native speed. As I remember it, Rosetta2 emulated C versions of matrix multiplication I had handy faster than the calls to Accelerate (while normally using routines from Accelerate are much faster than anything written in C when running natively).

Hm; I think there are/were some restrictions to changing modes in the middle of a running process - Like if you had a program that could act as a plugin host you could also only use x86 plugins when host was running under Rosetta and only ARM plugins when the host app was in native mode

 

[bzgnyc2]

Yeah; I've been thinking about trying that out myself but doubt I'll find the time any time soon

Hm; I think there are/were some restrictions to changing modes in the middle of a running process - Like if you had a program that could act as a plugin host you could also only use x86 plugins when host was running under Rosetta and only ARM plugins when the host app was in native mode

Yes my understanding of the way Rosetta2 works is that at least the entire thread (and possibly the entire process) have to be one architecture or the other. Calls between one or the other require at a minimum a "thunk" to translate across ABI calling conventions.

My assumption however is that Cocoa UI and similar stuff runs native versinos of those frameworks and it's not for example emulating Intel-versions of the Cocoa UI frameworks for Intel applications run under Rosetta2 on Apple Silicon. If so, I would assume they could do the same for Accelerate code. But maybe there is something about Accelerate that makes that harder or they're actually running the Cocoa frameworks supporting legacy applications under emulation as well.

 

[Icelus]

MacBook Air gets hosed, other models hold steady in macOS 15 as Intel support fades

Sequoia is both more and less generous to Intel Macs, depending on the model.

arstechnica.com

 

[Fishrrman]

Question:
"Will MacOS 15 drop support for Intel?"

The answer is "NO".
(nothing follows)

 

[conmee]

Now the question is: "Will macOS 16 drop support for Intel?"

I wonder if Apple will make a formal announcement about ceasing all Intel support or will they just somewhat quietly keep culling Intel model support until none remain. Pretty much anyone with an older Intel model only found out about support or not at WWDC when a new macOS is announced.

 

[basdeninard]

Now the question is: "Will macOS 16 drop support for Intel?"

I wonder if Apple will make a formal announcement about ceasing all Intel support or will they just somewhat quietly keep culling Intel model support until none remain. Pretty much anyone with an older Intel model only found out about support or not at WWDC when a new macOS is announced.

They will just cut support with a future release of macOS. It is not typical for Apple to pre-announce those decisions.

 

[bzgnyc2]

They will just cut support with a future release of macOS. It is not typical for Apple to pre-announce those decisions.

If they want to get more into enterprise sales (e.g. hospital IT departments), they are going to have to learn how to announce these things in advance. A lot of organizations don't like things being declared obsolete/unsupported with less than a year's notice.

 

[conmee]

They will just cut support with a future release of macOS. It is not typical for Apple to pre-announce those decisions.

Some people point to when Apple dropped 32-bit support. They started making regular statements to expect 32-bit support to end during Sierra. Then continuing those statements during High Sierra, then statements and pop-up notifications in Mojave. So at least with 32-bit support, they telegraphed the end for a couple years. The difference is 32-bit support affected everyone and many developers. Maybe they don’t feel the need to be so transparent with the dwindling Intel base. At this point, I know I have a little over 3 years of support at minimum for my 2019 MBP. So even if Sequoia is the last to support Intel, I’ll make it to October 2027, which is a nice 8yr run of support for my MBP. Assuming I don’t jump to M5/M6 by then. But currently, my workflow relies on x86 VMs and my MBP is still going strong for what I need it to do.

 

[basdeninard]

If they want to get more into enterprise sales (e.g. hospital IT departments), they are going to have to learn how to announce these things in advance. A lot of organizations don't like things being declared obsolete/unsupported with less than a year's notice.

They are not interested. They don't publicly disclose how long they support a given release of macOS. It is already the case that they are not interested in catering to the needs of enterprise customers.

Some people point to when Apple dropped 32-bit support. They started making regular statements to expect 32-bit support to end during Sierra. Then continuing those statements during High Sierra, then statements and pop-up notifications in Mojave. So at least with 32-bit support, they telegraphed the end for a couple years. The difference is 32-bit support affected everyone and many developers. Maybe they don’t feel the need to be so transparent with the dwindling Intel base. At this point, I know I have a little over 3 years of support at minimum for my 2019 MBP. So even if Sequoia is the last to support Intel, I’ll make it to October 2027, which is a nice 8yr run of support for my MBP. Assuming I don’t jump to M5/M6 by then. But currently, my workflow relies on x86 VMs and my MBP is still going strong for what I need it to do.

They are not likely to pre-announce when support for x86 is being dropped.