Slashdot Mirror
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.
I had a look in activity monitor and I have 3 32-bit processes running and I found 3. Two were part of novaterm, which I installed years ago to do HP TouchPad development and haven't used since HP abandoned WebOS, but which I apparently left installing some daemons. The remaining one was the Android File Transfer agent, because apparently I haven't updated Android File Transfer since 2012 and it doesn't auto-update. After a small cleanup, I am now running none.
There's actually only one 32-bit application that I do care about: WINE. There's no reason that WINE couldn't be made to launch 32-bit Windows apps as a 64-bit binary though: it already includes its own program launcher and thunks for calling from Windows libraries into host-system ones.
The benefit is not just saving a few GBs of system libs. It's not having to do QA on any 32-bit versions of software. Apple's 64-bit Objective-C ABI is very different to its 32-bit one (small objects are hidden in pointers, reference counts are embedded in isa pointers, and so on). Making sure that none of the 100MBs or so of Objective-C frameworks that they ship have different observable behaviour with the different pointer sizes is a significant testing overhead. It's also a noticeable memory overhead if you run one app that pulls in the 32-bit versions of all of the system libraries. Even just the small set that you need to link to for any GUI application that adds up to around 50MB of object code, which is not shared with any of the 64-bit processes and so consumes L1 icache and L2/L3 cache space, making everything else slower.
I am TheRaven on Soylent News
Memory space has nothing to do with it. 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). Less relevant for Apple, because they never supported anything older than a Core 1, but it also typically means being able to assume SSE.
In all except for a few rare circumstances, x86-64 code is faster than x86-32 code on the same processor (the same does not apply to all other 32/64-bit architecture pairs). On top of the underlying improvements, there are a number of 64-bit-only optimisations in Apple's Objective-C implementation (and Objective-C code accounts for a very large proportion of their total code). The class pointer has a load of spare bits at the top, so reference counts are stored inline there. Small objects can be embedded in pointers (including small ASCII strings, which account for a large proportion of dictionary keys and can significantly reduce memory usage and improve performance).
Oh, and it's worth noting that there was a very small window when Apple shipped 32-bit x86 machines. For the Mac Mini, February 2006 to August 2007. For the MacBook, May 2006 to November 2006. For the MacBook Pro, January 2006 to October 2006. The last version of OS X to support the 32-bit chips was 10.6.8, released 8 years ago and discontinued (no more support updates) in July 2011.
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). XCode was able to produce 64-bit binaries and 32/64-bit fat binaries prior to the Intel switch and most Mac apps moved to being 64-bit a long time ago.
I am TheRaven on Soylent News
Actually, I am.
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).
I am TheRaven on Soylent News
Games are an example of software that doesn't usually get updated, but you still want them to keep working.
Frankly I wish programmers like you (who don't have respect for backwards compatibility) would crawl into a ditch and die, but I don't get everything I want in this world.
"First they came for the slanderers and i said nothing."
Yeah, but x32 linux is faster for pretty much everything than amd64 or i386, so it's not the "64-bit" that makes it faster, it's the "extra registers and instructions" Ditching the 64 bit pointers makes programs faster.
A large part of the Apple software stack is Objective-C. On 32-bit platforms, every object has a 32-bit reference count, which is stored in a look-aside table (which I think is an llvm::DenseMap now). Every reference count manipulation (which happens on almost every heap assignment of an object pointer) requires locking the table (or, at least, one of the tables - I think there are 8 on the desktop builds), looking up the refcount indexed by the object, and modifying it. On 64-bit platforms, Apple stores the reference count in the top 16 bits of the class pointer. Updating it is an atomic instruction.
When you create an NSString or NSNumber instance on 32-bit Apple platforms, you are creating an object on the heap. This requires a reference count in the table if it is ever retained (i.e. a pointer to it is stored on the heap), a 32-bit class pointer and at least 32 bits for the value, typically more. This space is probably rounded up to 16 bytes, for alignment. When you create an NSNumber instance or a short NSString on 64-bit Apple platforms, the value is embedded in the pointer. Creation is some bit twiddling in a register, no memory allocation. When I profiled some desktop applications some years ago (before Apple implemented this optimisation), I found that around 10% of all object allocations were strings that could be stored in a pointer. That saving alone is worth the 64-bit switch for most Objective-C applications.
Most JavaScript implementations see similar benefits on 64-bit, though from quite different implementation techniques.
I am TheRaven on Soylent News