Begun, the instruction set wars have. Granted, it's Bloomberg which has a spotty record on tech coverage. But if true, Bootcampers and Mac gamers are BTFO. Shadow and GeForceNow can't come out a...
Begun, the instruction set wars have.
Granted, it's Bloomberg which has a spotty record on tech coverage. But if true, Bootcampers and Mac gamers are BTFO. Shadow and GeForceNow can't come out a moment too soon.
Given that Windows 10 runs just fine on ARM64, Apple might still include Boot Camp support. The hard part is that very little of the Windows ecosystem can run without Microsoft's x64 emulation...
Given that Windows 10 runs just fine on ARM64, Apple might still include Boot Camp support. The hard part is that very little of the Windows ecosystem can run without Microsoft's x64 emulation layer, meaning that a lot of third-party applications are slow. Unlike Microsoft, Apple has the power to force developers to adapt to changes in macOS and Mac hardware.
I don't know how Apple's EFI would work on their ARM laptops, so Linux support would be iffy at first. But ARM is clearly the direction that many laptop manufacturers are going in, so I expect that the support will eventually be there.
I just realized that this is my main gripe, I never figured Windows 10 might just run on ARM chips but why not? What does it mean for general backwards-compatibility, though? Nothing made for...
Given that Windows 10 runs just fine on ARM64, Apple might still include Boot Camp support.
I just realized that this is my main gripe, I never figured Windows 10 might just run on ARM chips but why not?
What does it mean for general backwards-compatibility, though? Nothing made for current Intel MacBooks would run on ARM machines?
Developers would need to recompile their binaries—for apps on the Mac App Store, my bet is they're already implicitly compatible with ARM Macs because of Apple's restrictions around API usage on...
Developers would need to recompile their binaries—for apps on the Mac App Store, my bet is they're already implicitly compatible with ARM Macs because of Apple's restrictions around API usage on macOS. Apple may even be able to automatically recompile from "day one".
Developers shouldn't have any problems™ provided they're using publicly surfaced macOS APIs. Apple can provide a translation layer at that level to ensure instruction compatibility with both x86 and ARM. The hard part is developers who utilise private APIs. This includes most big names like Microsoft and Adobe, which unfortunately, have an outsized influence on the adoption and value of macOS hardware.
I can't find it straight off the bat, but there's a good article documenting how Apple has actually modified their own APIs for Microsoft, Adobe, and many other big companies, to ensure "bugs" don't appear in those companies' own programs which abuse the system APIs in unexpected ways. It's a good read.
Genuine question: Wouldn't it be possible for Apple to make custom chips that are x86 compatible? Intel and AMD seem to do it. Is the instruction set the part that's limiting performance?
Genuine question: Wouldn't it be possible for Apple to make custom chips that are x86 compatible? Intel and AMD seem to do it. Is the instruction set the part that's limiting performance?
Someone can correct me if I'm wrong, but my understanding is that the biggest impediment to this, apart from Intel not liking the idea of Apple taking their instruction set without having to pay...
Someone can correct me if I'm wrong, but my understanding is that the biggest impediment to this, apart from Intel not liking the idea of Apple taking their instruction set without having to pay Intel for x86 chips, is the licensing fees that come with building x86 products. Apple would have to buy rights to manufacture and design x86 processors.
Apple has a great team of chip engineers who are most familiar with ARM. At this point, it would silly to not utilise that institutional corporate knowledge to expand the use cases for their chips to Macs too.
Intel owns the x86 license. AMD owns the x86-64 license (yes, Intel does not own the 64 bit version lol) . They decided to mutually share between themselves. They're not going to license it out to...
Intel owns the x86 license. AMD owns the x86-64 license (yes, Intel does not own the 64 bit version lol) . They decided to mutually share between themselves.
Interestingly, Intel did make a 64 bit instruction set, paired with the itanium line of cpus. https://en.wikipedia.org/wiki/IA-64 I always thought that it was quickly overtaken with amd64, but it...
I always thought that it was quickly overtaken with amd64, but it turns out intel made itanium chips until recently. They only stopped shipping them in January this year, and it is not EOLed until next year.
Edit: Bad autocorrect, Intel did not make uranium cpus!
I'm surprised they still made them, but yeah, that's historically why Intel is forced to use AMD's x86-64. They invested heavily in VLIW... which turned out to be a huge flop. While all this was...
I'm surprised they still made them, but yeah, that's historically why Intel is forced to use AMD's x86-64. They invested heavily in VLIW... which turned out to be a huge flop. While all this was happening, AMD just took x86 and made it 64 bit, because this was back in the FX days and boy AMD did not have the money to spend on that kind of R&D. In the end, Intel had to give up on VLIW and just licensed x86-64 from AMD.
Ah, I thought AMD basically opened up the 64bit versions and Intel just used those, I didn't know there was a weird split deal. Still, on a more philosophical level, why can instruction sets be...
Ah, I thought AMD basically opened up the 64bit versions and Intel just used those, I didn't know there was a weird split deal.
Still, on a more philosophical level, why can instruction sets be "owned"? Isn't it just a bunch of bytes describing basic mathematical operations? Just like you can't keep competitors from adapting a file format?
If Apple follows the same playbook as they did when moving from PowerPC to Intel back in 2005/2006, this won't be a limitation either. Apple shipped a machine language translation layer called...
Nothing compiled to machine code.
If Apple follows the same playbook as they did when moving from PowerPC to Intel back in 2005/2006, this won't be a limitation either. Apple shipped a machine language translation layer called Rosetta that allowed the vast majority of PPC-native apps to run on Intel CPUs.
Of course, there was a small but measurable performance hit, but in many cases the Intel chips were so much faster that PPC apps still ran more smoothly on a equivalent newer machine (e.g. PowerBook -> MacBook Pro).
Maybe it's because dot Net is impossible to format on a mobile keyboard. God damn it autocorrect. Machine code programs wouldn't work without recompiling. Programs in a byte code that runs on a...
Maybe it's because dot Net is impossible to format on a mobile keyboard. God damn it autocorrect.
Machine code programs wouldn't work without recompiling.
Programs in a byte code that runs on a runtime would be fine (Java, dot net, etc)
This has been a rumour for what feels like a decade now. Granted, it does take some time to make sure that something as complex as an operating system works on any new platform.
This has been a rumour for what feels like a decade now.
Granted, it does take some time to make sure that something as complex as an operating system works on any new platform.
I’m really curious what this will mean for all the software that we're used to. I am a computer scientist, but I never took a class on architectures of processors or an operating systems class....
I’m really curious what this will mean for all the software that we're used to.
I am a computer scientist, but I never took a class on architectures of processors or an operating systems class. Maybe someone with more knowledge can fill me in on the implications of this?
I believe Apple's thinking is that it won't really matter from the end user's perspective since they will push more people into using Swift or Objective C and provide tools like Marzipan to port...
I believe Apple's thinking is that it won't really matter from the end user's perspective since they will push more people into using Swift or Objective C and provide tools like Marzipan to port iOS apps into the Mac. For everything else I expect they plan to fill the gaps with virtualization. Windows runs on ARM now too, so even that option might be open to them. Not great for people who like to tinker with computers or for gamers, but everyone else should be okay.
Compatibility is less of an issue now that so many professional applications are going SaaS. Most end user applications are pretty lightweight thin clients these days or obnoxiously heavy electron apps. They probably won't be switching to ARM for the Macs targeted at professionals who handle heavier loads.
PowerPC transition and x86 both happened. I think this mostly just means we lose stuff that not enough people are interested to port. I’m still on Mojave because of the 64-bit only requirement...
PowerPC transition and x86 both happened. I think this mostly just means we lose stuff that not enough people are interested to port.
I’m still on Mojave because of the 64-bit only requirement breaks one application that’s critical to my budgeting.
Yes but at that point x86 so outstripped PPC in performance that they could eat the overhead of dynamically translating PPC binaries and still have it be faster. ARM becomes tough because, while...
PowerPC transition and x86 both happened.
Yes but at that point x86 so outstripped PPC in performance that they could eat the overhead of dynamically translating PPC binaries and still have it be faster. ARM becomes tough because, while it is way more efficient it's not necessarily dramatically faster. So they don't have as much surplus power to fill in the gaps.
Maybe. But I can imagine that getting expensive real fast. I’m sure there might be some VLSI design considerations that make it hard too, but that’s so far outside my area of knowledge.
Maybe. But I can imagine that getting expensive real fast. I’m sure there might be some VLSI design considerations that make it hard too, but that’s so far outside my area of knowledge.
According to the article, Intel's slow performance improvements over the last decade are the primary driving factor behind Apple moving to home-grown ARM chips, so it could be a similar situation...
According to the article, Intel's slow performance improvements over the last decade are the primary driving factor behind Apple moving to home-grown ARM chips, so it could be a similar situation here.
If you've been reading the tea leaves though, the rumours have been gaining increasingly large amounts of credibility as the years go by. Apple's actions also speak to this: first there was...
If you've been reading the tea leaves though, the rumours have been gaining increasingly large amounts of credibility as the years go by. Apple's actions also speak to this: first there was Marzipan, now there's Catalyst. These provide ways of creating (poor, but usable) "universal" apps from a single Xcode project with UIKit and SwiftUI, obfuscating the need to use AppKit for macOS.
Then there's Intel's horrible low-power mobile offering cadence over the last few years. I maintain the MacBook (the low-power fanless model that was introduced in 2015, not the product lineup) would've been a fantastic product with better battery life and more performance if at the time, it ran a supercharged Apple A9X processor (this is the same chip the first generation iPad Pro uses), instead of a gimpy Intel Core M-5Y31.
Apple's ARM chips were ready for the task of powering a MacBook all the way back in the mid 2010's. The only thing stopping them was the platform it was needed for. I for one can't wait to see the return of a fanless MacBook. Give it a supercharged A14X, and you'll instantly have the best performing, longest-lasting battery life, and most power efficient ultrabook ever. It will sell like hotcakes for the people who want internet browsing & light document editing machines.
I don't feel that Marzipan and Catalyst are good markers of this kind of change. Those are all about creating software that works across two very different operating systems - the fact that these...
I don't feel that Marzipan and Catalyst are good markers of this kind of change. Those are all about creating software that works across two very different operating systems - the fact that these operating systems are designed for different architectures is secondary.
I get that Apple's chips are supposed to be extremely fast, but there is so much more to the equation than speed. I think that to make it worth the transition, they need something that fits in every market, including the high end. Apple isn't likely to repeat Microsoft's Windows RT fiasco.
Well, it's an inference. If you have universal apps pre-built for both iOS and macOS, software incompatibilities when the macOS platform transition to ARM occurs become even less important. No...
Well, it's an inference. If you have universal apps pre-built for both iOS and macOS, software incompatibilities when the macOS platform transition to ARM occurs become even less important. No doubt the development of Project Catalyst has given Apple Engineering lessons learned about how to begin to navigate the software side of the ISA transition process. Yes, it's a secondary order effect, but it's part of the dovetail of the overall strategy IMO.
Yes, but you're also reading the Catalyst information the other way around - Apple is marketing it as a way to take existing iOS apps and make it work on MacOS, not the other way around. It's...
Yes, but you're also reading the Catalyst information the other way around - Apple is marketing it as a way to take existing iOS apps and make it work on MacOS, not the other way around. It's basically Electron for iOS developers.
In any case, the important thing that needs to happen to transition ISAs is to implement existing APIs, not to create new ones. Without that, every software package will need major parts of it rewritten. And I doubt we'll see any proof of that until Apple actually releases an ARM version of MacOS.
I'm really skeptical about any tech rumors, but this one in particular has that "I want to believe so I can see evidence everywhere" vibe. MacOS is extremely slowly becoming more and more iPad-like as time goes on, but I'm not taking that as a sign that they want to change architectures, but that they are trying to make them more homogeneous.
That is an important part of the transition strategy though. If the fear is that an ARM switch will diminish the amount of available software/capabilities on the Mac, flooding the zone with ported...
Apple is marketing it as a way to take existing iOS apps and make it work on MacOS, not the other way around. It's basically Electron for iOS developers.
That is an important part of the transition strategy though. If the fear is that an ARM switch will diminish the amount of available software/capabilities on the Mac, flooding the zone with ported over iOS apps would fix the problem nicely. (If only all the Marzipan apps we've gotten thus far weren't total shit).
I wonder how they are going to handle compatibility with existing apps. Last time Apple switched architectures, they included a PPC emulator that worked reasonably well but wasn't ideal. Emulation...
I wonder how they are going to handle compatibility with existing apps. Last time Apple switched architectures, they included a PPC emulator that worked reasonably well but wasn't ideal.
Emulation has come a long way since then. Since Apple is designing the silicon themselves it wouldn't be a stretch for them to include a few custom instructions that help accelerate x86 emulation, making the transition easier for users.
I'd say that software providers will be against this - having to port all of their code over. But the up side is that you get to dispose of all the users on legacy perpetual licenses, making the...
I'd say that software providers will be against this - having to port all of their code over. But the up side is that you get to dispose of all the users on legacy perpetual licenses, making the new ports subscription only.
(and, yes, this makes me sad/angry)
Coding standards have changed a lot in the last 20 years. As long as Apple isn't changing their APIs at the same time, most apps could have working builds within a week or two. Many will probably...
Coding standards have changed a lot in the last 20 years. As long as Apple isn't changing their APIs at the same time, most apps could have working builds within a week or two. Many will probably just require changing the compiler's target architecture.
Agreed. I worked at a company with a very large, very popular Mac application suite during the PPC to Intel transition. It was absolute hell, but only because one of our legacy apps had huge...
Agreed. I worked at a company with a very large, very popular Mac application suite during the PPC to Intel transition. It was absolute hell, but only because one of our legacy apps had huge swaths of its codebase in raw PPC assembly, for legacy performance reasons. Thankfully, it was all converted to portable C, which should make their job much easier this time around.
But there's like a billion companies producing ARM chips. ARM develops and licenses the ISC, but Samsung, Apple, Qualcomm, Intel (yes, Intel also makes Arm chips, just not for consumer CPUs), etc...
But there's like a billion companies producing ARM chips. ARM develops and licenses the ISC, but Samsung, Apple, Qualcomm, Intel (yes, Intel also makes Arm chips, just not for consumer CPUs), etc all develop ARM chips.
While I'm also skeptical about a move to ARM, there are a lot more than 2 companies designing and producing ARM chips: Samsung, Qualcomm, Apple, and Huawei to name a few. That's actually one of...
While I'm also skeptical about a move to ARM, there are a lot more than 2 companies designing and producing ARM chips: Samsung, Qualcomm, Apple, and Huawei to name a few. That's actually one of ARM's better points over x86.
The thing that concerns me about migrating desktops and laptops to ARM is that the whole platform has thus far been a dumpster fire of hardware specific operating systems requiring explicit manufacturer support. If we can't replicate the relatively hardware agnostic OS model of x86, I don't want any part of this. Not that that's relevant to Apple of course.
Yup. All those years ago when I first heard about Android, I thought that Linux on the smartphone would finally start pushing phones to become more like regular PCs. Instead, things have gone in...
Yup. All those years ago when I first heard about Android, I thought that Linux on the smartphone would finally start pushing phones to become more like regular PCs. Instead, things have gone in the complete opposite direction, especially in the laptop market with nonsense like soldered RAM and storage, and non-replaceable batteries. Hopefully moving to ARM doesn't accelerate the trend, but let's be real, it will.
It'll be a gradual phase in—expect to see this in lower-end products initially where the most important concerns are efficiency and thermal design constraints, which Apple's ARM chips excel at...
It'll be a gradual phase in—expect to see this in lower-end products initially where the most important concerns are efficiency and thermal design constraints, which Apple's ARM chips excel at managing. Think the MacBook Air (which could possibly go fanless with an ARM processor!), and the iMacs designed for school environments.
Apple's "Pro" laptops and especially desktops will most likely continue to stick with x86 for the time being. The Mac Pro & iMac Pro will likely be the last products to complete the transition. My expectation is that it's not a chip design problem—if Apple were to introduce a series of turbocharged ARM processors designed for Pro use cases in desktop environments, they would be up to the task of powering these beasts in a way that compares favourably with x86—it's the disruption that this would cause pro users due to software and hardware compatibility differences. That'll take a few more years to resolve before the workflow for professionals can handle a graceful transition away from x86.
I wonder if it will be a hard break or a soft one. Like, would the ARM versions be able to run things like Logic or are they going to have a class of software that only x86 Macs can run? The Logic...
I wonder if it will be a hard break or a soft one. Like, would the ARM versions be able to run things like Logic or are they going to have a class of software that only x86 Macs can run? The Logic Pro application on iPad Pro, as far as I know, only lets you remote control the app running on a Mac, it can't run on the iPad itself.
Hmm. I think Apple will want to tell a story of just how ready ARM chips are for MacBooks. A demo of Final Cut rendering some 1080p HD-like video on an ARMBook might accomplish that—Apple is more...
Hmm. I think Apple will want to tell a story of just how ready ARM chips are for MacBooks. A demo of Final Cut rendering some 1080p HD-like video on an ARMBook might accomplish that—Apple is more than happy to spend time optimising their professional software for their hardware (see: the updates Logic and Final Cut received to take advantage of the hardware offerings in the Mac Pro).
Even though most people don't render video on their MacBook Airs, it'd certainly demonstrate just how capable these new chips are.
iPhones can already handle 4K editing and compositing. And Final Cut Pro and Motion (and even iMovie, actually) do most of their image processing on the GPU.
*** 4K support is available on iPhone 6s, iPhone 6s Plus, iPad Air 2, iPad Pro, and later devices.
...
Easily add picture in picture, green screen, and split screen effects
And Final Cut Pro and Motion (and even iMovie, actually) do most of their image processing on the GPU.
Sorry, I should have been more specific. I meant professional editing software (like Adobe Premiere) and professional compositing software (like Adobe After Effects).
Sorry, I should have been more specific. I meant professional editing software (like Adobe Premiere) and professional compositing software (like Adobe After Effects).
I would think Adobe has the inside scoop at Apple and would know to work on this if it's in their plans. My worry is more for smaller developers or ones where the Mac isn't a core market.
I would think Adobe has the inside scoop at Apple and would know to work on this if it's in their plans. My worry is more for smaller developers or ones where the Mac isn't a core market.
That's slightly "cheating". Apple has hardware MP4 encoding/decoding in their chips. Higher-end professional productions are likely to use professional formats like redcode or Apple's own ProRes....
That's slightly "cheating". Apple has hardware MP4 encoding/decoding in their chips. Higher-end professional productions are likely to use professional formats like redcode or Apple's own ProRes.
That being said, I'm an outsider here and I don't know what iMovie on iPad supports.
Begun, the instruction set wars have.
Granted, it's Bloomberg which has a spotty record on tech coverage. But if true, Bootcampers and Mac gamers are BTFO. Shadow and GeForceNow can't come out a moment too soon.
Given that Windows 10 runs just fine on ARM64, Apple might still include Boot Camp support. The hard part is that very little of the Windows ecosystem can run without Microsoft's x64 emulation layer, meaning that a lot of third-party applications are slow. Unlike Microsoft, Apple has the power to force developers to adapt to changes in macOS and Mac hardware.
I don't know how Apple's EFI would work on their ARM laptops, so Linux support would be iffy at first. But ARM is clearly the direction that many laptop manufacturers are going in, so I expect that the support will eventually be there.
I just realized that this is my main gripe, I never figured Windows 10 might just run on ARM chips but why not?
What does it mean for general backwards-compatibility, though? Nothing made for current Intel MacBooks would run on ARM machines?
Developers would need to recompile their binaries—for apps on the Mac App Store, my bet is they're already implicitly compatible with ARM Macs because of Apple's restrictions around API usage on macOS. Apple may even be able to automatically recompile from "day one".
Developers shouldn't have any problems™ provided they're using publicly surfaced macOS APIs. Apple can provide a translation layer at that level to ensure instruction compatibility with both x86 and ARM. The hard part is developers who utilise private APIs. This includes most big names like Microsoft and Adobe, which unfortunately, have an outsized influence on the adoption and value of macOS hardware.
I can't find it straight off the bat, but there's a good article documenting how Apple has actually modified their own APIs for Microsoft, Adobe, and many other big companies, to ensure "bugs" don't appear in those companies' own programs which abuse the system APIs in unexpected ways. It's a good read.
Genuine question: Wouldn't it be possible for Apple to make custom chips that are x86 compatible? Intel and AMD seem to do it. Is the instruction set the part that's limiting performance?
Someone can correct me if I'm wrong, but my understanding is that the biggest impediment to this, apart from Intel not liking the idea of Apple taking their instruction set without having to pay Intel for x86 chips, is the licensing fees that come with building x86 products. Apple would have to buy rights to manufacture and design x86 processors.
Apple has a great team of chip engineers who are most familiar with ARM. At this point, it would silly to not utilise that institutional corporate knowledge to expand the use cases for their chips to Macs too.
Intel owns the x86 license. AMD owns the x86-64 license (yes, Intel does not own the 64 bit version lol) . They decided to mutually share between themselves.
They're not going to license it out to Apple lol.
Interestingly, Intel did make a 64 bit instruction set, paired with the itanium line of cpus. https://en.wikipedia.org/wiki/IA-64
I always thought that it was quickly overtaken with amd64, but it turns out intel made itanium chips until recently. They only stopped shipping them in January this year, and it is not EOLed until next year.
Edit: Bad autocorrect, Intel did not make uranium cpus!
I'm surprised they still made them, but yeah, that's historically why Intel is forced to use AMD's x86-64. They invested heavily in VLIW... which turned out to be a huge flop. While all this was happening, AMD just took x86 and made it 64 bit, because this was back in the FX days and boy AMD did not have the money to spend on that kind of R&D. In the end, Intel had to give up on VLIW and just licensed x86-64 from AMD.
Ah, I thought AMD basically opened up the 64bit versions and Intel just used those, I didn't know there was a weird split deal.
Still, on a more philosophical level, why can instruction sets be "owned"? Isn't it just a bunch of bytes describing basic mathematical operations? Just like you can't keep competitors from adapting a file format?
Nothing compiled to machine code. Java, . Net, python, etc. Would run fine.
Additionally, electron apps would just need to swap the chromium binary.
If Apple follows the same playbook as they did when moving from PowerPC to Intel back in 2005/2006, this won't be a limitation either. Apple shipped a machine language translation layer called Rosetta that allowed the vast majority of PPC-native apps to run on Intel CPUs.
Of course, there was a small but measurable performance hit, but in many cases the Intel chips were so much faster that PPC apps still ran more smoothly on a equivalent newer machine (e.g. PowerBook -> MacBook Pro).
The inclusion of the word "fine" here makes this a bit confusing to parse.
Maybe it's because dot Net is impossible to format on a mobile keyboard. God damn it autocorrect.
Machine code programs wouldn't work without recompiling.
Programs in a byte code that runs on a runtime would be fine (Java, dot net, etc)
Electron would be fine
This has been a rumour for what feels like a decade now.
Granted, it does take some time to make sure that something as complex as an operating system works on any new platform.
I’m really curious what this will mean for all the software that we're used to.
I am a computer scientist, but I never took a class on architectures of processors or an operating systems class. Maybe someone with more knowledge can fill me in on the implications of this?
I believe Apple's thinking is that it won't really matter from the end user's perspective since they will push more people into using Swift or Objective C and provide tools like Marzipan to port iOS apps into the Mac. For everything else I expect they plan to fill the gaps with virtualization. Windows runs on ARM now too, so even that option might be open to them. Not great for people who like to tinker with computers or for gamers, but everyone else should be okay.
Compatibility is less of an issue now that so many professional applications are going SaaS. Most end user applications are pretty lightweight thin clients these days or obnoxiously heavy electron apps. They probably won't be switching to ARM for the Macs targeted at professionals who handle heavier loads.
PowerPC transition and x86 both happened. I think this mostly just means we lose stuff that not enough people are interested to port.
I’m still on Mojave because of the 64-bit only requirement breaks one application that’s critical to my budgeting.
Yes but at that point x86 so outstripped PPC in performance that they could eat the overhead of dynamically translating PPC binaries and still have it be faster. ARM becomes tough because, while it is way more efficient it's not necessarily dramatically faster. So they don't have as much surplus power to fill in the gaps.
Arm is something they can load up with a lot of cores, though. Could parallelism aid the real time translation?
Maybe. But I can imagine that getting expensive real fast. I’m sure there might be some VLSI design considerations that make it hard too, but that’s so far outside my area of knowledge.
According to the article, Intel's slow performance improvements over the last decade are the primary driving factor behind Apple moving to home-grown ARM chips, so it could be a similar situation here.
If you've been reading the tea leaves though, the rumours have been gaining increasingly large amounts of credibility as the years go by. Apple's actions also speak to this: first there was Marzipan, now there's Catalyst. These provide ways of creating (poor, but usable) "universal" apps from a single Xcode project with UIKit and SwiftUI, obfuscating the need to use AppKit for macOS.
Then there's Intel's horrible low-power mobile offering cadence over the last few years. I maintain the MacBook (the low-power fanless model that was introduced in 2015, not the product lineup) would've been a fantastic product with better battery life and more performance if at the time, it ran a supercharged Apple A9X processor (this is the same chip the first generation iPad Pro uses), instead of a gimpy Intel Core M-5Y31.
I know geekbench isn't gospel, but...
Apple's ARM chips were ready for the task of powering a MacBook all the way back in the mid 2010's. The only thing stopping them was the platform it was needed for. I for one can't wait to see the return of a fanless MacBook. Give it a supercharged A14X, and you'll instantly have the best performing, longest-lasting battery life, and most power efficient ultrabook ever. It will sell like hotcakes for the people who want internet browsing & light document editing machines.
I don't feel that Marzipan and Catalyst are good markers of this kind of change. Those are all about creating software that works across two very different operating systems - the fact that these operating systems are designed for different architectures is secondary.
I get that Apple's chips are supposed to be extremely fast, but there is so much more to the equation than speed. I think that to make it worth the transition, they need something that fits in every market, including the high end. Apple isn't likely to repeat Microsoft's Windows RT fiasco.
Well, it's an inference. If you have universal apps pre-built for both iOS and macOS, software incompatibilities when the macOS platform transition to ARM occurs become even less important. No doubt the development of Project Catalyst has given Apple Engineering lessons learned about how to begin to navigate the software side of the ISA transition process. Yes, it's a secondary order effect, but it's part of the dovetail of the overall strategy IMO.
Yes, but you're also reading the Catalyst information the other way around - Apple is marketing it as a way to take existing iOS apps and make it work on MacOS, not the other way around. It's basically Electron for iOS developers.
In any case, the important thing that needs to happen to transition ISAs is to implement existing APIs, not to create new ones. Without that, every software package will need major parts of it rewritten. And I doubt we'll see any proof of that until Apple actually releases an ARM version of MacOS.
I'm really skeptical about any tech rumors, but this one in particular has that "I want to believe so I can see evidence everywhere" vibe. MacOS is extremely slowly becoming more and more iPad-like as time goes on, but I'm not taking that as a sign that they want to change architectures, but that they are trying to make them more homogeneous.
That is an important part of the transition strategy though. If the fear is that an ARM switch will diminish the amount of available software/capabilities on the Mac, flooding the zone with ported over iOS apps would fix the problem nicely. (If only all the Marzipan apps we've gotten thus far weren't total shit).
Hmm. I guess I can see that as a vague possibility, but I can't say it's a particularly wise strategy. I suppose time will tell.
I wonder how they are going to handle compatibility with existing apps. Last time Apple switched architectures, they included a PPC emulator that worked reasonably well but wasn't ideal.
Emulation has come a long way since then. Since Apple is designing the silicon themselves it wouldn't be a stretch for them to include a few custom instructions that help accelerate x86 emulation, making the transition easier for users.
I'd say that software providers will be against this - having to port all of their code over. But the up side is that you get to dispose of all the users on legacy perpetual licenses, making the new ports subscription only.
(and, yes, this makes me sad/angry)
Coding standards have changed a lot in the last 20 years. As long as Apple isn't changing their APIs at the same time, most apps could have working builds within a week or two. Many will probably just require changing the compiler's target architecture.
Agreed. I worked at a company with a very large, very popular Mac application suite during the PPC to Intel transition. It was absolute hell, but only because one of our legacy apps had huge swaths of its codebase in raw PPC assembly, for legacy performance reasons. Thankfully, it was all converted to portable C, which should make their job much easier this time around.
One nice thing about x86 is we have two competing companies producing x86 chips. I wouldn’t like to see the world go all in on ARM.
But there's like a billion companies producing ARM chips. ARM develops and licenses the ISC, but Samsung, Apple, Qualcomm, Intel (yes, Intel also makes Arm chips, just not for consumer CPUs), etc all develop ARM chips.
While I'm also skeptical about a move to ARM, there are a lot more than 2 companies designing and producing ARM chips: Samsung, Qualcomm, Apple, and Huawei to name a few. That's actually one of ARM's better points over x86.
The thing that concerns me about migrating desktops and laptops to ARM is that the whole platform has thus far been a dumpster fire of hardware specific operating systems requiring explicit manufacturer support. If we can't replicate the relatively hardware agnostic OS model of x86, I don't want any part of this. Not that that's relevant to Apple of course.
I wholeheartedly agree. Laptops already get thrown out far more then they should be, and the current ARM market would just make it worse.
Yup. All those years ago when I first heard about Android, I thought that Linux on the smartphone would finally start pushing phones to become more like regular PCs. Instead, things have gone in the complete opposite direction, especially in the laptop market with nonsense like soldered RAM and storage, and non-replaceable batteries. Hopefully moving to ARM doesn't accelerate the trend, but let's be real, it will.
What about especial cases like 4K video editing and compositing?
It'll be a gradual phase in—expect to see this in lower-end products initially where the most important concerns are efficiency and thermal design constraints, which Apple's ARM chips excel at managing. Think the MacBook Air (which could possibly go fanless with an ARM processor!), and the iMacs designed for school environments.
Apple's "Pro" laptops and especially desktops will most likely continue to stick with x86 for the time being. The Mac Pro & iMac Pro will likely be the last products to complete the transition. My expectation is that it's not a chip design problem—if Apple were to introduce a series of turbocharged ARM processors designed for Pro use cases in desktop environments, they would be up to the task of powering these beasts in a way that compares favourably with x86—it's the disruption that this would cause pro users due to software and hardware compatibility differences. That'll take a few more years to resolve before the workflow for professionals can handle a graceful transition away from x86.
I wonder if it will be a hard break or a soft one. Like, would the ARM versions be able to run things like Logic or are they going to have a class of software that only x86 Macs can run? The Logic Pro application on iPad Pro, as far as I know, only lets you remote control the app running on a Mac, it can't run on the iPad itself.
Hmm. I think Apple will want to tell a story of just how ready ARM chips are for MacBooks. A demo of Final Cut rendering some 1080p HD-like video on an ARMBook might accomplish that—Apple is more than happy to spend time optimising their professional software for their hardware (see: the updates Logic and Final Cut received to take advantage of the hardware offerings in the Mac Pro).
Even though most people don't render video on their MacBook Airs, it'd certainly demonstrate just how capable these new chips are.
iPhones can already handle 4K editing and compositing.
And Final Cut Pro and Motion (and even iMovie, actually) do most of their image processing on the GPU.
Sorry, I should have been more specific. I meant professional editing software (like Adobe Premiere) and professional compositing software (like Adobe After Effects).
Sorry - I added my edit at the same time you were replying.
That’s okay ;)
Adobe products are very popular in any case, and switching this kind of software is a great disruption for creative professionals.
I would think Adobe has the inside scoop at Apple and would know to work on this if it's in their plans. My worry is more for smaller developers or ones where the Mac isn't a core market.
That’s quite possible yes.
That's slightly "cheating". Apple has hardware MP4 encoding/decoding in their chips. Higher-end professional productions are likely to use professional formats like redcode or Apple's own ProRes.
That being said, I'm an outsider here and I don't know what iMovie on iPad supports.