You're right, but I wonder how their revenue per customer is clustered. I would expect that, on average, Facebook users in the US and EU have significantly more disposable income than those elsewhere (as I understand it, most people with money in China are using home-grown alternatives to Facebook). If it's a 5% drop in people reachably by their biggest advertisers, then that would be cause for concern. If Facebook stops being the ad platform with the biggest reach and is not a brand that has positive recognition then moving ad budgets elsewhere starts to look like a good idea. I suspect Facebook would struggle if 50% of US advertisers went elsewhere.
If you think that 'how to contact you' is all that they get from their massive surveillance and psychological profiling engine that you're happy to opt into, then you're incredible naive. That attitude does explain why so many people are on Facebook though.
It's not the number I'm interested in. I want to know what advertisers are pulling Facebook ads. If you want to hurt Facebook, don't try to make people leave, organise a boycott of any company that uses Facebook for communicating with its customers and of any company that advertises on Facebook.
I assume he means on every API call and worse, on every bit of IPC with the messaging and object subsystems.
The only time things need thunks is when you're communicating between the 32-bit world inside the WINE environment and the 64-bit world outside. At that point, you already need thunks to get between the Windows ABI structure layouts and the host's (typically SysV) ABI structure layouts.
A typical C++ STL-using project has a lot of pointers.
We've measured this and found it less significant than you are implying.
Then, you get larger struct alignment.
That's the big one, though that's much more relevant for the 64 to 128-bit jump, because by now most structures are sensibly laid out for 64-bit systems, but gain padding on 128. We saw a 20% overhead in a couple of benchmarks which went down to under 5% when you rearranged a couple of struct fields.
Java is even worse.
No it isn't, because most Java implementations (including OpenJDK and ART) don't use 64-bit pointers by default on 64-bit systems, they use 32-bit pointers that are left shifted by 3 and added to the Java heap base address. The allocator is happy to 8-byte align allocations, so that gives a 64GB heap size, which is enough for almost all Java programs. JavaScript implementations, in contrast, typically use 64-bit pointers (or, rather, 64 bit gaps in object structures to store pointers in) on 32-bit platforms because they need to handle the case that someone stores a Number (represented as a double) into them.
How much does a System/Z (sorry, apparently it's IBM Z this week) machine cost compared to a Mac? I actually have no idea, but the fact that IBM doesn't have a price list - or even a product list - and instead has a 'Request a consultation' button for people interested in buying one tells me that it's not going to be cheap.
If you want long-term support and are willing to pay for it, then there are platforms available and whatever OS/360 is called this week is the absolute gold standard for this. If you aren't willing to pay for it, don't be surprised when it goes away.
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.
In your world VMs have direct access to the video card?
Depends on the host / guest pair, but yes, often. Well, not quite direct access, but paravirtualised (so they can do 3D acceleration, which is what I think you actually want). Most modern GPUs do user-mode command submission, so the kernel is responsible for setting up the memory mappings in the MMU and IOMMU and then userspace communicates directly with the GPU. This kind of setup is very easy to support in virtualised environments.
Yes you are, the EULA explicitly permits you to run macOS in a VM, but only on Apple hardware. VirtualBox will boot macOS on macOS out of the box, but you need to patch it to work on other host systems.
Except in the case of games. A lot of Windows 95 games never made it over the transition to the NT kernel. I have a few games from that era that run well on a Mac or other *NIX box under WINE, but don't work on a modern Windows system.
In 2005, I spent £100 on a PC-Engines WRAP. That machine outperformed the fastest 486 ever produced and used 7W under load. Most 486s used at least 50W, but let's be generous and say 30W. Electricity cost, to a rough approximation (which was still roughly valid back then) around £1/WYear, so if you'd done the same you'd have saved £276 in power (probably more, but I'm being very generous in my estimations) for an up-front cost of £100. That's roughly equivalent to investing the money in something that's earned 10% interest per annum, compounded over the entire term. I hope you invested the money that you saved by not upgrading the 486 very well!
I, too, would like to find one. Last time I looked, someone had a design for one that you could make at home, if you could source the parts, but I don't really know if my 5.25" floppy disks still work so I'd rather not have two variables to test at the same time.
You joke, but the last study I saw referenced in the news (and didn't read) was about a year ago and concluded the exact opposite to this one. I wonder what the causes of death are and whether it's different based on population sizes (is one group more likely to be exposed to pollution, accidents, or sunlight than the other in a locale-dependent way, for example?)
Having a 64 bit Wine handle 32 bit Windows applications means converting pointer sizes on the way in and again on the way out
That's true, but in and out of what?
For instance take the CreateProcess() [microsoft.com] API.
And most of its implementation in WINE is in a PE/COFF binary that will be compiled in 32-bit mode. Only things that call system libraries will need translation.
If you have unlimited developer resources, by all means spend them making everything better. If you have finite developer resources, you need to prioritise. Supporting 32-bit applications, when the last version of Mac OS X that couldn't run 64-bit ones was EOL'd 7 years earlier and the standard Mac toolchain has built 64-bit binaries by default for over 10 years is not likely to affect very many people.
Totally irrelevant. Windows ran on 32-bit x86 systems since 1993 (NT 3.1) and 32-bit was the most common version of Windows since late 1995. Mac OS X shipped 32-bit x86 on laptops for about 6 months, low-end desktops (Mac Mini) for about 18 months and on high-end desktops never. The last version of OS X to run on 32-bit processors was released in 2009 and reached EOL in 2011. Mac OS X never ran on a Pentium 4 and it shipped on Core 1 (the only x86 processors that it ever shipped on) for a very limited period.
Personally, I'd rather that they invest their finite developer resources in something that affects 99% of users, rather than something that affects 1%.
Availability of 64bit PPC hardware to run OSX predates the 32bit x86 version, so they actually took a step backwards.
My memory is a bit fuzzy. When they shipped the G5, they supported 64-bit processes, but didn't provide 64-bit versions of any of the GUI libraries, so things that wanted to run 64-bit code needed to do it in a separate process. Did they ship a 64-bit version of Cocoa for PowerPC before they supported it on x86, or was it released at the same time for both?
The only non 64bit x86 macs are the very first model laptops, IIRC even the first gen mac pro was 64bit from the start.
The Mac Mini was 32-bit for about 18 months. It was Mac Mini owners that were the loudest to complain when 10.7 dropped support for 32-bit CPUs.
Any macOS dev who is actively developing their code will already be developing a 64-bit version. XCode has defaulted to fat binary (32/64-bit) builds since 2006 and on all versions of OS X since 2011 and any older version on a 64-bit chip the system will launch the 64-bit version in preference. You have to explicitly opt out of 64-bit support. It's far more common for developers to not bother with the 32-bit version.
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).
You're gonna have to run a VM to run 32 bit software
What 32-bit software?
Even Microsoft is better at back compatibility than that
The first version of Windows to support 32-bit x86 applications was Windows NT 3.1. It ran on a 386. Since then, Windows has been collecting 32-bit applications and it's only recently that a large enough proportion of the installed base has been running 64-bit Windows on 64-bit processors that it's made sense to switch.
In contrast, the first version of OS X to support 32-bit x86 applications was Mac OS X 10.4, which also added support for 64-bit x86 applications in a point release. It originally ran on Core 1 processors. With the exception of the Mac Mini, most Apple product lines included 32-bit x86 processors for about six months (about 18 for the Mac Mini). The last version of OS X to support 32-bit x86 processors was 10.6, which shipped in 2009 and was EOL'd in 2011.
Microsoft is pretty good at backwards compatibility in general (take a look at the contortions that they go to so that old ATL apps don't break with their control-flow integrity protection), but in this case they have much more need to be. 32-bit x86 apps were the main thing that Windows ran for 20 years. They were the main thing that OS X ran for about a year.
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.
Everyone who buys a Mac is paying to subsidise the continued maintenance and support of the 32-bit versions of system libraries. Very few people are actually using these libraries. You seem to want other people to subsidise your purchasing decisions either way.
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.
Is this actually useful? My optician takes a photo of my retina each year and compares it with the previous one when I have my sight tested. This comparison apparently provide a very high rate of detection of diabetes (before any other symptoms are visible). Do you really need a pattern-recognition system to do this? Is it actually better than an optician?
Slashdot Mirror
You're right, but I wonder how their revenue per customer is clustered. I would expect that, on average, Facebook users in the US and EU have significantly more disposable income than those elsewhere (as I understand it, most people with money in China are using home-grown alternatives to Facebook). If it's a 5% drop in people reachably by their biggest advertisers, then that would be cause for concern. If Facebook stops being the ad platform with the biggest reach and is not a brand that has positive recognition then moving ad budgets elsewhere starts to look like a good idea. I suspect Facebook would struggle if 50% of US advertisers went elsewhere.
If you think that 'how to contact you' is all that they get from their massive surveillance and psychological profiling engine that you're happy to opt into, then you're incredible naive. That attitude does explain why so many people are on Facebook though.
It's not the number I'm interested in. I want to know what advertisers are pulling Facebook ads. If you want to hurt Facebook, don't try to make people leave, organise a boycott of any company that uses Facebook for communicating with its customers and of any company that advertises on Facebook.
I assume he means on every API call and worse, on every bit of IPC with the messaging and object subsystems.
The only time things need thunks is when you're communicating between the 32-bit world inside the WINE environment and the 64-bit world outside. At that point, you already need thunks to get between the Windows ABI structure layouts and the host's (typically SysV) ABI structure layouts.
A typical C++ STL-using project has a lot of pointers.
We've measured this and found it less significant than you are implying.
Then, you get larger struct alignment.
That's the big one, though that's much more relevant for the 64 to 128-bit jump, because by now most structures are sensibly laid out for 64-bit systems, but gain padding on 128. We saw a 20% overhead in a couple of benchmarks which went down to under 5% when you rearranged a couple of struct fields.
Java is even worse.
No it isn't, because most Java implementations (including OpenJDK and ART) don't use 64-bit pointers by default on 64-bit systems, they use 32-bit pointers that are left shifted by 3 and added to the Java heap base address. The allocator is happy to 8-byte align allocations, so that gives a 64GB heap size, which is enough for almost all Java programs. JavaScript implementations, in contrast, typically use 64-bit pointers (or, rather, 64 bit gaps in object structures to store pointers in) on 32-bit platforms because they need to handle the case that someone stores a Number (represented as a double) into them.
If you want long-term support and are willing to pay for it, then there are platforms available and whatever OS/360 is called this week is the absolute gold standard for this. If you aren't willing to pay for it, don't be surprised when it goes away.
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.
In your world VMs have direct access to the video card?
Depends on the host / guest pair, but yes, often. Well, not quite direct access, but paravirtualised (so they can do 3D acceleration, which is what I think you actually want). Most modern GPUs do user-mode command submission, so the kernel is responsible for setting up the memory mappings in the MMU and IOMMU and then userspace communicates directly with the GPU. This kind of setup is very easy to support in virtualised environments.
Yes you are, the EULA explicitly permits you to run macOS in a VM, but only on Apple hardware. VirtualBox will boot macOS on macOS out of the box, but you need to patch it to work on other host systems.
Except in the case of games. A lot of Windows 95 games never made it over the transition to the NT kernel. I have a few games from that era that run well on a Mac or other *NIX box under WINE, but don't work on a modern Windows system.
In 2005, I spent £100 on a PC-Engines WRAP. That machine outperformed the fastest 486 ever produced and used 7W under load. Most 486s used at least 50W, but let's be generous and say 30W. Electricity cost, to a rough approximation (which was still roughly valid back then) around £1/WYear, so if you'd done the same you'd have saved £276 in power (probably more, but I'm being very generous in my estimations) for an up-front cost of £100. That's roughly equivalent to investing the money in something that's earned 10% interest per annum, compounded over the entire term. I hope you invested the money that you saved by not upgrading the 486 very well!
I, too, would like to find one. Last time I looked, someone had a design for one that you could make at home, if you could source the parts, but I don't really know if my 5.25" floppy disks still work so I'd rather not have two variables to test at the same time.
You joke, but the last study I saw referenced in the news (and didn't read) was about a year ago and concluded the exact opposite to this one. I wonder what the causes of death are and whether it's different based on population sizes (is one group more likely to be exposed to pollution, accidents, or sunlight than the other in a locale-dependent way, for example?)
Having a 64 bit Wine handle 32 bit Windows applications means converting pointer sizes on the way in and again on the way out
That's true, but in and out of what?
For instance take the CreateProcess() [microsoft.com] API.
And most of its implementation in WINE is in a PE/COFF binary that will be compiled in 32-bit mode. Only things that call system libraries will need translation.
If you have unlimited developer resources, by all means spend them making everything better. If you have finite developer resources, you need to prioritise. Supporting 32-bit applications, when the last version of Mac OS X that couldn't run 64-bit ones was EOL'd 7 years earlier and the standard Mac toolchain has built 64-bit binaries by default for over 10 years is not likely to affect very many people.
Totally irrelevant. Windows ran on 32-bit x86 systems since 1993 (NT 3.1) and 32-bit was the most common version of Windows since late 1995. Mac OS X shipped 32-bit x86 on laptops for about 6 months, low-end desktops (Mac Mini) for about 18 months and on high-end desktops never. The last version of OS X to run on 32-bit processors was released in 2009 and reached EOL in 2011. Mac OS X never ran on a Pentium 4 and it shipped on Core 1 (the only x86 processors that it ever shipped on) for a very limited period.
Personally, I'd rather that they invest their finite developer resources in something that affects 99% of users, rather than something that affects 1%.
Availability of 64bit PPC hardware to run OSX predates the 32bit x86 version, so they actually took a step backwards.
My memory is a bit fuzzy. When they shipped the G5, they supported 64-bit processes, but didn't provide 64-bit versions of any of the GUI libraries, so things that wanted to run 64-bit code needed to do it in a separate process. Did they ship a 64-bit version of Cocoa for PowerPC before they supported it on x86, or was it released at the same time for both?
The only non 64bit x86 macs are the very first model laptops, IIRC even the first gen mac pro was 64bit from the start.
The Mac Mini was 32-bit for about 18 months. It was Mac Mini owners that were the loudest to complain when 10.7 dropped support for 32-bit CPUs.
Any macOS dev who is actively developing their code will already be developing a 64-bit version. XCode has defaulted to fat binary (32/64-bit) builds since 2006 and on all versions of OS X since 2011 and any older version on a 64-bit chip the system will launch the 64-bit version in preference. You have to explicitly opt out of 64-bit support. It's far more common for developers to not bother with the 32-bit version.
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).
You're gonna have to run a VM to run 32 bit software
What 32-bit software?
Even Microsoft is better at back compatibility than that
The first version of Windows to support 32-bit x86 applications was Windows NT 3.1. It ran on a 386. Since then, Windows has been collecting 32-bit applications and it's only recently that a large enough proportion of the installed base has been running 64-bit Windows on 64-bit processors that it's made sense to switch.
In contrast, the first version of OS X to support 32-bit x86 applications was Mac OS X 10.4, which also added support for 64-bit x86 applications in a point release. It originally ran on Core 1 processors. With the exception of the Mac Mini, most Apple product lines included 32-bit x86 processors for about six months (about 18 for the Mac Mini). The last version of OS X to support 32-bit x86 processors was 10.6, which shipped in 2009 and was EOL'd in 2011.
Microsoft is pretty good at backwards compatibility in general (take a look at the contortions that they go to so that old ATL apps don't break with their control-flow integrity protection), but in this case they have much more need to be. 32-bit x86 apps were the main thing that Windows ran for 20 years. They were the main thing that OS X ran for about a year.
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.
Everyone who buys a Mac is paying to subsidise the continued maintenance and support of the 32-bit versions of system libraries. Very few people are actually using these libraries. You seem to want other people to subsidise your purchasing decisions either way.
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.
Is this actually useful? My optician takes a photo of my retina each year and compares it with the previous one when I have my sight tested. This comparison apparently provide a very high rate of detection of diabetes (before any other symptoms are visible). Do you really need a pattern-recognition system to do this? Is it actually better than an optician?