Apple Starts Alerting Users That It Will End 32-Bit App Support On the Mac (techcrunch.com)

An anonymous reader quotes a report from TechCrunch: Tomorrow at midnight PT, Apple will begin issuing an alert box when you open a 32-bit app in MacOS 10.13.4. It's a one-time (per app) alert, designed to help MacOS make the full transition to 64-bit. At some unspecified time in the future, the operating system will end its support for 32-bit technology meaning those apps that haven't been updated just won't work. That time, mind you, is not tomorrow, but the company's hoping that this messaging will help light a fire under users and developers to upgrade before that day comes. Says the company on its help page, "To ensure that the apps you purchase are as advanced as the Mac you run them on, all future Mac software will eventually be required to be 64-bit." As the company notes, the transition's been a long time coming. The company started making it 10 or so years ago with the Power Mac G5 desktop, so it hasn't exactly been an overnight ask for developers. Of course, if you've got older, non-supported software in your arsenal, the eventual end-of-lifing could put a severe damper on your workflow. For those users, there will no doubt be some shades of the transition from OS 9 to OS X in all of this.

Comments

why?

[Anonymous Coward]

To save a few GB in system libs? I realize that there are arch improvements in amd64 but that's no reason to break compatibility.

Re:why?

[drinkypoo]

To save a few GB in system libs? I realize that there are arch improvements in amd64 but that's no reason to break compatibility.

It's probably actually to reduce testing. It's still dumb. You're gonna have to run a VM to run 32 bit software. Even Microsoft is better at back compatibility than that. But Apple has never been shy about forcing its customers to spend more money, because they repeatedly demonstrate a willingness to do that — and they often give it to Apple.

Re:why?

[KiloByte]

I realize that there are arch improvements in amd64 but that's no reason to break compatibility.

64-bit on x86 royally sucks. Beside unavoidable issues related to 64-bit in general (twice as big pointers, thus any pointer-heavy structure taking twice as much memory, thus cache lines), on x86 in particular it's a dirty hack.

To get slower than amd64, you'd need an ancient register-starved ABI that passes way too much on stack, can't use floating point efficiently, may not pass 64-bit arguments when you actually need them, etc -- ie, i386.

Compare this with a modern 32-bit ABI on x86 (ie, x32). An average program takes ~2/3 memory to run, speed depending on how much pointers you use, but +7% is typical, over 40% in certain cases.

On architecture families that were designed with 64-bit in mind, most of this benefit disappears, but on x86 sane 32-bit wins handily.

Re:why?

[TheRaven64]

Compare this with a modern 32-bit ABI on x86 (ie, x32). An average program takes ~2/3 memory to run, speed depending on how much pointers you use, but +7% is typical, over 40% in certain cases.

I'd be very interested in where you get those numbers from. I work on a research architecture that uses 128-bit pointers and we find that in most cases your DRAM traffic increases by under 10% going from 64-bit to 128-bit. A 7% performance delta sounds about what I'd expect, but 2/3 more memory doesn't. That implies that around 2/3 of your memory is pointers - our measurements indicate that for most workloads (including most of SPEC) it's closer to 10-20% and the number goes down for more performance-critical workloads because developers try very hard to avoid pointer chasing (because it doesn't play well with modern pipelines) in such code.

With my FreeBSD hat on, I did a little bit of analysis of the x32 ABI and concluded that it is better for most systems only if you don't use the x64 ABI for anything. The performance hit from reduced cache sharing between processes for common shared libraries was greater than the performance win from x32. This was the same result that Sun Research found on SPARC 20 years earlier: the 32-bit ABI was better if everything used it, but if you use 1-2 64-bit programs then you lose more then you gain.

This is even more true on something like macOS, where there's a big shared memory region where all of the common system libraries are pre-loaded and then accessed via a per-process offset (and where the kernel is set up so that all mappings of this region share leaf page table entries and so reduce cache pressure on TLB misses).

Re:why?

[Anonymous Coward]

Memory space has nothing to do with it.

Not quite "nothing", thank you.

64-bit means a lot more general-purpose registers, 64-bit registers (x86-32 uses pairs of registers for 64-bit operations and typically requires a stack spill for each one), and PC-relative addressing (makes anything that uses shared libraries faster).

I know. Just wrote a bit of 32bit assembly that keeps the entire program state in registers. It emulates a rather more simple stack machine CPU.

But yes, enlarging the register file is what brought the big improvement in speed. Apparently the "CISC but RISC underneath"-marketeering was so much bullshit and the register file is a big fat bottleneck on x86. The 64bit register width isn't even that important since you don't really need more for most office and other "consumer" tasks anyway. Certainly not since as soon as you do need more bits the task turns out to be one for which there already is some extension or other to do the heavy lifting. The many extensions in x86 don't use the general register file.

But really, that's hardly relevant. What this is about is having programs that you got as a 32bit binary that work but somehow aren't updateable. Of course, apple typically doesn't care and just tells you to "upgrade", to a competitor's application if you have to, regardless of its cost to you.

Oh, and it's worth noting that there was a very small window when Apple shipped 32-bit x86 machines.

They probably should have refrained from doing that. They could've gone full 64bit from the start and not have to slam the door later. A little thought beforehand, etc.

Most people buying x86 Macs around the transition held off until the 64-bit ones, because it was pretty obvious at launch that Apple would move to 64-bit quickly (the lack of 64-bit mobile PowerPC chips was one of the reasons for their switch to Intel).

"We can't have 64bit mobile PowerPC chips so we'll ship 32bit wintendo mobile chips instead." This makes no sense.

For PowerPC the register file argument doesn't hold, by the by. Which is really the only thing that causes a big win outside scientific computing for x86 going from 32 to 64bit, certainly if "memory space has nothing to do with it."

Anyway, all that is rationalisation to the net effect of being less responsible than they could be, and I'm saying, you don't get to shout at the users of your "ecosystem" if you created your "ecosystem" to be this way.