"All that would remain would be backwards-compatibility measures similar to "Rosetta" allowing for PowerPC code to run on Intel processors" - there's an important difference here: Rosetta worked because the x86 processor was a lot faster than the PowerPC users were used to, so they didn't perceive much of a slowdown. But as you mentioned yourself, the A11 is "only" about on par with a low-end x86 i7 from a pure performance perspective - so with emulation, a user would definitely notice a degradation. Mitigating things (a lot?) are that most apps probably spend the majority of their CPU cycles inside Apple's APIs - and when they make a call into Apple's code, that can run at native speeds/non-emulated.
The "small-battery" powered A11 is on par with a low-end x86 i7. We don't know what it could do running on a system that doesn't always run on battery power, and can be optimized for performance and/or battery life.
Xcode today compiles in both ARM and x68. Fixing apps to be multi platform would be pretty minor for most developers today. It would be a bit more of a challenge for some bigger stuff like MS Office and Adobe CS Apps, but it wouldn't be too difficult with todays Xcode to have cross platform binaries for everything. It would take us back to said binaries being 2x+ the size again though.
The funy thing about this is neither Samsung or Qualcomm make more powerful versions of their ARM processors for things like tablet. They are already way behind the A11. If Apple makes an ARM MacBook (with the likely A11X or A12X) it’s going to be far more powerful than any Windows laptop using ARM.
"All that would remain would be backwards-compatibility measures similar to "Rosetta" allowing for PowerPC code to run on Intel processors" - there's an important difference here: Rosetta worked because the x86 processor was a lot faster than the PowerPC users were used to, so they didn't perceive much of a slowdown. But as you mentioned yourself, the A11 is "only" about on par with a low-end x86 i7 from a pure performance perspective - so with emulation, a user would definitely notice a degradation. Mitigating things (a lot?) are that most apps probably spend the majority of their CPU cycles inside Apple's APIs - and when they make a call into Apple's code, that can run at native speeds/non-emulated.
The "small-battery" powered A11 is on par with a low-end x86 i7. We don't know what it could do running on a system that doesn't always run on battery power, and can be optimized for performance and/or battery life.
Xcode today compiles in both ARM and x68. Fixing apps to be multi platform would be pretty minor for most developers today. It would be a bit more of a challenge for some bigger stuff like MS Office and Adobe CS Apps, but it wouldn't be too difficult with todays Xcode to have cross platform binaries for everything. It would take us back to said binaries being 2x+ the size again though.
Not necessarily, it can be distributed in bitcode to the App store and the app store gives you ARM or Intel binary. For 3rd party installation, it can be compiled down to binary bitcode (LLVM) and then the installer translate that LLVM "binary code" into native code.
The funy thing about this is neither Samsung or Qualcomm make more powerful versions of their ARM processors for things like tablet. They are already way behind the A11. If Apple makes an ARM MacBook (with the likely A11X or A12X) it’s going to be far more powerful than any Windows laptop using ARM.
Why give this an 'A' designation at all? Why can't they have a D1 (like they've done with their other ARM designs) that has a lot more transistors, higher clock rate, more RAM, and much higher thermals than the A-series while still being well below what Intel offers for the current MacBook Air? There are also plenty of features that could be added to support a desktop environment like direct x86_64 virtualization or a discrete GPU.
For this to really matter you need full MS Office compatibility including Excel macros or many businesses still couldn't switch to ARM.
And yet iDevices not only thrive in businesses, but in the enterprise. Apparently your assertion of "need" isn't as absolute as you make it out to be. You've also excluded the most common customer base for the Mac in your statement.
It would be a bit more of a challenge for some bigger stuff like MS Office and Adobe CS Apps, but it wouldn't be too difficult with todays Xcode to have cross platform binaries for everything.
Adobe CC apps are not built with Xcode, but they have already demonstrated that they can build some pretty nice iOS apps, presumably using Xcode.
The funy thing about this is neither Samsung or Qualcomm make more powerful versions of their ARM processors for things like tablet. They are already way behind the A11. If Apple makes an ARM MacBook (with the likely A11X or A12X) it’s going to be far more powerful than any Windows laptop using ARM.
Why give this an 'A' designation at all? Why can't they have a D1 (like they've done with their other ARM designs) that has a lot more transistors, higher clock rate, more RAM, and much higher thermals than the A-series while still being well below what Intel offers for the current MacBook Air? There are also plenty of features that could be added to support a desktop environment like direct x86_64 virtualization or a discrete GPU.
The designation is irrelevant. The fact Apples existing ARM processors are already vastly superior to anything Samsung or Qualcomm has is what’s important. Where is Microsoft going to turn flor more powerful ARM processors if they want to make Windows on ARM a relevant product?
Apple quietly added in the ability for it to generate the application code to any processor when it included 'bitcode' as part of the App Store submission process. For apps on the Mac App Store that added this, those apps can be re-generated for the ARM from the x86 code. All of this is based on the LLVM work that Apple funded years ago.
The cutover from X86 to ARM has been well-planned by Apple for years and, when it happens, I suspect that the transition will be the smoothest ever. I lived through Rosetta and it was as good as it could be made. The approach Apple is planning will make that look like the stone age.
This is a myth. The bitcode in App Store only allows Apple to optimize apps when a CPU has newer instruction, like between every iPhone release. It can not magically make them work on a different architecture.
Early rumors about the ARM-powered laptop line suggested that Intel was going to include a X86 32-bit emulator when the units shipped.
For this to really matter you need full MS Office compatibility including Excel macros or many businesses still couldn't switch to ARM.
Office365 supports any platform on any processor architecture. I'm sure Apple doesn't really care about Macros support in Office, or Office support in general.
The funy thing about this is neither Samsung or Qualcomm make more powerful versions of their ARM processors for things like tablet. They are already way behind the A11. If Apple makes an ARM MacBook (with the likely A11X or A12X) it’s going to be far more powerful than any Windows laptop using ARM.
Why give this an 'A' designation at all? Why can't they have a D1 (like they've done with their other ARM designs) that has a lot more transistors, higher clock rate, more RAM, and much higher thermals than the A-series while still being well below what Intel offers for the current MacBook Air? There are also plenty of features that could be added to support a desktop environment like direct x86_64 virtualization or a discrete GPU.
The designation is irrelevant.
That's probably the dumbest thing I've read on this forum… ever. The designation is relevant because Apple choose for it to be relevant. It's why the A-series isn't the same designation as the W-series, T-Series, or S-series, and why the X in the A-series chips refers to something over the A-series chips without that designation. This is not up for debate!
Apple quietly added in the ability for it to generate the application code to any processor when it included 'bitcode' as part of the App Store submission process. For apps on the Mac App Store that added this, those apps can be re-generated for the ARM from the x86 code. All of this is based on the LLVM work that Apple funded years ago.
The cutover from X86 to ARM has been well-planned by Apple for years and, when it happens, I suspect that the transition will be the smoothest ever. I lived through Rosetta and it was as good as it could be made. The approach Apple is planning will make that look like the stone age.
This is a myth. The bitcode in App Store only allows Apple to optimize apps when a CPU has newer instruction, like between every iPhone release. It can not magically make them work on a different architecture.
Early rumors about the ARM-powered laptop line suggested that Intel was going to include a X86 32-bit emulator when the units shipped.
Intel giving M$ an emulator? Or is this a typo?
The bitcode is the intermediate representation LLVM "assembly language". That intermediate code is then compiled down to ARM instructions or Intel Instructions later in the process. There are issues that have to be dealt with to make sure the LLVM code is portable. First is fixing the ABI to be the same on all platforms (in this case it is the same OS platform on different architectures - so it would be easy for Apple to have the same ABI on both platforms). The ARM processors and the Intel processors used are both 64 bit, which would be an other issue point. The gain you get from optimizing for newer or different Intel only CPUs is rather minor and would not be really worth the effort for the app store (i.e. in the grand scheme of things if this is all it is -- it would be of such a low priority that Apple would never have put that at the top of the list).
An example of LLVM bitcode being transportable would be Google's pNACL, which was done by fixing the ABI for the code to be portable.
A Mac mini would be an ideal entry-level candidate to test the waters with an ARM-based Mac. It's long overdue.
Apple absolutely needs to make sure all the pieces are in place before they even think of it. No matter what they do there will be some incompatibilities -- like not being able to run Windows in a VM or Linux for Intel (which I use for Oracle RDBMS). That said, they have to make sure that other than this limitation - the rest of the process is in place for a year or two in advance of the project since if it is not seamless and mostly hidden from the user -- it will cause platform confusion and confusion is not good at all for business. They are not there yet, I expect when they are you will hear an announcement at WWDC and then there will be a year to get ready before it goes live (if ever).
A Mac mini would be an ideal entry-level candidate to test the waters with an ARM-based Mac. It's long overdue.
Unfortunately, the sales numbers and profit margins on the Mini could never fund the technical effort required to create an entirely new platform. If anywhere, I'd expect to see it in the MacBook line first.
"All that would remain would be backwards-compatibility measures similar to "Rosetta" allowing for PowerPC code to run on Intel processors" - there's an important difference here: Rosetta worked because the x86 processor was a lot faster than the PowerPC users were used to, so they didn't perceive much of a slowdown. But as you mentioned yourself, the A11 is "only" about on par with a low-end x86 i7 from a pure performance perspective - so with emulation, a user would definitely notice a degradation. Mitigating things (a lot?) are that most apps probably spend the majority of their CPU cycles inside Apple's APIs - and when they make a call into Apple's code, that can run at native speeds/non-emulated.
Software compatibility isn't the same issue it was a decade ago, mainly because of Apples push to get developer to use high level languages and API's. In many cases apps can simply be cross compiled. Apple is also requiring bit code submissions which means that they may very well be doing this (JIT like compiles) them selves at download time or dynamically on the device. This is infrastructure that Apple already has in place. Then you have the potential of running iPad software natively in a Window on such a machine and interestingly again Apple has done a lot of work on the developers emulator to hopefully leading to making this user friendly. On top of all of that many users would end up with all the native app they need at launch, this due to Mac OS supplying many of the most important user apps right out of the box.
I any event way to many people are looking towards the past to try to determine if an ARM based machine would be successful in the future, I think the this foolish due to the nature of the business today. In the past people believed in "compatibility" due to MicroSofts lock on the market which is evaporating these days. IOS and the massive app situation there handily demonstrates that it really doesn't matter anymore for the majority of the users out there. Android provides a further point in the discussion.
Probably the third element here is that while native apps are nice and fast hardware is fast enough for interpreted and JIT'ed software. These days software built in Python or Java can often be good enough for the user. The point here is that if Java and Python support at there at ship time you bring another huge collection of software to the table.
Simply put I don't see the i86 problem as being anything significant for the majority of Apples users out there.
The funy thing about this is neither Samsung or Qualcomm make more powerful versions of their ARM processors for things like tablet. They are already way behind the A11. If Apple makes an ARM MacBook (with the likely A11X or A12X) it’s going to be far more powerful than any Windows laptop using ARM.
Why give this an 'A' designation at all? Why can't they have a D1 (like they've done with their other ARM designs) that has a lot more transistors, higher clock rate, more RAM, and much higher thermals than the A-series while still being well below what Intel offers for the current MacBook Air? There are also plenty of features that could be added to support a desktop environment like direct x86_64 virtualization or a discrete GPU.
The designation is irrelevant.
That's probably the dumbest thing I've read on this forum… ever. The designation is relevant because Apple choose for it to be relevant. It's why the A-series isn't the same designation as the W-series, T-Series, or S-series, and why the X in the A-series chips refers to something over the A-series chips without that designation. This is not up for debate!
Nothing like taking my comments completely out of context.
I’m not talking about designations - I’m talking about Apples processor design team being far ahead of everyone else. Whatever they call it (“if” they make it) there won’t be anything from Qualcomm or Samsung that could hope to compete. They can’t even compete with Apples current A-Series processors, let alone any future processor Apple might make, regardless of what they decide to call it.
Is there such thing as "Cooks Law"? It would state that Mac Hardware is always at least 2 years behind PC hardware in processing power and 4 years in graphics.
No that would not make sense as Apple is not 2 years behind PC hardware. They have more access to the latest Intel chips than most vendors. Apple chooses to user lesser CPU and GPU but they in no way lag in their potential to close the bap.
Are MS native applications, and some of there key partners, updating for ARM native? If so, then that would make such a move for Apple better.
Is this only for Windows 10s?
If MS can provide an x86 to ARM emulator (perhaps 32 bit only), then I would give Apple better than even odds they could do so better. They might be able to provide support in silicon to aid this (pure speculation here). Apple's custom ARM chips are also much faster. Apple could also use two Axx chips which still costs less than a single Intel.
S/W compatibility is the biggest challenge here, so having MS go "first" is likely a good move. They can claim some glory, but if Apple decides to also do this, then I give them the benefit of the doubt to be "best".
For Apple it is really about how they want to approach the computing. Do they want to invest in the Mac line in this fashion? I personally think they have to, and hope that they have been waiting until they could get their custom silicon "fast enough" to make the transition seamless.
Now that's an interesting point. Have MS finally got the Office division under control, and agreeing to follow the developer guidelines for their own platform? One of the (many) problems with Windows RT was that while the Windows division were trying to lock down the OS and kill off some legacy APIs, the Office division were refusing to play ball, and so RT had to support whole swathes of legacy code just so Office would run. After all, Windows without Office doesn't make nearly as much money for MS.
Comments
The designation is irrelevant. The fact Apples existing ARM processors are already vastly superior to anything Samsung or Qualcomm has is what’s important. Where is Microsoft going to turn flor more powerful ARM processors if they want to make Windows on ARM a relevant product?
An example of LLVM bitcode being transportable would be Google's pNACL, which was done by fixing the ABI for the code to be portable.
I any event way to many people are looking towards the past to try to determine if an ARM based machine would be successful in the future, I think the this foolish due to the nature of the business today. In the past people believed in "compatibility" due to MicroSofts lock on the market which is evaporating these days. IOS and the massive app situation there handily demonstrates that it really doesn't matter anymore for the majority of the users out there. Android provides a further point in the discussion.
Probably the third element here is that while native apps are nice and fast hardware is fast enough for interpreted and JIT'ed software. These days software built in Python or Java can often be good enough for the user. The point here is that if Java and Python support at there at ship time you bring another huge collection of software to the table.
Simply put I don't see the i86 problem as being anything significant for the majority of Apples users out there.
Nothing like taking my comments completely out of context.
I’m not talking about designations - I’m talking about Apples processor design team being far ahead of everyone else. Whatever they call it (“if” they make it) there won’t be anything from Qualcomm or Samsung that could hope to compete. They can’t even compete with Apples current A-Series processors, let alone any future processor Apple might make, regardless of what they decide to call it.
Clear now?
No that would not make sense as Apple is not 2 years behind PC hardware. They have more access to the latest Intel chips than most vendors. Apple chooses to user lesser CPU and GPU but they in no way lag in their potential to close the bap.