In the early 2000’s, Transmeta released the Crusoe and efficieon processors only to find that things like the LCD, RAM and storage gobble up a lot of energy. Battery life is clearly not at the heart of this transition.
Dont see how Apple is going to Reduce LCD power consumption, especially since mini/micro LED full array local dimming requires more power than an edge lit display.
Yeah, I agree battery life isn’t a big driver for today’s mobile device sales. Looks like 10 to 12 hours is the sweet spot and more runtime on top of that becomes a diminishing feature for selling the device.
However, going ARM will allow Apple to do other things, improve other features that may drive more sales. If you have ever seen an iPad Pro 12.9 logic board, it is about half as small as what you see on a 13” laptop with an x86 board, while being about as performant. They can make thinner and lighter 13” laptops in the 1.5 to 2 lb range. Or they can make a keyboard that has the same amount of travel as an external keyboard. A dual display clamshell can be made that is thin, light, and has sweet spot battery life. That extra volume can be used for more storage, more I/O, more things that can be placed in what used to be space for the logic board.
Would be kind of boring if it was just a regular laptop design.
In the early 2000’s, Transmeta released the Crusoe and efficieon processors only to find that things like the LCD, RAM and storage gobble up a lot of energy. Battery life is clearly not at the heart of this transition.
Dont see how Apple is going to Reduce LCD power consumption, especially since mini/micro LED full array local dimming requires more power than an edge lit display.
Yeah, I agree battery life isn’t a big driver for today’s mobile device sales. Looks like 10 to 12 hours is the sweet spot and more runtime on top of that becomes a diminishing feature for selling the device.
However, going ARM will allow Apple to do other things, improve other features that may drive more sales. If you have ever seen an iPad Pro 12.9 logic board, it is about half as small as what you see on a 13” laptop with an x86 board, while being about as performant. They can make thinner and lighter 13” laptops in the 1.5 to 2 lb range. Or they can make a keyboard that has the same amount of travel as an external keyboard. A dual display clamshell can be made that is thin, light, and has sweet spot battery life. That extra volume can be used for more storage, more I/O, more things that can be placed in what used to be space for the logic board.
Would be kind of boring if it was just a regular laptop design.
"A dual display clamshell can be made that is thin, light"
I know patents are not a guarantee, but from many of the more recent laptop patents filed by Apple that I have seen, I believe a dual-display device is the end goal.
In the early 2000’s, Transmeta released the Crusoe and efficieon processors only to find that things like the LCD, RAM and storage gobble up a lot of energy. Battery life is clearly not at the heart of this transition.
Dont see how Apple is going to Reduce LCD power consumption, especially since mini/micro LED full array local dimming requires more power than an edge lit display.
Yeah, I agree battery life isn’t a big driver for today’s mobile device sales. Looks like 10 to 12 hours is the sweet spot and more runtime on top of that becomes a diminishing feature for selling the device.
However, going ARM will allow Apple to do other things, improve other features that may drive more sales. If you have ever seen an iPad Pro 12.9 logic board, it is about half as small as what you see on a 13” laptop with an x86 board, while being about as performant. They can make thinner and lighter 13” laptops in the 1.5 to 2 lb range. Or they can make a keyboard that has the same amount of travel as an external keyboard. A dual display clamshell can be made that is thin, light, and has sweet spot battery life. That extra volume can be used for more storage, more I/O, more things that can be placed in what used to be space for the logic board.
Would be kind of boring if it was just a regular laptop design.
"A dual display clamshell can be made that is thin, light"
I know patents are not a guarantee, but from many of the more recent laptop patents filed by Apple that I have seen, I believe a dual-display device is the end goal.
They most certainly have prototyped both iOS and macOS versions. Something held them back. Maybe they felt it was too cumbersome for not much gain, too heavy, not enough battery life, who knows. They have thought about clamshell hinge accessories that connect two iPads together, never shipped. They prototyped the Surface Studio style tilting an iMac down and at a drafting table style angle about 10 years ago. They said gorilla arm instead. All they have done is the Touch Bar. The second screen display like the Touch Bar is also not a new idea either.
Maybe it won’t be really useful. It’s an old old idea. Multiple companies have tried. The Surface Neo looks like it is too small, and I’m skeptical of it. A 13” and 16” vertical display model with a 13” touch screen on the base is something I would like to try. The software keyboard will be wide enough for the full key set at standard spacing, stylus input would be great, and a 13” vertical display is about the practical minimum for modern WIMP UIs running office automation, web surfing, engineering, with a lot of windows open.
If Apple Maps and Siri are any indication, Apple will get its GPU game together by 2026.
Alternatively, if the ARM SoCs from AirPods, Watch to iPad Pros are any indication, the performance of the CPU, GPU, RAM, storage and encryption is going to be great right off the bat!
iOS and iPad OS are lightweight Unix variant of Mac OS that can easily be recompiled for whatever Instruction Set Architecture (ISA). iPad Pro and iPhone 11 run on ~3-4GB RAM and run into thermal limits very quickly when pushed.
Playing games or shooting video at 4K continuously will tax the I/O and heat up a device into its thermal envelope in a jiffy.
As a previous user mentioned, A sub $500 iPad w/a keyboard is meant to compete with Chromebook.
- Intel 10nm node = TSMC 7nm node - Intel 10th gen Ice Lake mobile SKU’s are already shipping - Intel integrated UHD graphics and Iris graphics are improving at a fast clip.
Adding thunderbolt, and Mac OS grade I/O combined with Apple’s HUGE profit margins and.........you end up with a lot of work for nothing. Seems more like an engineering exercise designed to extract more concessions out of Intel for a semi-custom CPU with hardware level extensions that MacOS can exploit.
Mac’s already run the ARM based T2 as a coprocessor. Servers use ARM based accelerator cards to speed up functions. What if x86 and ARM cores could be combined on the same SoC package?
Any ideas on how Apple will handle the X86 code of current apps to run on ARM architecture? I am not educated on this. Is ARM close enough to X86 that the transition will be easy or will it require a Rosetta-like translation framework like the move from Moto 68000 to X86 did. Will we have universal binaries again or something else during the transition?
Well, both ARM and X86 chips are micro coded. Could Apple microcode the x86 instruction set into the ARM?
No, that would require a license from Intel. That ain't happening.
AMD builds compatible CPUs. So, Apple gets similar rights.
Any ideas on how Apple will handle the X86 code of current apps to run on ARM architecture? I am not educated on this. Is ARM close enough to X86 that the transition will be easy or will it require a Rosetta-like translation framework like the move from Moto 68000 to X86 did. Will we have universal binaries again or something else during the transition?
Well, both ARM and X86 chips are micro coded. Could Apple microcode the x86 instruction set into the ARM?
My guess is they already have, hence the lower than usual performance bump when the moved to Vortex (virtual cortex).
Any ideas on how Apple will handle the X86 code of current apps to run on ARM architecture? I am not educated on this. Is ARM close enough to X86 that the transition will be easy or will it require a Rosetta-like translation framework like the move from Moto 68000 to X86 did. Will we have universal binaries again or something else during the transition?
Microsoft has an X86 emulation layer for ARM Windows. It isn't great, but it's a solution.
A Rosetta-like framework is the most likely.
It can be a lot like the last time.
1. Apps using Apple’s frameworks and Xcode will mostly be a recompile 2. Apps that mostly use Apple’s frameworks, but not Xcode, or use 3rd party libraries, will use a binary translator like Rosetta (switching x86 instructions with ARM instructions at runtime) 3. Apps that only work with macOS/x86 with 3rd party x86 libraries will need to be run in a macOS/x86 VM a la classic. If Apple provides it, presumably, apps can be overlapped, and it won’t be macOS run inside a window.
And once again, the single biggest impediment to success will be Microsoft and Adobe moving their apps to macOS/ARM. If that doesn’t happen, macOS/x86 won’t be successful. Presumably, Apple will just do the work to bring FCPX and LPX over. Plugins may need to use Rosetta for awhile before they are moved over.
If you can run a VM why not just have a much down spec'ed intel chip as APU?
Most of these older apps are going to be poorly multi-threaded so having a good single core performance CPU and GPU SOC that can be dedicated to those apps or high demand apps running inside a dedicated sub Mac instance inside the machine. Not needed it turns off. Sets Apple up to make an eAPU and the Mac Pro could be that eAPU for a whole office, same idea just longer cables as lag can be dealt with.
Just thinking out loud, but I could kinda see Apple taking the iOS-to-"aMac" route, rather than MacOS-to-aMac. Apple's recent tools for bringing iOS apps to MacOS might be experimental testing grounds for taking native iOS/ iPad OS apps into a more traditional computer environment, like a new aMac. Perhaps they will branch out iOS to a laptop format, the way thy branched out iOS to iPad OS - rather than taking the big MacOS and bringing that to the new Arm based computer. This way they could also kinda reboot. Sound cumbersome to pull off.. but I think if the'll be changing to their own ARM processors, they might be totally Apple and think different, think grand, and reboot again. Buuuut... without Steve Jobs at the reigns... sounds perhaps more likely to just port Mac OS 😅
Any ideas on how Apple will handle the X86 code of current apps to run on ARM architecture? I am not educated on this. Is ARM close enough to X86 that the transition will be easy or will it require a Rosetta-like translation framework like the move from Moto 68000 to X86 did. Will we have universal binaries again or something else during the transition?
Microsoft has an X86 emulation layer for ARM Windows. It isn't great, but it's a solution.
A Rosetta-like framework is the most likely.
It can be a lot like the last time.
1. Apps using Apple’s frameworks and Xcode will mostly be a recompile 2. Apps that mostly use Apple’s frameworks, but not Xcode, or use 3rd party libraries, will use a binary translator like Rosetta (switching x86 instructions with ARM instructions at runtime) 3. Apps that only work with macOS/x86 with 3rd party x86 libraries will need to be run in a macOS/x86 VM a la classic. If Apple provides it, presumably, apps can be overlapped, and it won’t be macOS run inside a window.
And once again, the single biggest impediment to success will be Microsoft and Adobe moving their apps to macOS/ARM. If that doesn’t happen, macOS/x86 won’t be successful. Presumably, Apple will just do the work to bring FCPX and LPX over. Plugins may need to use Rosetta for awhile before they are moved over.
If you can run a VM why not just have a much down spec'ed intel chip as APU?
Most of these older apps are going to be poorly multi-threaded so having a good single core performance CPU and GPU SOC that can be dedicated to those apps or high demand apps running inside a dedicated sub Mac instance inside the machine. Not needed it turns off. Sets Apple up to make an eAPU and the Mac Pro could be that eAPU for a whole office, same idea just longer cables as lag can be dealt with.
Your expectations that older apps are likely to be poorly multi-threaded seems to suggest you believe new apps are much better multi-threaded. Grand Central Dispatch has been out a number of years, and while it makes another nice tool of abstraction for multi-threading tasks, it changes nothing in the nature that most applications have no viable path to having added threads increasing performance because the nature of what they do has no natural parallelizable tasks. In that situation, adding threads adds complexity (and likely bugs) while often causing performance costs you wouldn't have otherwise.
So you're half right: individual core performance will always matter for real-world applications, and it's this fact that made me laugh at the core wars octocore Android phones being a useful thing compared to the few faster iPhone cores, even if the SOCs were capable of keeping those CPU cores fed with data and instructions (no chance of that).
Any ideas on how Apple will handle the X86 code of current apps to run on ARM architecture? I am not educated on this. Is ARM close enough to X86 that the transition will be easy or will it require a Rosetta-like translation framework like the move from Moto 68000 to X86 did. Will we have universal binaries again or something else during the transition?
Microsoft has an X86 emulation layer for ARM Windows. It isn't great, but it's a solution.
A Rosetta-like framework is the most likely.
It can be a lot like the last time.
1. Apps using Apple’s frameworks and Xcode will mostly be a recompile 2. Apps that mostly use Apple’s frameworks, but not Xcode, or use 3rd party libraries, will use a binary translator like Rosetta (switching x86 instructions with ARM instructions at runtime) 3. Apps that only work with macOS/x86 with 3rd party x86 libraries will need to be run in a macOS/x86 VM a la classic. If Apple provides it, presumably, apps can be overlapped, and it won’t be macOS run inside a window.
And once again, the single biggest impediment to success will be Microsoft and Adobe moving their apps to macOS/ARM. If that doesn’t happen, macOS/x86 won’t be successful. Presumably, Apple will just do the work to bring FCPX and LPX over. Plugins may need to use Rosetta for awhile before they are moved over.
Microsoft and (to a lesser extent) Adobe have invested heavily in developing iOS apps. I don't think there will be a lot of work to make them native on an ARM Mac
They both have native MacOS apps so there's zero overhead for "porting" because they will already by now (13 years and counting!) have optimized performance-sensitive media code in ARM-native instructions, if they somehow can't use MacOS APIs that already wrap top performance native-CPU versions of those functions.
With likely few or no significant exceptions, the costs will be a simple change of an Xcode build configuration and a rebuild, followed by a full application test suite just to be sure: trivial.
How can so many people be blind to the fact that Apple is about to release a hybrid iPadOS / macOS ARM-based laptop?
It will be a 2-in-1 type of product, which will replace the iPad Pro, running iPadOS when undocked and macOS when docked.
The new 2-in-1 platform will allow only App Store apps to be installed, which will be easily compilable for both modes and will be able adjust the GUI automatically. Any existing iPadOS app will be easily recompilable for the dual-platform device.
Those who do not need to run non-App-Store apps and who are not power users will be gladly bying that device. I know I will.
Power users will continue to buy Pro-level Macs that will stay on the Intel architecture.
iPad Pro will be discontinued in favor of this 2-in-1 device.
Regular iPads will remain as a cheaper iPadOS-only device the same way they are now.
The 2-in-1 platform will merge the iPad Pro and the MacBook Air into one device. Alternatively, Apple may keep MacBook Air on the Intel architecture and instead will merge the now discontinued MacBook line with the iPad Pro. The name of the new 2-in-1 device will be MacPad with the price range between $1,000 and $2,000, depending on the specs. The maximum screen size will be 13”, the maximum RAM will be 16GB, with the maximum disk space 1TB SSD.
Apple will have the following lines of computing products (excluding phones): 1. iPad (ARM) 2. macPad (ARM) 3. Mac Mini (ARM) 4. iMac (ARM)
5. (possible but not likely) MacBook Air (Intel) 6. MacBook Pro (Intel) 7. iMac Pro (Intel) 8. Mac Pro (Intel)
Any ideas on how Apple will handle the X86 code of current apps to run on ARM architecture? I am not educated on this. Is ARM close enough to X86 that the transition will be easy or will it require a Rosetta-like translation framework like the move from Moto 68000 to X86 did. Will we have universal binaries again or something else during the transition?
There are multiple answers to this question all of which will be right in some context. However the overwhelming reality will be that it is not a big issue as most apps these days are written in high level languages to Apples specs. They will simply require a recompile. So native apps should be plentiful within weeks or months of release.
Now that doesn’t mean every app so expect Apple to supply some sort of emulator that might handle old or simple apps. Don’t expect it to be a high performance solution.
Apple has gotten rather good at running iOS apps on Intel via XCodes test facilities. They effectively run iOS apps as native X86 apps in that context. This is a pretty clear demonstration that they have minimized machine specific dependencies in their system code. They only developers that will have significant problems are those that ignored Apples guidance on software development and used x86 features directly.
Any ideas on how Apple will handle the X86 code of current apps to run on ARM architecture? I am not educated on this. Is ARM close enough to X86 that the transition will be easy or will it require a Rosetta-like translation framework like the move from Moto 68000 to X86 did. Will we have universal binaries again or something else during the transition?
Microsoft has an X86 emulation layer for ARM Windows. It isn't great, but it's a solution.
A Rosetta-like framework is the most likely.
It can be a lot like the last time.
1. Apps using Apple’s frameworks and Xcode will mostly be a recompile 2. Apps that mostly use Apple’s frameworks, but not Xcode, or use 3rd party libraries, will use a binary translator like Rosetta (switching x86 instructions with ARM instructions at runtime) 3. Apps that only work with macOS/x86 with 3rd party x86 libraries will need to be run in a macOS/x86 VM a la classic. If Apple provides it, presumably, apps can be overlapped, and it won’t be macOS run inside a window.
And once again, the single biggest impediment to success will be Microsoft and Adobe moving their apps to macOS/ARM. If that doesn’t happen, macOS/x86 won’t be successful. Presumably, Apple will just do the work to bring FCPX and LPX over. Plugins may need to use Rosetta for awhile before they are moved over.
I’m of the opinion that Apple will not out a lot of focus on emulation of X86. They have been really hammering home the idea to developers that they write to Apples APIs and not the underlying hardware. For the developers that have listened apps for ARM will be a short recompile away with rather quick debugging. So expect that the vast majority of apps will be native when the hardware is released.
You then have two problems. One is apps with no developer (abandoned ware) and the developers that couldn’t be bothered to listen. For these guys I expect emulation will be provided but I don’t see it as being high performance or something Apple puts a lot of effort into.
There is a alternative reality with respect to emulation. Here Apple could imbue its ARM chips with special instructions to accelerate emulation of other processors. As we saw with JavaScript sometimes it only takes one or two instructions to accelerate a program. In this case Apple might add a few instructions and features for generic emulation acceleration. I say generic because done right these sorts of features could be used to accelerate the emulation of all sorts of processors and even virtual machines.
In a nut shell ARM code is nothing to worry about. For me the bigger issue is that Apples design direction for Mac hardware is unacceptable. The have become too locked down and hamstrung to consider anymore. I really need to see Apple make a course change here. Sadly I suspect that they will go the other way with ARM based hardware.
There is also (I believe) a substantial cost savings to Apple here
Assumptions:
- Half of Macs use internally developed Apple CPU: 10M/yr (the other half stays on Intel) - Current cost Apple pays per Intel chip: $200 (likely higher) - Cost to Apple to manufacture new chip at TMSC: $30 (likely lower) - Dedicated Apple CPU chip employees and cost: 300 employees x $400K/yr fully weighted cost = $120M
Total Intel Cost: 10M x $180 = $2B Total internal Apple Cost: 10M x $30 = $300M + $120M = $420M
Total Annual Savings: $2B - $420M = $1.6 Billion
It would be $3.2 Billion if Apple were to move it all internal. That would increase overall gross margin of the company by ~ 1%. It would be a huge financial win. But more importantly, it gets Apple untangled from the mess that is Intel
Not included here is the massive R&D effort/spend to get to launch. Maybe this is one of the driver's of Apple R&D spend exploding over the last 5 years
I suspect that your chip costs are wrong. This mainly because Apple is always on TSMC bleeding edge processes and Apples chips are rather large. Apple pays for being first so I’d double that processor cost. Maybe even more depending upon how it is packaged, if Apple does a multi chip module we could be seeing a huge jump above $30.
As for Apple and Intel’s chips that will be a lot harder to determine. For one Intel is under the watchful eyes of regulators and can not offer any discounts beyond those that are volume based. So Apple will pay about the same as any other builder with about the same volume. The sticker here is that Apple often buys Intel hardware not sold to anybody else. In any event I suspect their average price might be a bit more than $200 a crack.
As for R&D spending who knows where it all goes. Like the pentagon Apple likely has black projects we don’t know about. I kinda like to believe Apples rumored car development is more about autonomous robots than cars.
I wonder why most of commenters worry about x86 to arm code conversion.
Most of big company already invest iOS and Android product.
If Apple make arm base mac then this is not for professional target. It more likely directly compete with chrombook.
For the school kids to carry iPad with clumsy cover keyboard will not work. They meed raw bust laptop like keyboard.
So A14 or higher can perform like 7 or 8th gen i3 or i5 then I think this will be big hit.
the school already using cloud base office product either from Google or Microsoft. So there is no issue for x86 code base stuff.
As long as Apple can produce this under $500-600 with screen size 12-13' then I think lots of people might buy this instead iPad.
Since iOS 13 supports mouse interface, Apple can gesture touch pad to deal with touch base iOS functions.
The arm cpu bottle neck is voltage but if this become laptop's cpu with proper cooling solution I don't think there is performance issue as most of you thought.
Comments
However, going ARM will allow Apple to do other things, improve other features that may drive more sales. If you have ever seen an iPad Pro 12.9 logic board, it is about half as small as what you see on a 13” laptop with an x86 board, while being about as performant. They can make thinner and lighter 13” laptops in the 1.5 to 2 lb range. Or they can make a keyboard that has the same amount of travel as an external keyboard. A dual display clamshell can be made that is thin, light, and has sweet spot battery life. That extra volume can be used for more storage, more I/O, more things that can be placed in what used to be space for the logic board.
Would be kind of boring if it was just a regular laptop design.
I know patents are not a guarantee, but from many of the more recent laptop patents filed by Apple that I have seen, I believe a dual-display device is the end goal.
Playing games or shooting video at 4K continuously will tax the I/O and heat up a device into its thermal envelope in a jiffy.
As a previous user mentioned, A sub $500 iPad w/a keyboard is meant to compete with Chromebook.
- Intel 10nm node = TSMC 7nm node
- Intel 10th gen Ice Lake mobile SKU’s are already shipping
- Intel integrated UHD graphics and Iris graphics are improving at a fast clip.
Adding thunderbolt, and Mac OS grade I/O combined with Apple’s HUGE profit margins and.........you end up with a lot of work for nothing. Seems more like an engineering exercise designed to extract more concessions out of Intel for a semi-custom CPU with hardware level extensions that MacOS can exploit.
Mac’s already run the ARM based T2 as a coprocessor. Servers use ARM based accelerator cards to speed up functions. What if x86 and ARM cores could be combined on the same SoC package?
Or, Apple just buys AMD.
What? So, say, Apple builds something and it doesn’t sell. Apple stops making it. Where’s the dictatorship?
Apple's recent tools for bringing iOS apps to MacOS might be experimental testing grounds for taking native iOS/ iPad OS apps into a more traditional computer environment, like a new aMac. Perhaps they will branch out iOS to a laptop format, the way thy branched out iOS to iPad OS - rather than taking the big MacOS and bringing that to the new Arm based computer. This way they could also kinda reboot. Sound cumbersome to pull off.. but I think if the'll be changing to their own ARM processors, they might be totally Apple and think different, think grand, and reboot again. Buuuut... without Steve Jobs at the reigns... sounds perhaps more likely to just port Mac OS 😅
So you're half right: individual core performance will always matter for real-world applications, and it's this fact that made me laugh at the core wars octocore Android phones being a useful thing compared to the few faster iPhone cores, even if the SOCs were capable of keeping those CPU cores fed with data and instructions (no chance of that).
With likely few or no significant exceptions, the costs will be a simple change of an Xcode build configuration and a rebuild, followed by a full application test suite just to be sure: trivial.
1. iPad (ARM)
2. macPad (ARM)
3. Mac Mini (ARM)
4. iMac (ARM)
6. MacBook Pro (Intel)
7. iMac Pro (Intel)
8. Mac Pro (Intel)