AMD’s Metal drivers have never really been a problem. AMD GPUs’ only weakness, aside from their pitiful performance vs. nVidia’s equivalent counterparts, is OpenGL performance and bugs. That’s simply due to an aged and deprecated OpenGL. Thankfully few Mac games use OpenGL anymore.
There’s nothing special about an “actual Mac SSD”. APFS performance degrades over time on all SSDs, including on “Mac SSDs”. It’s inherent to the mechanics built into the filesystem that haven’t been rectified yet. The CASC files structure used in Blizzard’s games only exacerbates that since they both share the same issues.
You’re taking one thing (enumeration) and turning it into ‘APFS SUCKS’.
Actual real world performance is fantastic on my MacBook Pro (even in WoW). Load times are great, file transfer speeds are great, and having a safe modern file system underpinning it all is great.
There’s no point in getting hung up on one negative aspect that’s there for a very good reason, and blowing it out of proportion.
You do realize that the only thing propping APFS is the SSD, right? Go try to run APFS on a platter based HD. I dare you. Watch your precious speed become worse than Windows on the same HD.
It isn’t blown out of proportion. APFS can actually bring even NVMe to its knees over time. That enumeration eats IOPS like candy. PCIe 4.0 might mitigate that further, but the speed would be far greater without the poor enumeration process.
I’ve run APFS on a spinning drive (my iMac), it’s not at all ideal.
Enumeration is only a part of the filesystem. And from my experience on my MacBook Pro, with copying/moving/deleting files all over the place… The experience is fantastic.
It’s not about it being ‘poor’… It’s a design choice that has benefits and tradeoffs. For the SSDs apple is shipping in it’s products, APFS is a huge huge upgrade in so many ways over HFS. APFS extends the lifespan of SSDs over HFS, that’s a huge bonus in itself.
You’re trading miniscule lifespan improvements for very noticeable speed penalties. As I said, SSDs are propping APFS up. You take the SSD out of the equation and it becomes an abysmal filesystem to work with. But even with an SSD over time APFS degrades performance enough that a full-on OS reinstall is warranted. And Omegal showed just how bad it gets with APFS even on NVMe - he topped out at about 750 MB/sec on a Samsung 970 Pro that’s rated for nearly four times that. The enumeration aspect of APFS results in a massive amount of 4k random reads, which is where SSDs and especially HDs are weakest at (on the read side; SSDs vary widely on the 4k writes, getting worse as you go from SLC > MLC > TLC > QLC).
BTW, my games drive, that gets lots of writes from patches, is an OCZ Vertex 4 256 GB. From ten years ago and SMART shows 82% life left. My Samsung 840 Pro from 2012 (256 GB), which is my OS drive, shows 95% life left. From the drive’s own indicators. On HFS+.
So no, I don’t buy APFS measurably improving SSD lifespan. If anything the way it writes b-tree extents nodes all over the place (the parts that are read when enumeration occurs) shortens lifespan because those writes take up full cells even if it’s far less than the cell can hold. Any space savings you gain from the copy on write (the “fake” copy APFS does when you try to copy a file) is lost from b-tree nodes scattered across the eleventy billion cells used to store them.
Where APFS shines is in its containers. Nearly everyone I’ve looked at says those are much nicer to work with than HFS+ volumes were. Being on HFS+ still, I haven’t had a chance to work with them myself, but if it’s nearly unanimous with the praise on the containers, it’s hard to say that aspect is bad.
APFS’ Achille’s Heel is its b-tree enumeration system. If that one aspect were dealt with, it would sing on any type of drive.
You’ll get that on sequential reads. You won’t get that on mixed reads, and definitely not on writes. Sequential stuff is virtually identical across OSes. It’s mixed/4k that is not. The numbers you quoted are definitely not mixed/4k numbers.
APFS is going to perform equally well on a hackintosh or a Mac given equivalent SSDs. That’s a pretty poor argument on your part there. It’ll also perform equally abysmal when the extents nodes have piled up. APFS’ performance is directly tied to how many IOPS are occuring and what kind of operations are taking place (4k/8k/16k/32k/64k/128k reads/writes).
BTW, I do own a Mac Pro. Just not one that can go to 10.13. Yay being an early adopter. As to your experiences, you’ve obviously not run into the degredation yet. I’m actually happy for you. It may be because TRIM has freed up enough contiguous cells to stave off that problem or it may simply be you haven’t done enough writes in various locations on the SSD to create many smaller contiguous gaps. The degree which the latter occurs will vary by SSD size. On a smaller one like mine that’s only 256 GB (my OS drive), it would occur much sooner than it would on say, a nice shiny 2 TB drive.
If there’s one thing OS X has for a saving grace, APFS or no APFS, it’s that it doesn’t constantly write to the drive like Windows 10 does. It lets the SSD idle long enough to actually invoke TRIM more often than in Windows, and as a result of not constantly writing to the SSD, will have far better lifespan with either HFS+ or APFS than Windows 10 will. I’ve lost more lifespan on my Windows 10 SSD in just a year than I have in eight years of OS X on the other SSD. That’s why the lifespan savings of APFS are miniscule at best - the OS already minimizes writes. You’d have to constantly write to the drive for APFS to show measurable gains in lifespan. Except on QLC drives. Anything will help with those god awful monstrosities (thankfully Apple will likely never employ that kind of SSD).
Of course, most of APFS’ weaknesses are rendered virtually entirely moot if you have either a 2019 Mac Pro outfitted with a PCIe SSD card with at least an x8 interface or an Intel HEDT w/ the same card (Intel HEDTs have enough PCIe lanes that NVMe and/or PCIe slots get direct lanes to the CPU, unlike mainstream Intel CPUs).
Again, I’m happy for you that you haven’t run into issues yet. Unfortunately, many, many others have. It’s simply a matter of time relative to the workload employed on the machine.
FYI, AMD sub contracts their driver engineers to apple. they actually work at apple campus and report to apple. They essencially work for apple more than they do AMD. Apple also has controlling authority. They could fix things asap, and probalby do, they just don’t push those fixes out immediately they batch them together in next major OS update or if they are critical enough (usually a NON gaming issue affecting overall system stability or some pro apps) then it’ll go into next point update for current OS, even then that could be a few week wait.
This was one of the many issues apple had with nvidia. Nvidia refused to sub contract. Their stance was “our guys work for us, not you” and would not lend engineers to work directly for apple. They said they’d get driver updates on their terms not apples, and well you know what apple said back.
AMD’s Metal drivers are just fine. Their OpenGL drivers are another matter entirely. But since Apple killed 32-bit support, which is where most OpenGL games reside, very few games are left to worry about. Diablo 3 is the primary one, and it isn’t likely to get Metal support with how many corners Blizzard has been forced to cut under Activision’s “leadership”.
Because they knew they could tell people to install WIndows on their Mac to run it natively - the lazy way out. This time, they might not be so lucky unless they depend on Rosetta 2.
Do you think people will still be complaining about losing 32-bit support in 10 years or is the salt just exponentially worse during this transition period?
A lot of games, even from AAA studios, are 32-bit. Nearly every Mac compatible game in my Steam library now has a warning that it won’t run on Catalina or later. You won’t get any argument from me that 32-bit operating systems need to go (*cough* Microsoft *cough*), but access to 32-bit apps needs to remain in the kernel. It doesn’t affect the rest of the OS to have access to the 32-bit userspace apps, since the OS and the rest of the apps are in native 64-bit.
It would have made sense if they were killing 32-bit at the same time they removed OpenGL from the OS. That is something that actually fits since all that is left is Metal and Metal requires 64-bit apps. I’m not sure if Vulkan does, but it would make sense if it has that requirement too given the nature of the apps and games that would use that API and their memory requirements almost certainly being >3.5 GB.
I’m down to literally one game that I play in OS X now. Diablo 3. Once that is gone from the equation I have little left to keep me in OS X. Apple Arcade doesn’t even register on my radar as I loathe subscriptions like that. Hell, I’m typing this from Windows because yet another game I want to play has no OS X counterpart (replaying Final Fantasy XIII, this time in gloriously smooth 60 FPS, not that horrible 30 FPS sometimes and slowdowns everywhere else like it was on the PS3).
Losing 32-bit userspace access cuts of a lot more than you think it does, especially for games that aren’t going to get an architecture update to keep running. And keep in mind that I went through the PPC to Intel transition, then the whole problem with the 32-bit kernel being removed from the OS back when Lion came out, which royally screwed Mac Pro 1,1/2,1 owners like myself. Apple is giving its gamers less and less of a reason to remain on the platform with each “transition” that turns into a betrayal in the end.
It was Steve Jobs dream that put a fire under Apple once again. It’s what got me to come over to Apple in the first place, I was there when the OSX revolution began. Had Microsoft actually accomplished something in that timeframe I think the computing landscape would be entirely different than it is now.
But alas, the writing has been on the wall for quite some time now. It’s not just gaming that they are abandoning… it’s professional apps as well. I hope the entertainment industry does them well in the future because that is literally where all their focus is these days… selling you some sort of a subscription to something.
Too many players in that arena already and quite frankly it didn’t need another one.
FWIW, 64-bit processes can still run 32-bit code under Catalina. It’s what WINE does under macOS now. The problem was needing to keep around 32-bit versions of all the various frameworks (AppKit, etc) which 32-bit apps need in order to launch. Abandoning 32-bit also allowed them to make some long-needed changes in the Objective-C runtime.
They could have kept the 32-bit Mojave versions of these frameworks around in the Intel builds of Catalina through whatever version they drop Intel support in, but it would’ve only moderately increased the lease on life that 32-bit apps had, and only on Intel machines.
Aside from that, Microsoft is closing in on dropping direct 32-bit support too. They no longer offer 32-bit builds of Windows, and probably within the next 5 years 32-bit apps will need to be run in a virtualized environment. Some major Linux distros now only offer 64-bit versions, and Ubuntu recently toyed with dropping support for 32-bit software within 64-bit OS builds.
Apple might be jumping the gun a bit, but this is something that users and developers on all platforms will need to contend with sooner than later. It’s no longer realistic for a developer to expect their code to run unmodified for eons.
Gaming maybe, but they seem plenty interested in the pro industry. More than half the time spent in the macOS demos at WWDC was showing off Adobe Photoshop + Illustrator, Final Cut Pro, Maya under Rosetta, etc.
WINE’s wrapper itself is 64-bit, running as a container (virtualized environment). That wont’ help native Mac games or apps. Apple should have kept 32-bit support in until the end of the Intel to ARM transition, as none of their ARM apps or games are 32-bit anymore (that’s been long gone on iOS devices).
MS could easily nudge users to the 64-bit version of Windows 10 by offering the 32-bit users a 64-bit key for their specific hardware (if OEM) or a 64-bit reusable key (if retail). If Microsoft announced it was ending 32-bit support and doled out those 64-bit keys to get users to transition faster, it would actually help nudge the game industry to get their apps either updated or for companies like GOG or Valve to create a way to put their games into containers to run as a VM (Windows on Windows is much faster than WINE on OS X). They should have done this years ago IMO to speed things up. Oh well.
Interestingly, given all those words, you didn’t actually answer the question.
Do you think people will still be complaining about losing 32-bit support in 10 years or is the salt just exponentially worse during this transition period?
Assuming there are ways to run the software in either a container or virtualized environment down the road, then no, there won’t be issues. And you asked “ten years out”. By then either what gamers want will be available in virtualized or remade (modern) format or it won’t. There are too many variables for a 100% ironclad guarantee of an answer to your question. After all, there are still a few, though thankfully very few, PPC specific apps that companies use that were never updated for the Intel architecture. It happens.
I have alternatives currently, so most, if not all of what I lose on the Apple side I retain on the Windows side. With such a large swath of games being 32-bit on that side, it’s a fair bet a solution will come out prior to full-blown bye bye 32-bit OS. Hopefully a bit more elegant than what we have with DOSBox and 16-bit games.
