I welcome this for the Mac Pro. I would upgrade my i9 hex core machine for a powerful ARM variant. Intel is a “has been”. I much prefer AMD in the x86 world over Intel. I think providing a hardware accelerated solution for x86 emulation on an ARM platform would be appropriate to bridge the gap until most relevant software has been recompiled.
This is around the same multi-core performance as a Macbook Pro and Mac mini. A Mac Pro would typically offer 3-4x this. Even a top-end iMac Pro is double.
Although the performance is described as desktop-class, the iDevice chips are already in that range so this could easily just be a chip for 2019 iPad Pros:
The iOS benchmarks have a battery test. This benchmark would be 40% faster than current iPad Pros. While that would be quite a large increase these days, it's not that unusual. It could even be a sample of a 2020 5nm iDevice chip.
It would be nice to have as an option in a Mac Pro however. Intel charges $2-3k for their chips. If Apple could bundle a board with 4-8 of these chips using about 10W per chip, the chips would cost no more than $800 and for raw processing would outperform Intel's options and be easily $5k cheaper. It would be nice to be able to buy a Thunderbolt box of ARM chips like that too so that for raw CPU processing, you can just buy a $1k box and have $10k of workstation performance and you could buy one for each TB port. It would need software recompiled for it but scientific computing, rendering, video encoding etc use non-UI binaries that would be easily recompiled for it. This would also allow Apple to add their own custom hardware processing. H.265 would be added anyway but also standard video processing, possibly raytracing like NVidia RTX and AI processing.
I firmly believe that Apple has had a MacOS/ARM machine in development for several years. Just like it did with the IBM->Intel, when the time is right and the performance is at least on par with Intel's offerings, they will introduce that machine. It only makes sense that it is the next logical step in Apple's eventual divorce from major chip suppliers like Qualcomm and Intel. Intel has shot itself in the foot way too many times and proven to be a real headache for Apple in having a constant introduction of newer x86 chips.
My only hope is that there will still be some kind of compatibility with x86 instruction set. I know I'm part of a minority group, but I do have all my Macs (three of them) running Windows for certain development tools I use.
Either way, the day Apple jettisons Intel's CPU, that will be the blast heard around the world, and a good time to short Intel.
I was like you then late last year I bought a Dell PC, i7, 32 GB RAM and Nvidia GTX 1080 (pretty cheap really) and stuck it on the LAN with all my Macs and gave up on VMWare. It has the advantage I can play GTA V in the evenings. Bring the Mac Pro with Apple CPU on!
I’m not a gamer, which I agree the Wintel platform is superior. For everything else, it’s Mac Hardware for me and I have been very happy with VMware. It’s the best windows machine I owned.
No argument. I still use VMWare from time to time and actually ... these days to run Sierra mostly so I can use my Fujitsu SnapScan as the a-holes have never updated the drivers beyond Sierra.
Guys, guys, guys! Remember when Apple announced its transition to Intel, they made a special "developers" Mac? They put an Intel Pentium 4 in the Power Mac G5 enclosure. What if this chip represents a similar "developers" Mac for the transition to ARM?
Seems to me that if you’re going to transition to ARM, you need enough horsepower to handle x86 emulation for apps not recompiled to support ARM. I suppose this would be trivial to recompile existing apps using an updated version of Xcode, or to compile iOS apps to Mac soon which already using ARM instructions.
Despite what many people think, most apps are not a recompile away. Yes, small, simpler apps may be. But think about all of the demo’s we’ve seen over the years from software developers who, on stage, said; ...and we did this in one weekend, it was so easy! And then the actual app didn’t arrive for 6 months. Because it’s NOT so easy. Recompiling for a different chip family is never easy.
The instruction set is different. Some instructions aren’t even similar. X86 is Ciscier, while ARM is Riscier. Moving from one to the other is not simple for bigger apps. So big apps such as Office, and Photoshop, and Final Cut will have to run under emulation for some time, at half speed. We’ve seen this several times now, so don’t be surprised.
putting these into a Macbook, which uses a weak CPU could work, because this would be a lot more powerful, so that emulation would be fine. Big apps likely wouldn’t suffer much.
Your negativity in my mind is unwarranted. There certainly will be problem apps however Apple has been guiding the industry to this goal for years. That is apps that can be built and ran on different architectures. I would expect most of Mac App Store to have native binaries at launch.
As for developers and easy, never accept the ranting and ravings from a dog and pony show. However let’s not forget that new technologies often lead to major App refactoring. Often the delays are about new functionality.
I would fully expect that all key apps would be native at launch. That includes the entire ecosystem of Apple marketed apps and all of the operating system. I just don’t see Apple screwing this up.
An unsubstantiated, and highly suspect, "leak" on Friday claims to reveal benchmarks from a pair of desktop-class ARM processors supposedly designed by Apple, offering what could be the first look at A-series silicon destined for Mac.
Outlined in a post to Slashleakson Friday are supposed Geekbench benchmarks for ARM big.LITTLE chips with 10- and 12-core architectures.
Information provided by an anonymous uploader claims the 10-core version is clocked at 3.4GHz, while supposed Geekbench screenshots show the 12-core chip, referenced as "APWL2@HmP," running at 3.19GHz. The two application processors achieved respective single-core scores of 7335 and 6912, and multi-core scores of 20580 and 24240.
What device the alleged ARM chips are powering is unknown, but the performance of each falls in line with desktop class hardware. Both processors beat single-core benchmarks set by Apple's 2017 27-inch Retina 5K iMac with 4.2GHz Intel Core i7-7700K, while the purported 12-core ARM chip's mutli-core score bests the 2018 15-inch MacBook Pro with 2.9GHz Intel Core i9-8950HK.
It is unclear if the benchmarks shared today are legitimate, but it should be noted that the uploader joined SlashleaksAppleInsider was unable to verify the leak and does not vouch for its veracity.
Apple has long been rumored to transition Mac away from Intel to a bespoke ARM architecture, but hard evidence of the development process has been elusive.
Last October, analyst Ming-Chi Kuo in a note to investors predicted an ARM-based mac to arrive in 2020 or 2021. More recently, Intel officials in February told Axios they expect the tech giant to make the switch "as soon as next year."
I am sure there are many ARM base laptop/desktop class machines running in Apple HQ. But if Apple really stop using Intel/X86 cpu, that means a big chunk of corporate/power user will stop Apple products for good. The ability to run windows, Linux and other x86 base OS on a quality Mac machine is why these companies willing to pay extra bucks for it, not MacOS.
Will Apple willing to make the switch just for being “I am special” like the good old days? I doubt it. After all, it is not like Intel has bad relationships with apple or not able to improve like Motorola/IBM.
Why do you assume that Windows and Linux will not run on these machines? Seriously I see this posted all the time and frankly we have no evidence that Apple intends to lock out these operating systems. They could of course but it doesn’t make any sense to do so.
Beyond that I really don’t think you understand what a mess the Windows world is right now. Far too many apps do not run on MS newer Windows versions. The industry already has significant transitional issues.
No argument. I still use VMWare from time to time and actually ... these days to run Sierra mostly so I can use my Fujitsu SnapScan as the a-holes have never updated the drivers beyond Sierra.
@MacPro There is an update to Scansnap that was confusing rebranded as Scansnap Home. I found it by accident and it works fine with my Scansnap ix500. It has a slightly different interface and usage which was confusing at first.
Seems to me that if you’re going to transition to ARM, you need enough horsepower to handle x86 emulation for apps not recompiled to support ARM. I suppose this would be trivial to recompile existing apps using an updated version of Xcode, or to compile iOS apps to Mac soon which already using ARM instructions.
Despite what many people think, most apps are not a recompile away. Yes, small, simpler apps may be. But think about all of the demo’s we’ve seen over the years from software developers who, on stage, said; ...and we did this in one weekend, it was so easy! And then the actual app didn’t arrive for 6 months. Because it’s NOT so easy. Recompiling for a different chip family is never easy.
The instruction set is different. Some instructions aren’t even similar. X86 is Ciscier, while ARM is Riscier. Moving from one to the other is not simple for bigger apps. So big apps such as Office, and Photoshop, and Final Cut will have to run under emulation for some time, at half speed. We’ve seen this several times now, so don’t be surprised.
putting these into a Macbook, which uses a weak CPU could work, because this would be a lot more powerful, so that emulation would be fine. Big apps likely wouldn’t suffer much.
While that is likely true, I suspect the majority of Mac users would simply shrug --- because they don't use them. Increasingly the only ones using MS-Office are those who need it to be compatible with their office. For the rest, Apple's free look-alike products will do just fine.
For home use, and even many business cases, Pages is fine. I’ve gotten to the point where I avoid MS Word whenever possible - it’s big, clunky, slow to load and painful to use. The problem is, it’s still more or less an industry standard. Yes, Pages can load and save .docx formatted docs, but things get lost in translation, and many organizations are moving to a platform like Office365.
I’m not in the industry, so I may be wrong, but if Apple were to move to A-series processors for their desktops, my suspicion is that it would increase the complexity of developing both PC and Mac versions of software and potentially reduce the available software base.
Seems to me that if you’re going to transition to ARM, you need enough horsepower to handle x86 emulation for apps not recompiled to support ARM. I suppose this would be trivial to recompile existing apps using an updated version of Xcode, or to compile iOS apps to Mac soon which already using ARM instructions.
Despite what many people think, most apps are not a recompile away. Yes, small, simpler apps may be. But think about all of the demo’s we’ve seen over the years from software developers who, on stage, said; ...and we did this in one weekend, it was so easy! And then the actual app didn’t arrive for 6 months. Because it’s NOT so easy. Recompiling for a different chip family is never easy.
The instruction set is different. Some instructions aren’t even similar. X86 is Ciscier, while ARM is Riscier. Moving from one to the other is not simple for bigger apps. So big apps such as Office, and Photoshop, and Final Cut will have to run under emulation for some time, at half speed. We’ve seen this several times now, so don’t be surprised.
putting these into a Macbook, which uses a weak CPU could work, because this would be a lot more powerful, so that emulation would be fine. Big apps likely wouldn’t suffer much.
Luckily this instruction difference is bridged by a compiler and almost all code is written in C (etc), a higher order language that doesn't depend on a specific instruction set. So, almost all programs, unless they contain hardware accelerated pieces of inline machine code, can be converted with one push of the XCode recompile button. Maybe your confused with ‘porting’ of applications, that's a whole different ballgame and consists of rewriting parts of code to fit a different API. But in this case the APIs are the same. It is also possible to translate x86 machine code directly to ARM, if no source (higher language) code is available, so even third party programs, designated for x86 can be used at almost full speed on ARM (this could also be an OS responsabilty, to translate fat binaries of the wrong kind automatically the first time they run and save this code for future runs).
An unsubstantiated, and highly suspect, "leak" on Friday claims to reveal benchmarks from a pair of desktop-class ARM processors supposedly designed by Apple, offering what could be the first look at A-series silicon destined for Mac.
Outlined in a post to Slashleakson Friday are supposed Geekbench benchmarks for ARM big.LITTLE chips with 10- and 12-core architectures.
Information provided by an anonymous uploader claims the 10-core version is clocked at 3.4GHz, while supposed Geekbench screenshots show the 12-core chip, referenced as "APWL2@HmP," running at 3.19GHz. The two application processors achieved respective single-core scores of 7335 and 6912, and multi-core scores of 20580 and 24240.
What device the alleged ARM chips are powering is unknown, but the performance of each falls in line with desktop class hardware. Both processors beat single-core benchmarks set by Apple's 2017 27-inch Retina 5K iMac with 4.2GHz Intel Core i7-7700K, while the purported 12-core ARM chip's mutli-core score bests the 2018 15-inch MacBook Pro with 2.9GHz Intel Core i9-8950HK.
It is unclear if the benchmarks shared today are legitimate, but it should be noted that the uploader joined SlashleaksAppleInsider was unable to verify the leak and does not vouch for its veracity.
Apple has long been rumored to transition Mac away from Intel to a bespoke ARM architecture, but hard evidence of the development process has been elusive.
Last October, analyst Ming-Chi Kuo in a note to investors predicted an ARM-based mac to arrive in 2020 or 2021. More recently, Intel officials in February told Axios they expect the tech giant to make the switch "as soon as next year."
I am sure there are many ARM base laptop/desktop class machines running in Apple HQ. But if Apple really stop using Intel/X86 cpu, that means a big chunk of corporate/power user will stop Apple products for good. The ability to run windows, Linux and other x86 base OS on a quality Mac machine is why these companies willing to pay extra bucks for it, not MacOS.
Will Apple willing to make the switch just for being “I am special” like the good old days? I doubt it. After all, it is not like Intel has bad relationships with apple or not able to improve like Motorola/IBM.
Why do you assume that Windows and Linux will not run on these machines? Seriously I see this posted all the time and frankly we have no evidence that Apple intends to lock out these operating systems. They could of course but it doesn’t make any sense to do so.
Beyond that I really don’t think you understand what a mess the Windows world is right now. Far too many apps do not run on MS newer Windows versions. The industry already has significant transitional issues.
I am sure the arm base CPU can run windows and Linux, but most likely with something similar to Rosetta. Power user needs speed and precision which Rosetta or similar programs lack. Unless apple can make the arm cpu run like a x86, otherwise these corporate and power users will most likely disappear. But when an arm cpu runs like a x86. It is not exactly a ARM cpu, isn’t it?
An unsubstantiated, and highly suspect, "leak" on Friday claims to reveal benchmarks from a pair of desktop-class ARM processors supposedly designed by Apple, offering what could be the first look at A-series silicon destined for Mac.
Outlined in a post to Slashleakson Friday are supposed Geekbench benchmarks for ARM big.LITTLE chips with 10- and 12-core architectures.
Information provided by an anonymous uploader claims the 10-core version is clocked at 3.4GHz, while supposed Geekbench screenshots show the 12-core chip, referenced as "APWL2@HmP," running at 3.19GHz. The two application processors achieved respective single-core scores of 7335 and 6912, and multi-core scores of 20580 and 24240.
What device the alleged ARM chips are powering is unknown, but the performance of each falls in line with desktop class hardware. Both processors beat single-core benchmarks set by Apple's 2017 27-inch Retina 5K iMac with 4.2GHz Intel Core i7-7700K, while the purported 12-core ARM chip's mutli-core score bests the 2018 15-inch MacBook Pro with 2.9GHz Intel Core i9-8950HK.
It is unclear if the benchmarks shared today are legitimate, but it should be noted that the uploader joined SlashleaksAppleInsider was unable to verify the leak and does not vouch for its veracity.
Apple has long been rumored to transition Mac away from Intel to a bespoke ARM architecture, but hard evidence of the development process has been elusive.
Last October, analyst Ming-Chi Kuo in a note to investors predicted an ARM-based mac to arrive in 2020 or 2021. More recently, Intel officials in February told Axios they expect the tech giant to make the switch "as soon as next year."
I am sure there are many ARM base laptop/desktop class machines running in Apple HQ. But if Apple really stop using Intel/X86 cpu, that means a big chunk of corporate/power user will stop Apple products for good. The ability to run windows, Linux and other x86 base OS on a quality Mac machine is why these companies willing to pay extra bucks for it, not MacOS.
Will Apple willing to make the switch just for being “I am special” like the good old days? I doubt it. After all, it is not like Intel has bad relationships with apple or not able to improve like Motorola/IBM.
Why do you assume that Windows and Linux will not run on these machines? Seriously I see this posted all the time and frankly we have no evidence that Apple intends to lock out these operating systems. They could of course but it doesn’t make any sense to do so.
Beyond that I really don’t think you understand what a mess the Windows world is right now. Far too many apps do not run on MS newer Windows versions. The industry already has significant transitional issues.
I am sure the arm base CPU can run windows and Linux, but most likely with something similar to Rosetta. Power user needs speed and precision which Rosetta or similar programs lack. Unless apple can make the arm cpu run like a x86, otherwise these corporate and power users will most likely disappear. But when an arm cpu runs like a x86. It is not exactly a ARM cpu, isn’t it?
There are native ARM versions of Linux and Windows. No need to emulate. ARM is now as fast as Intel (x86) and generally much more power efficient allowing longer battery life.
Sorry folks this is Fake! The numbers don't track.
While there are a lot of people who would love to see an ARM based Mac system its going to be still a few years before we see one. Apple would be smart focusing on the low end systems first.
Frankly, I don't see any true benefit until the apps are running RISC based code. Running in emulation would burn any true CPU improvement.
We still have the limits of physics here both A series and Intel chips can't run the chip any faster until the issue of heat is controlled.
Seems to me that if you’re going to transition to ARM, you need enough horsepower to handle x86 emulation for apps not recompiled to support ARM. I suppose this would be trivial to recompile existing apps using an updated version of Xcode, or to compile iOS apps to Mac soon which already using ARM instructions.
Despite what many people think, most apps are not a recompile away. Yes, small, simpler apps may be. But think about all of the demo’s we’ve seen over the years from software developers who, on stage, said; ...and we did this in one weekend, it was so easy! And then the actual app didn’t arrive for 6 months. Because it’s NOT so easy. Recompiling for a different chip family is never easy.
The instruction set is different. Some instructions aren’t even similar. X86 is Ciscier, while ARM is Riscier. Moving from one to the other is not simple for bigger apps. So big apps such as Office, and Photoshop, and Final Cut will have to run under emulation for some time, at half speed. We’ve seen this several times now, so don’t be surprised.
putting these into a Macbook, which uses a weak CPU could work, because this would be a lot more powerful, so that emulation would be fine. Big apps likely wouldn’t suffer much.
Your negativity in my mind is unwarranted. There certainly will be problem apps however Apple has been guiding the industry to this goal for years. That is apps that can be built and ran on different architectures. I would expect most of Mac App Store to have native binaries at launch.
As for developers and easy, never accept the ranting and ravings from a dog and pony show. However let’s not forget that new technologies often lead to major App refactoring. Often the delays are about new functionality.
I would fully expect that all key apps would be native at launch. That includes the entire ecosystem of Apple marketed apps and all of the operating system. I just don’t see Apple screwing this up.
I don’t understand why you would think that. In the past, every time Apple has done this, the big apps took about a year to arrive, including Apple’s own. Apps of intermediate size took months. Only smaller apps were available fairly quickly. We can even look at iOS. When Apple announced that 32 bit apps would not be allowed a year later, many apps were still not 64 bits when the time arrived. Many took months, and many never came. And that was the same processor family. With over a year’s notice.
Seems to me that if you’re going to transition to ARM, you need enough horsepower to handle x86 emulation for apps not recompiled to support ARM. I suppose this would be trivial to recompile existing apps using an updated version of Xcode, or to compile iOS apps to Mac soon which already using ARM instructions.
Despite what many people think, most apps are not a recompile away. Yes, small, simpler apps may be. But think about all of the demo’s we’ve seen over the years from software developers who, on stage, said; ...and we did this in one weekend, it was so easy! And then the actual app didn’t arrive for 6 months. Because it’s NOT so easy. Recompiling for a different chip family is never easy.
The instruction set is different. Some instructions aren’t even similar. X86 is Ciscier, while ARM is Riscier. Moving from one to the other is not simple for bigger apps. So big apps such as Office, and Photoshop, and Final Cut will have to run under emulation for some time, at half speed. We’ve seen this several times now, so don’t be surprised.
putting these into a Macbook, which uses a weak CPU could work, because this would be a lot more powerful, so that emulation would be fine. Big apps likely wouldn’t suffer much.
Luckily this instruction difference is bridged by a compiler and almost all code is written in C (etc), a higher order language that doesn't depend on a specific instruction set. So, almost all programs, unless they contain hardware accelerated pieces of inline machine code, can be converted with one push of the XCode recompile button. Maybe your confused with ‘porting’ of applications, that's a whole different ballgame and consists of rewriting parts of code to fit a different API. But in this case the APIs are the same. It is also possible to translate x86 machine code directly to ARM, if no source (higher language) code is available, so even third party programs, designated for x86 can be used at almost full speed on ARM (this could also be an OS responsabilty, to translate fat binaries of the wrong kind automatically the first time they run and save this code for future runs).
No, that’s simply not true. I don’t get it. I’ve been through this several times before over the decades, and it was never true. Every time, we get the wags who exclaim that it’s only a recompile away. But that’s only true for smaller apps. It’s never true for more complex apps. There are a lot of reasons. Many developers, including Apple, don’t follow the rules. When this change happens, they have to scramble to figure out ways around their screwups.
It’s more complex than that though. Like it or not, C doesn’t do what you think it does. It’s not Java. Also, apps are written in various versions of Swift, and other languages.
you can’t just translate machine code around like that. There are often instructions that are not comparable, and it can be difficult to work around that.
I have not read all comments so hope not doubling anyone but I feel some connection with Apple AR plans, And maybe VR as well. It is said they will introduce AR glasses/headset in 2020. They will need machines to connect to with enough horse power. Current state of VR on mac is nothing to write home about. So besides new iDevices there can be VR gaming potential on AMR Macbooks or Minis..And maybe Apple TV as well.
Seems to me that if you’re going to transition to ARM, you need enough horsepower to handle x86 emulation for apps not recompiled to support ARM. I suppose this would be trivial to recompile existing apps using an updated version of Xcode, or to compile iOS apps to Mac soon which already using ARM instructions.
Despite what many people think, most apps are not a recompile away. Yes, small, simpler apps may be. But think about all of the demo’s we’ve seen over the years from software developers who, on stage, said; ...and we did this in one weekend, it was so easy! And then the actual app didn’t arrive for 6 months. Because it’s NOT so easy. Recompiling for a different chip family is never easy.
The instruction set is different. Some instructions aren’t even similar. X86 is Ciscier, while ARM is Riscier. Moving from one to the other is not simple for bigger apps. So big apps such as Office, and Photoshop, and Final Cut will have to run under emulation for some time, at half speed. We’ve seen this several times now, so don’t be surprised.
putting these into a Macbook, which uses a weak CPU could work, because this would be a lot more powerful, so that emulation would be fine. Big apps likely wouldn’t suffer much.
Luckily this instruction difference is bridged by a compiler and almost all code is written in C (etc), a higher order language that doesn't depend on a specific instruction set. So, almost all programs, unless they contain hardware accelerated pieces of inline machine code, can be converted with one push of the XCode recompile button. Maybe your confused with ‘porting’ of applications, that's a whole different ballgame and consists of rewriting parts of code to fit a different API. But in this case the APIs are the same. It is also possible to translate x86 machine code directly to ARM, if no source (higher language) code is available, so even third party programs, designated for x86 can be used at almost full speed on ARM (this could also be an OS responsabilty, to translate fat binaries of the wrong kind automatically the first time they run and save this code for future runs).
No, that’s simply not true. I don’t get it. I’ve been through this several times before over the decades, and it was never true. Every time, we get the wags who exclaim that it’s only a recompile away. But that’s only true for smaller apps. It’s never true for more complex apps. There are a lot of reasons. Many developers, including Apple, don’t follow the rules. When this change happens, they have to scramble to figure out ways around their screwups.
It’s more complex than that though. Like it or not, C doesn’t do what you think it does. It’s not Java. Also, apps are written in various versions of Swift, and other languages.
you can’t just translate machine code around like that. There are often instructions that are not comparable, and it can be difficult to work around that.
really, your view on this is simplistic.
Simplistic, yes ok. It will take some extra time to give a more comprehensive view. But in essence its what I posted before. Your right that C is a difficult language and translating an elaborate program to another machine language can reveal bugs never noticed before (using different compilers for the same target architecture may do the same), and it can take a lot of time to work that out. The added bonus in this case is that a better program will eventually run on ARM. Directly translating machine code has its own specific difficulties of course, no one argues that it is easy to do, but it is certainly possible (I know I can write the code to do that, I worked for a compiler company ...).
These obviously aren't benchmarks for a new apple laptop but I guess good for page views and clicks. That said I can't wait to see how this eventually shakes out. I just can't imagine desktops and pro grade laptops running arm processors. Aside from the cpu, how do you handle the graphics? Apple isn't going to be able to create anything that beats Nvidia or AMD. The only way I see this happening is if Apple is creating a new class of ultrabooks that join the ranks of what microsoft is trying to accomplish with windows on arm.
On top of that, what happens if software performance is terrible on the arm chips? It would be catastrophic for Apple if an Adobe product worked twice as fast on x86. Like I said, it will be interesting to see how all of these factors are addressed. And I'm just scraping the surface.
Why would it be catastrophic? Few people use any Adobe product except Reader and there are plenty of substitutes for that.
Apple is about meeting people's needs, not performance specs.
Pros need performance and last time I checked Pros are still a market Apple caters to
Comments
Although the performance is described as desktop-class, the iDevice chips are already in that range so this could easily just be a chip for 2019 iPad Pros:
https://browser.geekbench.com/ios-benchmarks
https://browser.geekbench.com/mac-benchmarks
The iOS benchmarks have a battery test. This benchmark would be 40% faster than current iPad Pros. While that would be quite a large increase these days, it's not that unusual. It could even be a sample of a 2020 5nm iDevice chip.
It would be nice to have as an option in a Mac Pro however. Intel charges $2-3k for their chips. If Apple could bundle a board with 4-8 of these chips using about 10W per chip, the chips would cost no more than $800 and for raw processing would outperform Intel's options and be easily $5k cheaper. It would be nice to be able to buy a Thunderbolt box of ARM chips like that too so that for raw CPU processing, you can just buy a $1k box and have $10k of workstation performance and you could buy one for each TB port. It would need software recompiled for it but scientific computing, rendering, video encoding etc use non-UI binaries that would be easily recompiled for it. This would also allow Apple to add their own custom hardware processing. H.265 would be added anyway but also standard video processing, possibly raytracing like NVidia RTX and AI processing.
As for developers and easy, never accept the ranting and ravings from a dog and pony show. However let’s not forget that new technologies often lead to major App refactoring. Often the delays are about new functionality.
I would fully expect that all key apps would be native at launch. That includes the entire ecosystem of Apple marketed apps and all of the operating system. I just don’t see Apple screwing this up.
Beyond that I really don’t think you understand what a mess the Windows world is right now. Far too many apps do not run on MS newer Windows versions. The industry already has significant transitional issues.
https://www.fujitsu.com/uk/products/computing/peripheral/scanners/scansnap/software/sshome/
I’m not in the industry, so I may be wrong, but if Apple were to move to A-series processors for their desktops, my suspicion is that it would increase the complexity of developing both PC and Mac versions of software and potentially reduce the available software base.
So, almost all programs, unless they contain hardware accelerated pieces of inline machine code, can be converted with one push of the XCode recompile button.
Maybe your confused with ‘porting’ of applications, that's a whole different ballgame and consists of rewriting parts of code to fit a different API. But in this case the APIs are the same.
It is also possible to translate x86 machine code directly to ARM, if no source (higher language) code is available, so even third party programs, designated for x86 can be used at almost full speed on ARM (this could also be an OS responsabilty, to translate fat binaries of the wrong kind automatically the first time they run and save this code for future runs).
ARM is now as fast as Intel (x86) and generally much more power efficient allowing longer battery life.
More convoluted: they ran the iOS version hosted on “macOS/ARM”
Cinspiracist explanation: they took the bytecode for GB and compiled it to macOS/ARM
Mundane explanation: it’s just iPad prototype hardware
While there are a lot of people who would love to see an ARM based Mac system its going to be still a few years before we see one. Apple would be smart focusing on the low end systems first.
Frankly, I don't see any true benefit until the apps are running RISC based code. Running in emulation would burn any true CPU improvement.
We still have the limits of physics here both A series and Intel chips can't run the chip any faster until the issue of heat is controlled.
No, that’s simply not true. I don’t get it. I’ve been through this several times before over the decades, and it was never true. Every time, we get the wags who exclaim that it’s only a recompile away. But that’s only true for smaller apps. It’s never true for more complex apps. There are a lot of reasons. Many developers, including Apple, don’t follow the rules. When this change happens, they have to scramble to figure out ways around their screwups.
It’s more complex than that though. Like it or not, C doesn’t do what you think it does. It’s not Java. Also, apps are written in various versions of Swift, and other languages.
you can’t just translate machine code around like that. There are often instructions that are not comparable, and it can be difficult to work around that.
really, your view on this is simplistic.
So besides new iDevices there can be VR gaming potential on AMR Macbooks or Minis..And maybe Apple TV as well.
But in essence its what I posted before.
Your right that C is a difficult language and translating an elaborate program to another machine language can reveal bugs never noticed before (using different compilers for the same target architecture may do the same), and it can take a lot of time to work that out. The added bonus in this case is that a better program will eventually run on ARM.
Directly translating machine code has its own specific difficulties of course, no one argues that it is easy to do, but it is certainly possible (I know I can write the code to do that, I worked for a compiler company ...).