Mark Gurman and Ian King, writing for Bloomberg:
Now — and I'm just spit-balling here — imagine this is something beyond the whole Intel/ARM question. (Apple has been prototyping ARM-based Macs for years, after all).
Imagine it's an extension of the "fusion" architecture that Apple's been increasingly using across their products and services. Fusion Drive melds high-capacity platters with high-speed solid state. iCloud Libraries do something similar but meld online and local storage. The iPhone 7 Plus camera melds a wide-angle with a telephoto lens.
A better example is the A10 system-on-a-chip, though, which Apple went so far as to brand "Fusion". When Apple made the main A10 cores, they noticed it was so high-performance it actually made lower-performance tasks less efficient. So, to fill the space left beneath it, Apple added a second set of lower-performance, more power efficient cores. The result was Apple's first big.LITTLE chipset.
For several generations now, though, Apple has also been doing sensor fusion hubs by including the M-series co-processors — originally alongside but now integrated into — the A-series. That lets them do things like track motion more power efficiently.
The T1 system-in-package on the MacBook Pro is another example. The Mac controls the majority of the Touch Bar but the T1 SIP handles Touch ID, Apple Pay, and displaying any and all related data.
Power efficiency is Apple's jam. Unless and until they license x86 or swap MacBook to ARM, there's only so much even the tight and belabored integration they do with Intel will deliver them.
Offloading low-power, low-level tasks to their own silicon, though, is absolutely something Apple could and would do regardless of the main processor architecture. Same as they could and did offload display to their own, custom timing controller when they wanted to bring 5K to the iMac and the industry just hadn't gotten there yet.
I wouldn't be surprised to see Apple take on more and more of the silicon inside all of their devices as time goes on. Modems, graphics processors, central processors — with the team they have in place, there's no limit to what they can do other than what makes sense to them and what they choose to focus on at any given point in time.
Like I said when Apple's first wireless chip, W1 was introduced...
Rene Ritchie is one of the most respected Apple analysts in the business, reaching a combined audience of over 40 million readers a month. His YouTube channel, Vector, has over 90 thousand subscribers and 14 million views and his podcasts, including Debug, have been downloaded over 20 million times. He also regularly co-hosts MacBreak Weekly for the TWiT network and co-hosted CES Live! and Talk Mobile. Based in Montreal, Rene is a former director of product marketing, web developer, and graphic designer. He's authored several books and appeared on numerous television and radio segments to discuss Apple and the technology industry. When not working, he likes to cook, grapple, and spend time with his friends and family.
..... Sent from the iMore App
This is really interesting. I’m not sure how feasible a big.LITTLE approach is across completely different chipsets, but the concept is very appealing. Real-time scheduling of third party code is probably not going to happen anytime soon, but splitting the OS so that some processes are always handled by ARM cores and some by Intel cores might be possible. It would be great if macOS could run low power tasks such as browsing, email and text editing on an ARM chip, and only use Intel when you need more oomph. I’d imagine a future MacBook Pro with an OLED screen, Kaby Lake Intel cores, LPDDR4 memory and ARM cores for low power tasks could be very efficient indeed. However if Apple’s ARM chips keep progressing at the current rate then they will catch up with Intel in terms of performance soon anyway, so why bother...
Re: "However if Apple’s ARM chips keep progressing at the current rate then they will catch up with Intel in terms of performance soon anyway, so why bother..." You probably answered this yourself earlier in your post. Most third-party applications would still be coded for the X86 architecture. Rewriting their codebase to ARM wouldn't be a trivial undertaking for many professional grade application developers. The iPad Pro's a good example. Marketed heavily to creative professionals, and performance wise, the 12.9" iPad Pro performs better than the 12" MacBook for most tasks (and has a more pixel dense screen to boot), but iPad apps that are the equivalent of their desktop counterparts are still few and far between, even 15 months since the iPad Pro's release. No desktop equivalent of the image or vector editing suites from Adobe or Affinity, no desktop equivalents of professional CAD software, no desktop equivalent DAWs like ProTools or Ableton, etc. In fact, the only two creative professions I see catered to with the Pro iPads are writers and illustrators. Almost every other segment seems to only have gimped 'complimentary' apps that do some stuff but require users to export to a Mac/PC to finish the job on the desktop versions. Heck, we don't even have Xcode for iOS yet. In the short term, Rene's "Fusion" thing would seem more viable compared to moving the entire Mac line to ARM exclusively. Long term? Anything's possible, I suppose.
There is a big difference between migrating an app from macOS to iOS and changing a macOS app to run on ARM instead of Intel. The former involves a complete rethink of how the app should work in a touchscreen environment, whereas the latter would hopefully just involve a recompile for most apps. The good thing about having both architectures is that it wouldn’t be mandatory, so if an app is particularly hard to migrate then they wouldn't have to. And the most complex apps probably wouldn’t want to anyway. For instance the most difficult stuff to port would be where an app uses assembly language for outright performance, but you probably wouldn’t want that sort of app running on the slow cores anyway. I’m not knocking the Fusion idea. I really like it as a transition towards ARM instead of Intel. I’m just saying that it wouldn’t be as difficult for most developers to migrate their apps to ARM as you might think from the lack of Pro apps on iOS. A few apps might need a lot of work, but if ARM chips become as powerful as Intel with lower power requirements then it would be worth their while anyway.
"Rewriting their codebase to ARM wouldn't be a trivial undertaking for many professional grade application developers." It's already been done, and quite elegantly. The PowerPC switch to intel went well. Rosetta covered the migration period seamlessly. I think that this time around, they wouldn't need an emulator. Apple would integrate an ARM chip alongside Intel. Their own apps could run on ARM from the get go for energy efficiency and they could offer developers the option to offload some low power functions to the ARM chip. Extensions, widgets, things like that. That would give developers an incentive and would start bringing them on to ARM. Progressively, more and more functions could be run on ARM and eventually, entire 3rd party apps would run on it.
If the stock apps use the ARM cores then they may need to make it possible for entire third party apps to do the same soon after, if only to prevent the sort of anti-trust issues that plagued IE on Windows. If Safari is much more power efficient than other browsers then that would be a massive advantage that would undoubtedly interest Google’s lawyers.
From the Bloomberg article:
"Intel dipped on the news and ended the day down 0.8 percent at $36.52. Apple rose 6.1 percent to $128.75 in New York." The only thing we can be sure about is that someone made a good bit of money from this.
Thank you for signing up to iMore. You will receive a verification email shortly.
There was a problem. Please refresh the page and try again.