Apple to debut multiple ARM MacBook, desktop models in 2021(appleinsider.com)
appleinsider.com
Apple to debut multiple ARM MacBook, desktop models in 2021
https://appleinsider.com/articles/20/03/26/apple-to-debut-multiple-arm-powered-mac-desktop-and-laptop-models-in-2021
129 comments
ARM Macs are one of the things I don't want to be an early adopter of. I am going to stay with Intel as long as possible but I am excited about making the switch to ARM once it's shown to not be a hassle.
This is Apple we're talking about -- and Apple is what other OEMs want to be when they grow up. Not only will the Apple-designed ARM CPUs perform at or above the level of a similarly-specced Intel machine, but the ISA transition will be seamless, with a nearly-invisible Intel binary compatibility layer that does on-the-fly JITing. Otherwise, they simply won't release it at all.
I think you are over-estimating the quality of their software engineering. Maybe ten years ago I would have believed this, but with each macOS release the litany of unforced errors just continues to grow. The advantage Apple derives from owning the whole stack is a bit oversold, at least when it comes to their non-iOS products.
Of course this is anecdotal, but my macbook (made solely from Apple-supplied parts) seems to crash 3x as often as my cobbled-together-from-spare-parts Windows 10 desktop.
> Otherwise, they simply won't release it at all.
Do you think post-Jobs Apple retains that discipline? I'm not sure.
Of course this is anecdotal, but my macbook (made solely from Apple-supplied parts) seems to crash 3x as often as my cobbled-together-from-spare-parts Windows 10 desktop.
> Otherwise, they simply won't release it at all.
Do you think post-Jobs Apple retains that discipline? I'm not sure.
> Maybe ten years ago I would have believed this, but with each macOS release the litany of unforced errors just continues to grow.
Apple, of all companies, is not a monolith. There are parts of the company who've been just killing it from a software perspective (Swift, SwiftUI, XCode preview for SwiftUI, etc.) Where they've had severe issues has effectively been quality management across the broader OS.
Also, I'll be very interested to watch what happens over the next couple of major release cycles. I think Apple got a major wake-up call with the shitstorm that was the iOS 13 / Catalina release cycle. I'm hoping that they'll be putting in place an outright culture shift to fix that long-term, vs. a one-off "Snow Leopard" tech debt paydown release.
Apple, of all companies, is not a monolith. There are parts of the company who've been just killing it from a software perspective (Swift, SwiftUI, XCode preview for SwiftUI, etc.) Where they've had severe issues has effectively been quality management across the broader OS.
Also, I'll be very interested to watch what happens over the next couple of major release cycles. I think Apple got a major wake-up call with the shitstorm that was the iOS 13 / Catalina release cycle. I'm hoping that they'll be putting in place an outright culture shift to fix that long-term, vs. a one-off "Snow Leopard" tech debt paydown release.
>(Swift, SwiftUI, XCode preview for SwiftUI, etc.)
Time will tell, but right now I think Swift isn't the languages that I once hoped for. And objective-C, despite all of its problem, is still doing well.
Time will tell, but right now I think Swift isn't the languages that I once hoped for. And objective-C, despite all of its problem, is still doing well.
> Not only will the Apple-designed ARM CPUs perform at or above the level of a similarly-specced Intel machine, but the ISA transition will be seamless, with a nearly-invisible Intel binary compatibility layer that does on-the-fly JITing
Apple didn't bother with 32-bit compatibility for Catalina which would have been much easier to implement. You're being way too optimistic. Apple doesn't care about backwards compatibility.
Apple didn't bother with 32-bit compatibility for Catalina which would have been much easier to implement. You're being way too optimistic. Apple doesn't care about backwards compatibility.
I think that might have been to prepare us for ARM. They did the same stuff with the headphone jack : Removed it one iteration sooner than needed, so the new design wouldn't catch flack for missing it.
If the ARM macs can run Intel 64 bit software, but not 32 bit, then removing it in Catalina makes perfect sense
If the ARM macs can run Intel 64 bit software, but not 32 bit, then removing it in Catalina makes perfect sense
Considering that they can't manage to not break foundational libraries in code paths that should require no changes (at least since the introduction of Aqua, with the actual code being used since 1988!) and considering how they broke even 64bit software in Catalina in subtle ways that are still impossible to figure out by developers...
Nah. It won't be seamless at all. It will be like touchbar macs - you buy it because last 3 generations were stuck in place with little improvement and you are forced artificialy to upgrade.
Nah. It won't be seamless at all. It will be like touchbar macs - you buy it because last 3 generations were stuck in place with little improvement and you are forced artificialy to upgrade.
I think this is a little optimistic. Apple doesn’t have the cachet it did ten years ago and their attention to detail on the Mac platform has slipped a hell of a lot. They would probably have an ISA emulation to support x86 apps, but that will likely be deprecated in a couple of years.
They could make an x86 daughterboard for the Mac Pro. Plenty of space for that and it’s been done decades ago. Or a third party could.
I wonder whether they’ve got any special killer apps in mind for the desktop and MacBook ARM machines. They could theoretically customize them greatly since they’re designing the architecture. Also wonder whether they view keeping the unix developer pipeline.
I wonder whether they’ve got any special killer apps in mind for the desktop and MacBook ARM machines. They could theoretically customize them greatly since they’re designing the architecture. Also wonder whether they view keeping the unix developer pipeline.
iOS development and, potentially, better support for Catalyst are the obvious pluses I haven’t seen mentioned yet.
Or graphics algorithms tailored to many cpu cores instead of just gpus. Or have the Mac platform interoperate with their mobiles better, again.
Graphics algorithms for what? Mac is still such a small market share that third party developers won’t take advantage of any weird architectural advantages. Sony tried and failed to pull this off with the PS3’s Cell processor, which was ironically PowerPC-based.
FCP, Adobe, etc. Apple has enough market power, cash, and know how to pull some combos and killer features off.
Battery life
For me, the interesting development right now is the drastic increase of CPU cores. ARM or Intel doesn't matter much except for gaming in Windows.
But of course, Apple does often surprise us all, maybe this could be something cool after all.
But of course, Apple does often surprise us all, maybe this could be something cool after all.
I wonder if we could see more mixed architecture like T2. What would it look like if you had x86 and ARM on board?
Apple won’t do it. There are so many architectural issues with it and you don’t get the power savings of ARM.
People asked the same question during both previous transitions.
People asked the same question during both previous transitions.
Note that Apple is currently doing this.
Saying that Apple will do this because they are using a coprocessor is like saying Apple was going to run Mac software on 65C02 because the IIFx included two 65C02 processors.
But during the PPC transition, you could buy a PPC daughter card for 68040 Macs to run PPC software but you couldn’t use them simultaneously.
But during the PPC transition, you could buy a PPC daughter card for 68040 Macs to run PPC software but you couldn’t use them simultaneously.
Apples biggest debt was developers who rely on vm’s and brew. They’ve already booted them about while producing laptops without a reliable keyboard for 4 years.
ARM macbooks will be for youtube influencers. Sure they’ll be able to edit 8K (and when uploaded to youtube they can’t even view it themselves). Devs need AMD.
ARM macbooks will be for youtube influencers. Sure they’ll be able to edit 8K (and when uploaded to youtube they can’t even view it themselves). Devs need AMD.
Windows and Linux have already run on ARM for quite a while, both are able to run x86 software while doing so (at a penalty). The main holdback has been lack of desktop class ARM CPUs.
I'm still mad about Apple killing 32bit support; I don't have a few extra grand a year to drop on Photoshop. If they drop x86 support, too, I might finally jump ship.
To be honest, I am super unexcited by this. What I want to see from Apple is a move back to high software quality, high hardware quality and real vision for their products. At the moment their convergence between iPad and Macbook has essentially been to add sub-par versions of macbook features to the iPad and to make the macbook a second class citizen in terms of quality.
My big worry is that actually this is just acting as cover for deep underlying issues in a lack of real vision for how the iPad can become a real replacement for laptops and no vision at all for the desktop line. How crazy is it that Apple is pumping out products that re-implement Microsoft features from 5 years ago (after spending 5 years mocking Microsoft).
My big worry is that actually this is just acting as cover for deep underlying issues in a lack of real vision for how the iPad can become a real replacement for laptops and no vision at all for the desktop line. How crazy is it that Apple is pumping out products that re-implement Microsoft features from 5 years ago (after spending 5 years mocking Microsoft).
I owned a surface and I own an iPad Pro now. They aren’t even comparable in usability, Apple is great at refining features and making them work even if Microsoft is better at getting them out earlier. It’s like comparing the iPhone to WinCE.
Apple spent the last 4 years backtracking on features they introduced in 2016:
- Keyboard with more travel - ESC key
Now people are calling the 16" the greatest laptop ever. It's like you've been abused for 4 years, then the abuser does something nice, and you think he/she is the nicest person in the world.
Macbook Pros are still bad:
- Useless touchbar that makes basic functions harder - Resting your palm over an oversized touchpad - Dongle-hell - No battery life improvement in 8 years - Overpriced due to focus on thinness and useless touch bar
They should have taken the 2015 Macbook Pro and gave it a 16" screen, touch ID, newer ports, newer CPUs/GPUs and it would have been 10x better than the overpriced junk we have today.
- Keyboard with more travel - ESC key
Now people are calling the 16" the greatest laptop ever. It's like you've been abused for 4 years, then the abuser does something nice, and you think he/she is the nicest person in the world.
Macbook Pros are still bad:
- Useless touchbar that makes basic functions harder - Resting your palm over an oversized touchpad - Dongle-hell - No battery life improvement in 8 years - Overpriced due to focus on thinness and useless touch bar
They should have taken the 2015 Macbook Pro and gave it a 16" screen, touch ID, newer ports, newer CPUs/GPUs and it would have been 10x better than the overpriced junk we have today.
Yep, the real give away was the A12Z. It isn't shit all faster than the A12X with the exception of the added GPU core.
The A12X was so fast when it came out, reviewers were like "holy shit, this is nearly as fast or faster as comparable x86 laptop," and that was what... two years ago?
Apple's ARM processors are likely _so fucking fast_ that they'd absolutely be showing their hand if they put one in a tablet right now. Reviewers would probably be like "uhh this is faster than a 13" macbook pro and it's a fucking tablet?!" Not to mention, that'd be the nail in the coffin for a good (for Apple) relationship with Intel until they're totally ready to transition.
My guess is Apple is probably just not "quite" there yet for it's highest-end products or we'd see them this year. It's pretty lucky for them their custom silicon to-date has been so far ahead of everyone else or (appearing to be) sitting on their asses for a year or so might hurt.
TSMC is already capable of taking a shit on Intel (Ryzen 3000) and Apple is obviously capable of making very fast custom CPUs. It's a pretty dangerous combo if you're Intel right now and already getting hammered by AMD.
For me, the real question, and pipe dream, will Apple partner with AMD during the transition and perhaps make some some hybrid AMD x86/Apple ARM machines since they're both being built by TSMC?
The A12X was so fast when it came out, reviewers were like "holy shit, this is nearly as fast or faster as comparable x86 laptop," and that was what... two years ago?
Apple's ARM processors are likely _so fucking fast_ that they'd absolutely be showing their hand if they put one in a tablet right now. Reviewers would probably be like "uhh this is faster than a 13" macbook pro and it's a fucking tablet?!" Not to mention, that'd be the nail in the coffin for a good (for Apple) relationship with Intel until they're totally ready to transition.
My guess is Apple is probably just not "quite" there yet for it's highest-end products or we'd see them this year. It's pretty lucky for them their custom silicon to-date has been so far ahead of everyone else or (appearing to be) sitting on their asses for a year or so might hurt.
TSMC is already capable of taking a shit on Intel (Ryzen 3000) and Apple is obviously capable of making very fast custom CPUs. It's a pretty dangerous combo if you're Intel right now and already getting hammered by AMD.
For me, the real question, and pipe dream, will Apple partner with AMD during the transition and perhaps make some some hybrid AMD x86/Apple ARM machines since they're both being built by TSMC?
For me, the real question, and pipe dream, will Apple partner with AMD during the transition and perhaps make some some hybrid AMD x86/Apple ARM machines since they're both being built by TSMC?
There is an interesting thought. Apple could embed one AMD-chiplet with up to 8 cores into their designs, where Apple provides the ARM-CPUs as well as the io-hardware the chiplets require. This would retain the ability to run x86-code, while the system would use the ARM-hardware for most task.
There is an interesting thought. Apple could embed one AMD-chiplet with up to 8 cores into their designs, where Apple provides the ARM-CPUs as well as the io-hardware the chiplets require. This would retain the ability to run x86-code, while the system would use the ARM-hardware for most task.
Always a year away.
I remain deeply sceptical that Apple will move the Mac to ARM, and given their bungling of the MacBook lineup over the last 5 years I have doubts they understand what their users need from a laptop. I don't think they could pull it off without a great deal of pain for their users and developers. I don't think their OS engineers need the burden.
I remain deeply sceptical that Apple will move the Mac to ARM, and given their bungling of the MacBook lineup over the last 5 years I have doubts they understand what their users need from a laptop. I don't think they could pull it off without a great deal of pain for their users and developers. I don't think their OS engineers need the burden.
Not clear that Apple “bungled” the laptops as their sales have been declining roughly in proportion to the sagging of the overall PC market. In other words the flimsy keyboards may have increased their service costs and pissed of a small part of a key constituency but basically may not have itself risen above the noise floor.
For every person who complains about the laptops there’s someone like me who is happy with the direction (doesn’t make either of us wrong). I’m a software developer and miss the portability of my 12” MacBook. I enable telemetry so they know I almost never plug anything into my machine. An iPad just doesn’t cut it.
If this ARM speculation is even substantive it will likely mean a light super-portable machine for me and continued investment in the 16” MBP for you.
For every person who complains about the laptops there’s someone like me who is happy with the direction (doesn’t make either of us wrong). I’m a software developer and miss the portability of my 12” MacBook. I enable telemetry so they know I almost never plug anything into my machine. An iPad just doesn’t cut it.
If this ARM speculation is even substantive it will likely mean a light super-portable machine for me and continued investment in the 16” MBP for you.
given their bungling of the MacBook lineup over the last 5 years
Wouldn't this stand as a reason to not be skeptical of the big move? Switching to ARM (badly) and breaking everything seems like it'd be exactly in line with all of this bungling.
I ordered a new MacBook Air just over a week ago, right when it was announced. If it turns out to be the last Intel-based MBA before years of pain and suffering with the ARM transition then I expect to be hanging on to it for a long time.
Having said all that, Apple is well known for having successfully navigated multiple CPU architecture transitions over the life of their operating system (s). If anyone can do it again successfully, I would expect Apple to do so.
Wouldn't this stand as a reason to not be skeptical of the big move? Switching to ARM (badly) and breaking everything seems like it'd be exactly in line with all of this bungling.
I ordered a new MacBook Air just over a week ago, right when it was announced. If it turns out to be the last Intel-based MBA before years of pain and suffering with the ARM transition then I expect to be hanging on to it for a long time.
Having said all that, Apple is well known for having successfully navigated multiple CPU architecture transitions over the life of their operating system (s). If anyone can do it again successfully, I would expect Apple to do so.
I timed my purchase of my last PowerBook G4 (the last PowerPC-based model) based on similar thinking.
IIRC, It took a while for all the "pro" tools I used to get refreshed for x86.
IIRC, It took a while for all the "pro" tools I used to get refreshed for x86.
They’ll do it on a select model or two. By passing on some of the cost savings to purchasers, they will drag the market along with them as they gradually replace Intel. I would guess that they target the MacBook Air first, because there are likely large power-performance benefits in that form factor. They will build multiple processor targeting into the default build process in Xcode and will invest a great deal of effort and time into ensuring that app developers are well supported with the targeting of ARM.
They did this before with the move to Intel from PPC. And back then, Apple was a great deal smaller.
They did this before with the move to Intel from PPC. And back then, Apple was a great deal smaller.
Or the (currently discontinued) MacBook. The evidence (and logic) suggests that Apple is on a path to reconverge their tablet and at least a portion of their laptop line. Which would be interesting to me if the merged device didn't have too many compromises given that I typically travel with an iPad and some sort of laptop (whether MacBook Pro or Chromebook).
yes, and in addition, the ipad pro is being developed into a viable low- to mid-tier option that's even more mobile (for video, AR/VR, and whatnot). a perusal of geekbench shows that ARM is performance/efficiency competitive already.
but the transition will likely be more gradual (for instance, replacement times for computers are longer now), so x86 macs should stay around for a long while i think.
but the transition will likely be more gradual (for instance, replacement times for computers are longer now), so x86 macs should stay around for a long while i think.
> By passing on some of the cost savings to purchasers
We're talking about Apple here. I expect the new machines to have less perf but be as expensive as before.
We're talking about Apple here. I expect the new machines to have less perf but be as expensive as before.
> I have doubts they understand what their users need from a laptop
Better battery life and less heat, no? Isn't that the point of ARM?
They've done processor transitions multiple times before.
And whatever "bungling" you're talking about, I don't see what that has to do with it. It's not like people have stopped buying MacBooks and Apple has serious remedial stuff to work on first. Besides, whether or not your MacBook has a touchbar or whatever its key travel is has literally nothing to do with what it's doing with processors.
Better battery life and less heat, no? Isn't that the point of ARM?
They've done processor transitions multiple times before.
And whatever "bungling" you're talking about, I don't see what that has to do with it. It's not like people have stopped buying MacBooks and Apple has serious remedial stuff to work on first. Besides, whether or not your MacBook has a touchbar or whatever its key travel is has literally nothing to do with what it's doing with processors.
> Always a year away.
Citation needed. We’re not talking about Year of the Linux Desktop here.
I’ve been hearing rumblings and speculations about ARM Macs since at least five years ago, but IFAICR never heard a concrete timeline attached to it, let alone “a year away”. And 2021 would be fairly consistent with speculations.
Citation needed. We’re not talking about Year of the Linux Desktop here.
I’ve been hearing rumblings and speculations about ARM Macs since at least five years ago, but IFAICR never heard a concrete timeline attached to it, let alone “a year away”. And 2021 would be fairly consistent with speculations.
e.g., "Intel reportedly expects Apple to start the Mac’s transition to ARM next year" -- Feb 2019
https://9to5mac.com/2019/02/21/mac-marzipan-arm-next-year-ma...
https://9to5mac.com/2019/02/21/mac-marzipan-arm-next-year-ma...
Are you sure? It seemed to be consistent theme of Apple rumours since I think ~2012, until grumbling about shit quality overtook it from 2015 onwards, but it never disappeared. The timeline was not so stated, but it usually boiled to "it will be the one more thing and next WWDC".
[deleted]
Kou wouldn't be able to use data from the supply chain to know what software is running on future hardware. If Apple is releasing ARM based desktops its more likely they'll be iOS derived devices to meet new niches. Something that competes with the large Wacoms would need to be more easel like than the current iMacs.
This is nothing new, just the latest rehashing of the same rumor that's been recirculating for months.
yeah, I was looking for something more than a single analyst's note here.
Get ready to not have root access on your laptop. The writing is on the wall:
* signed software restrictions
* no kernel extensions
* SIP
There's no evidence for this. They could remove root access now on x86 if they wanted to. They didn't have to spend engineering hours making it possible to disable SIP when they turned it on. Most software signature restrictions that have been added to macOS to date are easily disabled, and besides that have nothing to do with x86 vs ARM.
I wonder if they'll use that as an excuse for complete lockdown of macOS and only allow AppStore reviewed software.
They can't do this unless they are okay with never selling machines again to anyone who needs to write code. There's no feasible way for all programming tools to be distributed through MAS. IPython isn't going to suddenly go through the marathon of crap you need to get into the store.
If absolutely nothing else, native developers: you can't have more than one version of a MAS app installed. Nearly every iOS developer I know has at least two versions of Xcode at any given time.
If absolutely nothing else, native developers: you can't have more than one version of a MAS app installed. Nearly every iOS developer I know has at least two versions of Xcode at any given time.
That’s not true. Many people write code on Mac despite kernel extensions being disabled and SIP. What will be considered root will be a superficial emulation convincing enough to fool most Unix software
I doubt that Apple will completely lock down MacOS. However, for corporate machines, the presence of Apple-controlled hardware will enable more comprehensive control of the endpoint, which is arguably good for security.
Apple story on corporate support is infamously bad, and they don't appear interested in supporting buyer ownership of machines, unlike Microsoft (which requires it from the high end certifications).
I think it's likely.
They may provide sandboxes for development, some kind of WSL (Windows Subsystem for Linux) or Docker on Mac, and a "Classic" emulator for apps that haven't been recompiled like they did for the transition between Mac os 9 and Mac os X, and from PowerPC to x86.
Meanwhile they will continue to limit web apps.
They may provide sandboxes for development, some kind of WSL (Windows Subsystem for Linux) or Docker on Mac, and a "Classic" emulator for apps that haven't been recompiled like they did for the transition between Mac os 9 and Mac os X, and from PowerPC to x86.
Meanwhile they will continue to limit web apps.
Probably. That's what happened with the surface RT tablet a few years ago.
I'm curious what Parallels going to do. Running Windows and Linux applications with almost native integration into OSX ecosystem worth a lot, especially with all benefits of hardware virtualization. In theory PC could be virtualized on ARM, however software virtualization only.
Going to watch the process. In general, Windows and Linux support ARM as well, not sure if hardware virtualization for ARM exist though
Maybe backend developers for Intel Linux servers will fire up a VM on AWS/Azure/Google and work there.
There will be some cross platform compatibility issues. Interpreted languages hide the CPU (think Python, Ruby, Node) but their extensions in C could need some extra work that not all of them require now.
On the other side there will be the rise of the ARM servers. Apple is notoriously not interested in running server farms for their customers but I expect that the big cloud providers will start offering ARM servers.
It could be the x86 developers to have to fire up an ARM VM on the cloud to be able to work in ARM Macs heavy teams.
There will be some cross platform compatibility issues. Interpreted languages hide the CPU (think Python, Ruby, Node) but their extensions in C could need some extra work that not all of them require now.
On the other side there will be the rise of the ARM servers. Apple is notoriously not interested in running server farms for their customers but I expect that the big cloud providers will start offering ARM servers.
It could be the x86 developers to have to fire up an ARM VM on the cloud to be able to work in ARM Macs heavy teams.
Packages with native dependencies already require a recompile to run between Windows and Linux. Right now, I write Python scripts on a Windows laptop, push the changes and the build server (well actually a Linux Docker container using AWS CodeBuild) builds and deploys the package to Linux servers.
Apple already has an x86 build chain that cross compiled to ARM.
Apple already has an x86 build chain that cross compiled to ARM.
> not sure if hardware virtualization for ARM exist though
Virtualization extensions have been available since the Cortex A15 or thereabouts.
Linux supports normal KVM on both ARM32 and ARM64 although there are mutterings about dropping support for ARM32.
In practice, the hypervisor is usually already grabbed by the platform (e.g. on Android/Snapdragon it's taken by the TrustZone driver and can't be used yourself, even if you rebuild the kernel with CONFIG_KVM).
Virtualization extensions have been available since the Cortex A15 or thereabouts.
Linux supports normal KVM on both ARM32 and ARM64 although there are mutterings about dropping support for ARM32.
In practice, the hypervisor is usually already grabbed by the platform (e.g. on Android/Snapdragon it's taken by the TrustZone driver and can't be used yourself, even if you rebuild the kernel with CONFIG_KVM).
Interesting info, thanks. I also missed the point that Apple is going to design new CPU, they are definitely able to add any hardware virtualization instructions
Why wouldn’t they be able to provide on-chip x86 emulation, exposed via hypervisor Framework?
They can use that for backward compatibility for non-recompiled apps while supporting parallels/VMware
Also, the move to Catalina helps to check how fast app developers and users switch to new hardware.
Also, the move to Catalina helps to check how fast app developers and users switch to new hardware.
Apple doesn’t have chips that support it, yet.
I'd be completely fine with a switch to ARM, as long as it was handled in the same way that the switch to x86 was done - with a period of fat binaries targeting both architectures, and then a gradual phase-out of the older architecture (x86).
I'm pretty sure Apple have the ability to put 32-core ARM systems into the MacBook, and push the power/processing ratio into the stratosphere. The only reason I'm not using ARM right now, personally, is because such a thing doesn't really exist .. but I look at my old Touchbook up on the shelf and wonder what could have been...
I'm pretty sure Apple have the ability to put 32-core ARM systems into the MacBook, and push the power/processing ratio into the stratosphere. The only reason I'm not using ARM right now, personally, is because such a thing doesn't really exist .. but I look at my old Touchbook up on the shelf and wonder what could have been...
Other than Linux distros, almost every home OS on ARM is a locked-down anti-consumer mess. Android, Windows RT, iOS, Windows X, Chrome OS. I'm hoping MacOS doesn't follow them down that road of locked bootloaders and anti-root restrictions.
The question is as users should we care? If this is cheaper for Apple will they actually lower product prices or just enhance their own margins. Will this result in any superior performance on a cost-adjusted basis?
Of course, we should care. We are talking about losing the standard x86 platform support (which allows for Windows/Linux support if not total OOB support) to a custom Apple platform that may be more locked down to the point that Linux may not even care to add any support for it (T2-Macs have been difficult to add support in Linux). This drops the value a lot if you're not an exclusive macOS user.
1. We don't know what impact this will have for Bootcamp and Windows, since Windows 10 on ARM right now is customized for specific ARM CPUs like Snapdragon.
2. Same for virtualization, we don't know the performance hit it is going to have. A lot of people still need to use Windows for specific software that is not available on Windows or macOS where 32-bit support can be retained with older macOS releases.
3. Going the other direction, ARM means we could also see easier porting of iOS apps to macOS via Catalyst with more consistent APIs. But that could also mean less focus on macOS overall and everyone switching to iOS to port to macOS rather than working on two separate versions. This has both pros and cons and we won't know the full extent until a few years later.
1. We don't know what impact this will have for Bootcamp and Windows, since Windows 10 on ARM right now is customized for specific ARM CPUs like Snapdragon.
2. Same for virtualization, we don't know the performance hit it is going to have. A lot of people still need to use Windows for specific software that is not available on Windows or macOS where 32-bit support can be retained with older macOS releases.
3. Going the other direction, ARM means we could also see easier porting of iOS apps to macOS via Catalyst with more consistent APIs. But that could also mean less focus on macOS overall and everyone switching to iOS to port to macOS rather than working on two separate versions. This has both pros and cons and we won't know the full extent until a few years later.
Porting iOS to Macs don’t require ARM. Almost every iOS app started life running on x86. The iOS simulator runs iOS software compiled for x86 linked to x86 versions of the iOS framework.
I didn't say it does, I'm just saying that it'll be easier. Instead of working on both x86/ARM frameworks, they'll just stop supporting x86 (freeze) and only update on the ARM framework from now on.
They did the same thing with PowerPC and x86-32. No reason to expect them to support x86-64 in 5-10 years if they switch all Macs to ARM.
They did the same thing with PowerPC and x86-32. No reason to expect them to support x86-64 in 5-10 years if they switch all Macs to ARM.
Since Apple effectively stopped innovating OSX a decade ago (unless you really need each new iteration of emojis) just get a Windows machine if Windows software is essential to your workflow. I have used macs a long time but got a supplemental Windows machine for my office to not bother with fiddly virtualization issues. Windows has largely caught up with OSX as OSX has stagnated or outright decayed.
It makes me sad to say that given the Apple fanboy I once was but reality is reality.
It makes me sad to say that given the Apple fanboy I once was but reality is reality.
I already have Windows PCs (SP4 + Desktop)and while W10 has come a long way, it's not as stable as macOS. Catalina is just as bad as Vista IMO.
However, macOS is still better IMO because I still have a lot of issues on Windows; all stemming from MS shipping bad updates. Two months ago, a Windows update broke my bluetooth completely and I had to wait a month for another Windows update/driver to fix it. Last year, a bad update forced me to reinstall Windows because it was freezing all the time and I couldn't restore a system point either.
As for macOS, I never had to do a reinstall (except one time that was entirely my fault) in more than a decade. W7/W10, I had to do it 5 or so times in last few years. Catalina however lost my respect for macOS, that was the worst update of all time.
However, macOS is still better IMO because I still have a lot of issues on Windows; all stemming from MS shipping bad updates. Two months ago, a Windows update broke my bluetooth completely and I had to wait a month for another Windows update/driver to fix it. Last year, a bad update forced me to reinstall Windows because it was freezing all the time and I couldn't restore a system point either.
As for macOS, I never had to do a reinstall (except one time that was entirely my fault) in more than a decade. W7/W10, I had to do it 5 or so times in last few years. Catalina however lost my respect for macOS, that was the worst update of all time.
I have 4 machines running Windows 10 from its release and never had to reinstall the OS. Everything is stable and I hardly reboot.
Most development tools have Windows versions: Node, NPM, Git, Docker. If I'd encounter one which doesn't run ob Windows, there's WSL.
I pretty much disliked Windows XP, Vista and preferred Linux, but since Windows 7,the OS got a lot better from my point of view.
I have the largest possible software library and the added possibility to run *NIX tools when needed.
I don't need to fiddle with Linux desktop or pay 3x the price for Apple branded hardawe which you can't even maintain or extend yourself. I can use cheap chargers, perriferals and I can connect almost any device to my desktops or laptops.
Most development tools have Windows versions: Node, NPM, Git, Docker. If I'd encounter one which doesn't run ob Windows, there's WSL.
I pretty much disliked Windows XP, Vista and preferred Linux, but since Windows 7,the OS got a lot better from my point of view.
I have the largest possible software library and the added possibility to run *NIX tools when needed.
I don't need to fiddle with Linux desktop or pay 3x the price for Apple branded hardawe which you can't even maintain or extend yourself. I can use cheap chargers, perriferals and I can connect almost any device to my desktops or laptops.
Agreed, VSCode is my favorite text editor, WSL2 looks to be awesome (I'm waiting for VMware to use it since VMware is required for my job), Github, WinUI looks awesome, etc.
Windows is slowly becoming a very developer friendly platform. Will it work out for Microsoft? Who knows.
I'm more excited for Microsoft than Apple at this point but I am looking forward to seeing iPadOS/macOS later this year.
Windows is slowly becoming a very developer friendly platform. Will it work out for Microsoft? Who knows.
I'm more excited for Microsoft than Apple at this point but I am looking forward to seeing iPadOS/macOS later this year.
Apple's gains in chip performance are incredible and I would prefer to have an alternative to Intel. If I can get better performance and they keep the price the same, I care.
Users that run VM's because they need to run OSX and Win10, etc most definitely care.
Also, in the pro audio sector it's common for people to spend quite a bit more than the cost of the Mac on Intel-specific DAW plugins.
Citation/example?
Heh, well the list price for Waves Horizon bundle is $3,999 and that's one vendor...
A lot of the plugins those users acquire over time are produced by individual devs or small Indy shops, who may not be around any more or inclined to develop Arm versions of older products. You'll find threads on gearslutz.com where some people aren't upgrading to Catalina because 32-bit plugins aren't supported any more.
A lot of the plugins those users acquire over time are produced by individual devs or small Indy shops, who may not be around any more or inclined to develop Arm versions of older products. You'll find threads on gearslutz.com where some people aren't upgrading to Catalina because 32-bit plugins aren't supported any more.
I was referring to the "Intel-specific" part of your comment, not the price. I'm a professional composer and haven't ever come across an Intel-specific plugin -- loads of people use AMD. I think what you meant is x86-specific, but as other people have pointed out in this thread and others, it's expected that Apple will provide the ability to simply recompile for ARM. No big deal.
for ARM, power per watt. It's always been the advantage.
Controlling the stack w/ better vertical integration as well will probably yield more coherent product design. You can tell re how "put-together" a product an iPad or iPhone is vs. a Mac these days.
While maybe not yielding direct customer, user-facing benefits, the under-the-hood benefits would definitely improve customer experience.
Controlling the stack w/ better vertical integration as well will probably yield more coherent product design. You can tell re how "put-together" a product an iPad or iPhone is vs. a Mac these days.
While maybe not yielding direct customer, user-facing benefits, the under-the-hood benefits would definitely improve customer experience.
>If this is cheaper for Apple will they actually lower product prices or just enhance their own margins.
If this would happen, most definitely the improvement on margins. Why would they lower prices?
If this would happen, most definitely the improvement on margins. Why would they lower prices?
We have an existence proof. The iPads are already a better value when you compare price/performance.
Even the low end $329 iPad can hold its own performance wise to low and midrange laptops. The high end iPad Pros are cheaper and faster than lowend and midrange laptops.
Even the low end $329 iPad can hold its own performance wise to low and midrange laptops. The high end iPad Pros are cheaper and faster than lowend and midrange laptops.
Are you suggesting that Apple laptops are too expensive for what they're worth?
How is moving Macs to Arm going to improve this?
How is moving Macs to Arm going to improve this?
In a capitalist society, something is worth what enough people are willing to pay for it.
Apple pays much more for a Intel chips than its own ARM chips.
Again, you can look at the price/performance of iPads compared to laptop Macs.
Apple pays much more for a Intel chips than its own ARM chips.
Again, you can look at the price/performance of iPads compared to laptop Macs.
This is Apple. Unless there is a major downside, they will keep the same prices or increase it.
Apple would love more lock in and transforming Macs into giant iPhones with app store only apps.
However, breaking compatibility with Windows and Linux would be a terrible idea. People would flee to other platforms leaving Mac for those who are already locked in, like iOS developers.
People care most about running their software to do their work, than what os they use.
However, breaking compatibility with Windows and Linux would be a terrible idea. People would flee to other platforms leaving Mac for those who are already locked in, like iOS developers.
People care most about running their software to do their work, than what os they use.
Is it really going to be a MacBook - or a laptop form for the iPad Pro?
What does this mean for software companies whose consumer base is largely on OSX? Will Adobe, Sony, Avid, etc have to port their library of software over to Apple's new ARM architecture?
Will this allow for greater freedom with ARM devices not running new OSX?
It seems like Apple lately has very much internalized 'if you build it, they will come' even though it seems like it is heavily alienating their professional user base.
Will this allow for greater freedom with ARM devices not running new OSX?
It seems like Apple lately has very much internalized 'if you build it, they will come' even though it seems like it is heavily alienating their professional user base.
One would hope that after making both of the previous Mac CPU migrations, Adobe has all the CPU-specific stuff in their codebases well-charted, and is already playing with beta hardw— no what am I saying, I’ve been using Adobe stuff for twenty years now and they’ve only gotten less nimble over time, I don’t expect to even see a build for the beta test program until at least a year and a half after ARM Macs are on the market.
Maybe I’ll get an Arm Air in ‘22. My 2017 Pro should still be viable until then for what I do.
Maybe I’ll get an Arm Air in ‘22. My 2017 Pro should still be viable until then for what I do.
You act as if this is the first time that Apple has done a transition or the first time that the aforementioned companies have made the transition.
Each of them have made the transition from 68K -> PPC -> OS X -> x86.
Each of them have made the transition from 68K -> PPC -> OS X -> x86.
I only know about the transition to x86 and from what I remember the benefit was the same architecture as Windows. Since them OSX has gained a lot of market share. Moving to ARM is definitely a step backwards in that regard. I don't know anything about the previous transitions.
I don't think transitioning to ARM is a bad choice given the benefits, but a lot of serious (and casual) users are going to be very unhappy their programs aren't going to work after dropping $1k+ on a new computer.
I don't think transitioning to ARM is a bad choice given the benefits, but a lot of serious (and casual) users are going to be very unhappy their programs aren't going to work after dropping $1k+ on a new computer.
The Mac was already on an upward trajectory before the x86 transition. OS X hasn’t really gained that much marketshare. Besides the “beleaguered years”, Macs have historically trended at around 10% market share. They actually had more marketshare in the early 90s before Windows 95.
Apple has done this three times if you include the Apple //e transition. Each time they brought customer’s along.
The first transition from 68K to PPC, almost all of their revenue came from Macs. The second time about half (the other half was iPods). Now it’s less than 10%. It’s much less risky this time.
Apple has done this three times if you include the Apple //e transition. Each time they brought customer’s along.
The first transition from 68K to PPC, almost all of their revenue came from Macs. The second time about half (the other half was iPods). Now it’s less than 10%. It’s much less risky this time.
I doubt Adobe's largest consumer base is on macOS. Of course Adobe and any other software maker won't be happy, but if it's worth it, they'll target macOS on ARM. Some software companies might decide it isn't worth the hassle.
I'm wondering if they'll have some solution similar to Rosetta
Is the switch to ARM going to be for cost savings, or are the chips actually faster than current Intel?
That's Geekbench. The differences in Geekbench for ARM devices and Geekbench for x86 are laughable. Why not compare them in a real life workload like a render on Blender or a kernel compile?
People have (Jonathan Morrison for an example) , the 4k exports from iMovie or other video/image editor has been proven to be vastly faster on iPad Pro than the fastest Macbook Pro.
Intel CPUs are not customized by Apple for their own APIs, they're for general purpose use. yes, they have ISA extensions that Apple could use like QuickSync but it's not enough for Apple.
Apple customize their A series with the same APIs they use, such as Metal, CoreFoundation, Javascript Core (they have hardware-based JS acceleration support), etc.
It's why they added T2 chips to their Macs to help accelerate a lot of tasks like disk encryption, more locked down security with TouchID and so on.
Intel CPUs are not customized by Apple for their own APIs, they're for general purpose use. yes, they have ISA extensions that Apple could use like QuickSync but it's not enough for Apple.
Apple customize their A series with the same APIs they use, such as Metal, CoreFoundation, Javascript Core (they have hardware-based JS acceleration support), etc.
It's why they added T2 chips to their Macs to help accelerate a lot of tasks like disk encryption, more locked down security with TouchID and so on.
All of these tasks are "accelerated" by skimping on quality or using silicon dedicated to a specific program. It doesn't matter in real life unless literally the only thing you do is use a browser and nothing else, and even then only JS, not wasm. In which case, I don't know why you would even have a CPU with more than two cores, and an i3 would be more than enough anyways. JS acceleration really only matters if you want to maximize battery life and the only thing you're doing with your computer is contained in a traditional webview. That is to say, it matters little for laptops, as they already have 7-8 hour battery life, and literally not at all for desktops.
So, for example, my computer can encode 4 4K videos in real time simultaneously. Why don't I use this feature? Because the encode quality is subpar. So unless you give me a benchmark of the iPad Pro on ffmpeg or any other open source, non-hardware accelerated video encode software, comparison is completely moot. And the benchmarks that have been done on ffmpeg on x265 or x264 show that the iPad Pro is multiple times slower than an Intel laptop. Now obviously x265 is optimized for x86, but not on the order of multiple times slower. Unless it is the case, and that means that your benchmarks don't apply either.
Herein lies the issue, for many many workloads hardware acceleration while faster offers results that are not comparable to the CPU in terms of quality. So the only way to compare is by disabling hardware acceleration, and x86 processors tend to win.
Metal is a trash API that no one uses in the real world. It offers literally nothing better than Vulkan. And the fact that the chip is "customized for the API" is vacuous. All GPUs are optimized for OpenGL, DirectX or Vulkan. Same for a lot of the "Core" APIs. They will not succeed outside of the mobile market.
The T2 chip is simply a glorified security processor. There is absolutely nothing the T2 chip does that a traditional security processor in say a Zen chip can't do. x86 CPUs can already do AES at speeds so high you would need something like 4 RAID-0 NVMe SSDs to have a performance bottleneck, and even then the limitation isn't the CPU but RAM speed. There is no real world scenario where you would need to "accelerate" disk encryption or other kinds of cryptography beyond what an x86 CPU can do. Cryptography isn't some kind of magic you can't implement without some specialized chip, literally everything the T2 chip does can be done using a trusty old x86 processor and TPM. The only use of the T2 chip is for Apple to have more control over your hardware, and literally nothing else.
So, for example, my computer can encode 4 4K videos in real time simultaneously. Why don't I use this feature? Because the encode quality is subpar. So unless you give me a benchmark of the iPad Pro on ffmpeg or any other open source, non-hardware accelerated video encode software, comparison is completely moot. And the benchmarks that have been done on ffmpeg on x265 or x264 show that the iPad Pro is multiple times slower than an Intel laptop. Now obviously x265 is optimized for x86, but not on the order of multiple times slower. Unless it is the case, and that means that your benchmarks don't apply either.
Herein lies the issue, for many many workloads hardware acceleration while faster offers results that are not comparable to the CPU in terms of quality. So the only way to compare is by disabling hardware acceleration, and x86 processors tend to win.
Metal is a trash API that no one uses in the real world. It offers literally nothing better than Vulkan. And the fact that the chip is "customized for the API" is vacuous. All GPUs are optimized for OpenGL, DirectX or Vulkan. Same for a lot of the "Core" APIs. They will not succeed outside of the mobile market.
The T2 chip is simply a glorified security processor. There is absolutely nothing the T2 chip does that a traditional security processor in say a Zen chip can't do. x86 CPUs can already do AES at speeds so high you would need something like 4 RAID-0 NVMe SSDs to have a performance bottleneck, and even then the limitation isn't the CPU but RAM speed. There is no real world scenario where you would need to "accelerate" disk encryption or other kinds of cryptography beyond what an x86 CPU can do. Cryptography isn't some kind of magic you can't implement without some specialized chip, literally everything the T2 chip does can be done using a trusty old x86 processor and TPM. The only use of the T2 chip is for Apple to have more control over your hardware, and literally nothing else.
> the 4k exports from iMovie or other video/image editor has been proven to be vastly faster on iPad Pro than the fastest Macbook Pro.
I'd only be impressed if both used the exact same high-quality software encoder. Most likely the iPad uses the fast but less quality dedicated hardware encoder of the A-Series SoC and the MacBook uses a high quality but slow software-only one, which is what you typically use in any non-real-time encoding scenario due to way better bitrate-to-quality ratios.
> Javascript Core (they have hardware-based JS acceleration support)
Do you have a credible source for this? AFAIK JS VMs have gotten to the same place that Java VMs (for which some people also envisioned dedicated silicon a long time ago, but it was a dud) reached: so frickin fast on standard x86 ISA that putting any special instructions for them into the ISA isn't worth it, because it's more important to stay flexible to be able to adapt future extensions of ECMAScript.
> It's why they added T2 chips to their Macs to help accelerate a lot of tasks like disk encryption, more locked down security with TouchID
That has more to do with having a secure element under Apple's control in the T2 chip and nothing with performance. Any modern x86 CPU can do accelerated AES just as fast as any ARM with hardware crypto support.
I'd only be impressed if both used the exact same high-quality software encoder. Most likely the iPad uses the fast but less quality dedicated hardware encoder of the A-Series SoC and the MacBook uses a high quality but slow software-only one, which is what you typically use in any non-real-time encoding scenario due to way better bitrate-to-quality ratios.
> Javascript Core (they have hardware-based JS acceleration support)
Do you have a credible source for this? AFAIK JS VMs have gotten to the same place that Java VMs (for which some people also envisioned dedicated silicon a long time ago, but it was a dud) reached: so frickin fast on standard x86 ISA that putting any special instructions for them into the ISA isn't worth it, because it's more important to stay flexible to be able to adapt future extensions of ECMAScript.
> It's why they added T2 chips to their Macs to help accelerate a lot of tasks like disk encryption, more locked down security with TouchID
That has more to do with having a secure element under Apple's control in the T2 chip and nothing with performance. Any modern x86 CPU can do accelerated AES just as fast as any ARM with hardware crypto support.
That is true, I don't have any evidence to say that x86 isn't faster or equal against Apple's ARM CPUs or vis versa. They're hard to come by since they're both completely different arch.
For JS: https://twitter.com/codinghorror/status/1049082262854094848
It looks like it's not exclusive to Apple's CPU, it's the specific instruction features in ARM 8.3 ISA that makes JS faster.
Added here: https://bugs.webkit.org/show_bug.cgi?id=184023
> Any modern x86 CPU can do accelerated AES just as fast as any ARM with hardware crypto support.
Right but back then, Intel mobile chips weren't that fast. I had MBP with Filevault that took a massive hit and I had to turn it off to get back disk performance. I can't prove that T2 is the reason the encryption doesn't take any hit on T2 Macs, all I can see from my trial of rMBP 16, there was zero performance hit with it on or off.
For JS: https://twitter.com/codinghorror/status/1049082262854094848
It looks like it's not exclusive to Apple's CPU, it's the specific instruction features in ARM 8.3 ISA that makes JS faster.
Added here: https://bugs.webkit.org/show_bug.cgi?id=184023
> Any modern x86 CPU can do accelerated AES just as fast as any ARM with hardware crypto support.
Right but back then, Intel mobile chips weren't that fast. I had MBP with Filevault that took a massive hit and I had to turn it off to get back disk performance. I can't prove that T2 is the reason the encryption doesn't take any hit on T2 Macs, all I can see from my trial of rMBP 16, there was zero performance hit with it on or off.
Thanks for the JS link, I didn't know about that. Though I would hardly call that "Javascript acceleration in hardware". They added a slightly weird float-to-int conversion command that handles overflows a bit different than the normal command, and for lack of better names (and probably because no one else is expected to require that quirky command) they put a "Javascript" into its name.
The perf hit with Filevault became practically zero when Intel added the AES encryption hardware into its chips, which was quite a while ago (and definitely long before the T2 was a thing). I don't remember exactly when that was, but I remember noticing a considerable difference, because I've used FDE since it became available in Filevault. It wasn't even on Macs only, my Windows machines also showed the same improvements using (IIRC) TrueCrypt back in the days.
The dedicated AES hardware extensions in ARM and x86 cores are probably the same logic anyway, so it shouldn't matter too much who decrypts the data. Maybe it's a tiny bit faster with the T2 though, because then the CPU doesn't necessarily have to pipe all the data through it's buses for decryption then. But that is more or less a feature of having a dedicated separate chip for it, and is thus not tied to the question of whether that chip uses ARM or x86 or any other ISA.
The perf hit with Filevault became practically zero when Intel added the AES encryption hardware into its chips, which was quite a while ago (and definitely long before the T2 was a thing). I don't remember exactly when that was, but I remember noticing a considerable difference, because I've used FDE since it became available in Filevault. It wasn't even on Macs only, my Windows machines also showed the same improvements using (IIRC) TrueCrypt back in the days.
The dedicated AES hardware extensions in ARM and x86 cores are probably the same logic anyway, so it shouldn't matter too much who decrypts the data. Maybe it's a tiny bit faster with the T2 though, because then the CPU doesn't necessarily have to pipe all the data through it's buses for decryption then. But that is more or less a feature of having a dedicated separate chip for it, and is thus not tied to the question of whether that chip uses ARM or x86 or any other ISA.
>The dedicated AES hardware extensions in ARM and x86 cores are probably the same logic anyway, so it shouldn't matter too much who decrypts the data. Maybe it's a tiny bit faster with the T2 though, because then the CPU doesn't necessarily have to pipe all the data through it's buses for decryption then. But that is more or less a feature of having a dedicated separate chip for it, and is thus not tied to the question of whether that chip uses ARM or x86 or any other ISA.
I don't really see how that would help, CPU i/o has to handle the exact same amount of incoming data encryption or not. Maybe a bit less RAM impact though.
I don't really see how that would help, CPU i/o has to handle the exact same amount of incoming data encryption or not. Maybe a bit less RAM impact though.
My thought was this: If the CPU decrypts, it touches every byte being read to RAM, and it touches the data again later when it does actual work on it. If it doesn't decrypt, but a chip next to the NAND does the job, the CPU can DMA-transfer the data directly from that chip to RAM. The first time the CPU touches the data is when it actually does some real work on it.
True, but my thought was that since AES decryption is mostly limited by RAM bandwidth anyways, the transfer from the SSD to the CPU, then from the CPU to the T2 chip, then from the T2 chip to the CPU won't be much faster than transferring from the SSD into the RAM, then decryption, then it being read back into the RAM.
AFAIK the T2 is also the SSD controller in Apple's architecture, meaning it speaks directly to the NAND. So it should not be necessary for data to first go to the CPU, then to the T2 for decryption - the T2 can transparently decrypt and encrypt while doing the job of offering block-device-level access to the flash chips.
I mean, that might depend on the type of encryption used by your computer but there is a ton of documentation about full disk encryption in the Linux world and for over a decade there is almost no performance hit. My experience with a 2008 MBP running Debian was that disk encryption on or off had a very small performance hit.
I’d love to read your results rendering something in Blender on the latest A13 chip, if that’s the best way to make a comparison.
I'd love to make such a benchmark, but I won't because I don't have enough money to justify buying a Mac. If you send me one I'll port the rendering engine over and do the benchmark, though.
How is running the same code in two different machines and reporting the results objectively "laughable"?
Because the way the code is compiled or hand optimized even, which kind of extensions are used for ARM vs x86 (SSE, AVX and so on). Many of the worloads used in Geekbench are straight up directly accelerated, which is fine if the only thing that's requiring CPU power on your machine is Javascript, but not so otherwise.
Other synthetic benchmarks of memory bandwidth and so on use all acceleration features of the plafortm on ARM but don't support AVX2 or AVX512, although some other workloads in the benchmark do. And of course you would have to choose exactly which instruction is used in which scenario in which processor(Intel vs Zen 1 vs Zen 2) in order to have the same kind of optimization as for ARM processors. Then comes the issue that vector operations are "hand-tuned", which is not realistic and depending on the skill of the programmer and their affinity with a given uArch can yield vastly different results. Which is why they should either use the fastest library for each processor, or leave all the optimization to the compiler.
The only way to do a proper comparison between two uArch is with an open source benchmark compiled specifically for the processor.
Other synthetic benchmarks of memory bandwidth and so on use all acceleration features of the plafortm on ARM but don't support AVX2 or AVX512, although some other workloads in the benchmark do. And of course you would have to choose exactly which instruction is used in which scenario in which processor(Intel vs Zen 1 vs Zen 2) in order to have the same kind of optimization as for ARM processors. Then comes the issue that vector operations are "hand-tuned", which is not realistic and depending on the skill of the programmer and their affinity with a given uArch can yield vastly different results. Which is why they should either use the fastest library for each processor, or leave all the optimization to the compiler.
The only way to do a proper comparison between two uArch is with an open source benchmark compiled specifically for the processor.
Until they offer pro-level repair service they shouldn't be considered a "pro" machine.
That means next-day onsite repairs. Not 3-5 days at a distant location, leaving the user without their computer.
That means next-day onsite repairs. Not 3-5 days at a distant location, leaving the user without their computer.
You're thinking enterprise.
Shouldn't the first models to use ARM be desktop? Allow the early adopters to kick the tires. So that devs can make sure their wares work on ARM before the mass market models switch?
The only reason I could come to care about architecture, as a consumer, is if it provides a freakishly long battery life.
Does anyone have a rough figure for what fraction of the power load on a macbook is going to the CPU? In other words, what's the limit in battery life for a laptop whose CPU consumes no power at all, but still has to power the display, refresh RAM, etc?
Do Apple even care about their PC business? They basically let it rot.
Still hoping for a 13/14 inch intel macbook refresh with the revamped keyboard before too long.
Or I was, now that I work from home all the time my need for a laptop is much reduced.
Or I was, now that I work from home all the time my need for a laptop is much reduced.
On the other side, such a transition always is painfull. A lot of software needs to be rebuilt, and even more legacy software gets killed, as it is not ported to the new platform. Though Catalina already did a lot of that, and that might not be a coincidence, if you think about it. Catalina might be intentionally restrictive to ease the transition to another architecture.
Also, a lot of Mac users are running VMs on their machines. Running Windows and Linux VMs on your Mac was one big benefit of the switch to Intel. I myself use a Linux VM for my professional work on a MB Pro. And that VM needs to be able to run x86 software. So it remains to be seen, how Apple deals with the MB Pro (and of course the Mac Pro).