New A6s and the A7 (28nm) are both dual-sourced from Samsung and TSMC. A8 (20nm) will likely also be dual sourced (Apple's CEO is a supply-chain expert).
Samsung was not blindsided by A7. ARMv8 is still new and even ARM itself continues to find aspects of AArch64 (ARMv8) that need to be specified with greater precision or clarity and significant bugs in their own 64-bit core designs. Also there hasn't been much urgency among the Android and Chrome communities for 64-bit software and cores. (Phones really don't need 64-bit. There is however a significant ARMv8 Linux effort). So if there is surprise at the 64-bitness of Apple's A7 it may simply be that Samsung was surprised that Apple would risk publicizing that their premier product was ARMv8 when the architecture itself, let alone the open-source compiler and low-level libraries, are still technically immature. Hence Samsung's "ARMv8 in the fullness of time" attitude. I don't have knowledge of Apple's internal ARM software ecosystem, but it seems by this 64-bit A7 announcement that Apple is either trying to use 64-bitness as a diversion, and/or more likely, to demonstrate that their proprietary ARMv8 software environment is mature enough to workaround the bugs and ready to take on iOS, OS-X and desktop/laptop class productivity apps like Numbers, Keynote, etc. That it is a very short step from here to A7-based OS-X low-tier high-volume MacBooks is clearly not lost on Intel. At a minimum, Apple's MacBook processor pricing from Intel will now be more as if they were dual-sourced. As one of the possible second sources (among other reasons), Samsung stands to benefit from Apple's announcement and Samsung knows it.
The surprise here, although it shouldn't be in Apple's case (especially to AI readers), isn't the first mass production ARMv8 cores, as difficult as that was, it is the ARMv8 software and everything that goes into it. Hats off to Apple for being first to both and hats off to Apple's leaders for using that technical achievement to increase their leverage over processor pricing from both Samsung and Intel at the same time.
Your first post. You claim to know a lot but didn't provide any links to backup up anything.
I learned a lot from this article. Incendiary, but completely brilliant and thoroughly researched. It really does show you how tech journalism has devolved into regurgitating press releases. People aren't thinking deeply, strategically or long term.
I have always suspected Apple were playing the long game and Samsung were running a food fight; throwing mud and seeing what sticks. I didn't realise Samsung were not even taking the time to lay the foundations in their manufacturing division. I've felt for a while that Samsung is very much at risk of tripping over it's own short-sighted success. Too quick to grab this sale at the expense of the next ten. What happens when you run out of poorly-implemented ideas? What happens when your gimmicks start impacting adversely on battery life? How do you convince someone with a 6-inch phone to upgrade? Sell them a 7/8/9/10-inch phone? Sell adjunct accessories with no inherent reason for being? Clearly their strategy has diminishing returns.
People will eventually tire of complicated, poorly-implemented gimmicks. And when they do Apple is ready to sell them a functional, integrated solution from a family of devices at the optimal crux of design, usability, features, battery life and cost.
Siri has been panned but I suspect it's a sleeper hit waiting to happen. Apple Maps was an uncomfortable move forced by Google withholding turn-by-turn data and wanting to implement steep charges for vendors accessing its map data. Though much maligned, Apple Maps was at least successful at manoeuvring Google to provide turn-by-turn data to iPhone users, which was the entire point.
Apple will soon build themselves into a position where the have the volume, proprietary hardware and power efficiency such that no one will be able to compete in terms of form-factor, battery life and, eventually, cost.
Java has always been 64-bit (long data types), and the Java VM has supported 64-bit addressing for years due to Java's use in the enterprise. Dalvik adheres to this spec and supports 64-bit data types and addresses. For application developers on Android, you won't even need to recompile software if it uses no native code, you'll get 64-bit use automatically once Dalvik is deployed at 64-bit.
But Dalvik runs on top of Linux, so the question is, is Linux 64-bit ready? Yes, it was the first consumer OS to be 64-bit, before Apple and Microsoft. What is usually not 64-bit bit ready are proprietary binary device drivers that you can from Qualcomm, Nvidia, et al.
But, there is evidence this isn't going to be a problem. The Android x86 project shipped Android running on 64-bit x86 AMD/Intel chips a long time ago and it works.
Android will have an easier time moving to 64-bit (for Java based software, not NDK software) precisely because it is virtualized. It's like asking when will Javascript sites work on 64-bit, and the answer is, as soon as the Javascript VM is modified to leverage it, everything will benefit automatically. The stuff about needing Oracle is utter nonsense. Oracle has nothing to do with Android's Java implementation, and Oracle's implementation of Java is already 64-bit capable and has been for years.
What I find interesting is, when Apple is not the first to market (multicores, bigger ram, bigger screens, etc), then "specs don't matter" and Apple is not "following", but when Apple is first, all of a sudden, specs are the most important thing in the world, and anyone who was thinking the same thing, but late out of the gate is a copycat.
The reality is, 64-bit was inevitable, as mobile phones are already within a factor of 4 of the upper RAM limit, and ARMv8 was specced out in 2011 and vendors licensed SoCs in 2012 with predictions of shipping in 2014. Apple made it first, but being first out of the gate isn't always best either. It's like when NVidia and ATI used to release ultra powerful GPUs, but no games could really leverage them to the fullest, because it would fragment the market against mostly everyone else who had lower end HW. 64-bit on the 5S is going to give only modest speedups for the time being, nothing like the 2x quoted.
What's missing from this cheery discussion is the effect that pushing bigger die sizes with more transistors and switching fabs has on yields. The iPhone 5s seems to indicating short supply, this is due to either the fingerprint sensor, the 64-bit CPU, or a combination of both. My guess is the A7 is having yield problems. TSMC is notorious for this, and NVidia and ATI which both used TSMC used to have to frequently respin their silicon when they started hitting +1billion trannies. The more trannies and die area, the higher the probability of defects.
Thus, the A7 may in fact be costing Apple delays in parts and margins, because the more bad chips that come off of a wafer, the worse the margins. When most of the industry goes 64-bit in 2014, no one's going to care that Apple was first, just like no one cared who had the first dual core, quad core, or octa-core. Consumers don't care, only fanboys do, so they can engage in continuous penis measuring contests.
The iPhone 5S confers no benefit in battery life. Imagine if instead of doubling the number of transistors, Apple had instead, used the new semiconductor process to end up with a fall smaller SoC, it would drain less power, and be cheaper, and battery life would be greater. The question needs to be asked, does the iPhone already perform well enough? Does it really need 2x more CPU? Will consumers really notice that, or maybe they'll notice 20 hr battery life instead of 10? It's like having the ability to design a car with 2x the HP or 2x the gas mileage. Increasing the power isn't always the best win, as we learned from the desktop, eventually there are marginal returns.
(I'm guessing I'll be banned for writing an article that speaks positively of Android and semi-critical of Apple, as it seems you can get banned by these forums for merely stating the facts, while other people spew downright nasty ad hominems and nothing ever seems to happen, as long as you tow the Apple party line, it seems criticizing Apple is too hurtful)
If that's the case, then the majority won't get it before 2016/2017. Wow.
From reading that Android blog, it looks like it's mandatory to be stupid. Yes, Android. For the stupidities of us.
How can the majority get it in 2016/17?
The majority runs a several generations old Android at any time, I have 2 Andoids in my household, they were bought based on price only, and they are not close to running the latest version of A. I also have 2 iPhones (4 and 5), they obviously have always been fully up to date, but for the Androids that has never been an option.
Java has always been 64-bit (long data types), and the Java VM has supported 64-bit addressing for years due to Java's use in the enterprise. Dalvik adheres to this spec and supports 64-bit data types and addresses. For application developers on Android, you won't even need to recompile software if it uses no native code, you'll get 64-bit use automatically once Dalvik is deployed at 64-bit.
But Dalvik runs on top of Linux, so the question is, is Linux 64-bit ready? Yes, it was the first consumer OS to be 64-bit, before Apple and Microsoft. What is usually not 64-bit bit ready are proprietary binary device drivers that you can from Qualcomm, Nvidia, et al.
But, there is evidence this isn't going to be a problem. The Android x86 project shipped Android running on 64-bit x86 AMD/Intel chips a long time ago and it works.
Android will have an easier time moving to 64-bit (for Java based software, not NDK software) precisely because it is virtualized. It's like asking when will Javascript sites work on 64-bit, and the answer is, as soon as the Javascript VM is modified to leverage it, everything will benefit automatically. The stuff about needing Oracle is utter nonsense. Oracle has nothing to do with Android's Java implementation, and Oracle's implementation of Java is already 64-bit capable and has been for years.
What I find interesting is, when Apple is not the first to market (multicores, bigger ram, bigger screens, etc), then "specs don't matter" and Apple is not "following", but when Apple is first, all of a sudden, specs are the most important thing in the world, and anyone who was thinking the same thing, but late out of the gate is a copycat.
The reality is, 64-bit was inevitable, as mobile phones are already within a factor of 4 of the upper RAM limit, and ARMv8 was specced out in 2011 and vendors licensed SoCs in 2012 with predictions of shipping in 2014. Apple made it first, but being first out of the gate isn't always best either. It's like when NVidia and ATI used to release ultra powerful GPUs, but no games could really leverage them to the fullest, because it would fragment the market against mostly everyone else who had lower end HW. 64-bit on the 5S is going to give only modest speedups for the time being, nothing like the 2x quoted.
What's missing from this cheery discussion is the effect that pushing bigger die sizes with more transistors and switching fabs has on yields. The iPhone 5s seems to indicating short supply, this is due to either the fingerprint sensor, the 64-bit CPU, or a combination of both. My guess is the A7 is having yield problems. TSMC is notorious for this, and NVidia and ATI which both used TSMC used to have to frequently respin their silicon when they started hitting +1billion trannies. The more trannies and die area, the higher the probability of defects.
Thus, the A7 may in fact be costing Apple delays in parts and margins, because the more bad chips that come off of a wafer, the worse the margins. When most of the industry goes 64-bit in 2014, no one's going to care that Apple was first, just like no one cared who had the first dual core, quad core, or octa-core. Consumers don't care, only fanboys do, so they can engage in continuous penis measuring contests.
The iPhone 5S confers no benefit in battery life. Imagine if instead of doubling the number of transistors, Apple had instead, used the new semiconductor process to end up with a fall smaller SoC, it would drain less power, and be cheaper, and battery life would be greater. The question needs to be asked, does the iPhone already perform well enough? Does it really need 2x more CPU? Will consumers really notice that, or maybe they'll notice 20 hr battery life instead of 10? It's like having the ability to design a car with 2x the HP or 2x the gas mileage. Increasing the power isn't always the best win, as we learned from the desktop, eventually there are marginal returns.
(I'm guessing I'll be banned for writing an article that speaks positively of Android and semi-critical of Apple, as it seems you can get banned by these forums for merely stating the facts, while other people spew downright nasty ad hominems and nothing ever seems to happen, as long as you tow the Apple party line, it seems criticizing Apple is too hurtful)
yeah sure, Android coulda, shoulda, woulda. plus some pure speculation and penis trash talk.
Saying that there aren't really any apps on iOS that take advantage of 64-bit is missing the point really. The hardware has to be there for it to be taken advantage of. All of Apple's iOS7 apps on the 5S will be 64-bit but these are existing applications. I'm sure it won't be long before Apple are creating apps that will do things previously not possible, or at least useable in 32-bit form.
Apple, as usual, are laying down the groundwork for what's coming. As Tim Cook said on Tuesday, there is nothing like iWork for iOS on Android and I expect that Apple are putting the finishing touches to an app that will only exist on 64-bit iOS. It will help drive sales of the 5S of course, and probably the next iPad which is also seems likely to be 64-bit. They will want a software and hardware synthesis that Samsung and the others really can't copy, at least for some time.
Saying that there aren't really any apps on iOS that take advantage of 64-bit is missing the point really. The hardware has to be there for it to be taken advantage of. All of Apple's iOS7 apps on the 5S will be 64-bit but these are existing applications. I'm sure it won't be long before Apple are creating apps that will do things previously not possible, or at least useable in 32-bit form.
Apple, as usual, are laying down the groundwork for what's coming. As Tim Cook said on Tuesday, there is nothing like iWork for iOS on Android and I expect that Apple are putting the finishing touches to an app that will only exist on 64-bit iOS. It will help drive sales of the 5S of course, and probably the next iPad which is also seems likely to be 64-bit. They will want a software and hardware synthesis that Samsung and the others really can't copy, at least for some time.
I like iWork, especially KeyNote, but for Enterprise use, Pages and Numbers aren't really a big deal, they're pretty, but the biggest feature for Enterprise users is collaboration and backoffice, and iWork basically doesn't compete with Google Docs or Office in that regard, and I'm not sure Pages and Numbers are a big draw for consumers. The iPhone "won" because it won over consumers, while Blackberry and others thought creating devices for Enterprise users was key. I don't think enterprise software really strengthens the case for most people. Are we now saying the "5s" is for guys who carry briefcases, and the 5c is for everyone else? Seems weird.
Leveraging 64-bit performance requires crafting software to leverage 64-bit math. If you're got a game, and you've got features, like enhanced physics engine or particle effects on 64-bit iOS, but not on 32-bit, then you've fragmented the market. Fragmentation-by-performance increases cost for developers. Thus, I don't see 64-bit being that usable until a large number of 5s and 64-bit iPads are sold, enough to justify the design of killer apps for it.
But if you look at how 64-bit played out on the desktop, 64-bit never really mattered much in terms of "doing stuff that couldn't be done before". Most performance boosts came more from SIMD-extensions, not 64-bit scalars or MMX.
yeah sure, Android coulda, shoulda, woulda. plus some pure speculation and penis trash talk.
why, you'll fit right in!
It's not really penis trash talk to point out that people have been writing Java programs on 64-bit architectures for a long time and that, as applied to mobile, the switch over won't be difficult for non-native apps, it's just basic facts, and the "analyst" being quoted about how Android has to wait until Oracle upgrades Java to 64-bit or some such is basically clueless.
The biggest issue with 32-bit to 64-bit on Android, and there will be issues, is apps that use the NDK -- stuff written in C code and combined to ARM directly, and device drivers. Google is moving towards LLVM bitcode based solutions for this as Android will have to content with Intel Bay Trail oriented devices soon. My guess is, there's no rush, with 1 billion devices out there, developers really aren't going to care if even 1% of them are 64-bit at this point.
This is a great article and brings up very interesting points. If Apple sell a few hundred million A7 powered devices that's nice revenue for TSMC and less of course for Samsung. This has to be an Apple objective.
Saying that there aren't really any apps on iOS that take advantage of 64-bit is missing the point really. The hardware has to be there for it to be taken advantage of. All of Apple's iOS7 apps on the 5S will be 64-bit but these are existing applications. I'm sure it won't be long before Apple are creating apps that will do things previously not possible, or at least useable in 32-bit form.
Apple, as usual, are laying down the groundwork for what's coming. As Tim Cook said on Tuesday, there is nothing like iWork for iOS on Android and I expect that Apple are putting the finishing touches to an app that will only exist on 64-bit iOS. It will help drive sales of the 5S of course, and probably the next iPad which is also seems likely to be 64-bit. They will want a software and hardware synthesis that Samsung and the others really can't copy, at least for some time.
First, all of the shipped apps by Apple for iOS7 are supposed to be 64 bit. But the real beneficiary early on for 64 bit performance is probably the camera app and the related logic in the A7 chip for the image processor. I'm still carrying a 3 year old iPhone 4 (soon to be upgraded to the 5s) and I've seen the cameras for my mother's 4s and my wife's 5. Both are much better than mine but the burst mode stuff for the 5s camera that is looking at every image at 10 fps, evaluating every one on six major criteria factors and presenting the best picture? Really? You don't think that 64 bittiness isn't playing a role here with all of that data having to be slung around and evaluated in real time?
As for Android going 64 bit, it is true that the virtualization that the platform already features will help. Recently I had a large enterprise customer who was having a lot of Java related server problems and we came to discover that their enterprise production system was running on the ragged edge of memory for what the 32-bit JVM could do. A move to the 64 bit version solved the problem, without a change to the production code. Of course, running in bytecode is never going to be as fast as running natively, which is why Android phones frequently clock their processors faster than what Apple does with the A-series...they just have to for proper performance.
But I think the real problem for Android going 64 bit will again be the vendors. It's one thing to have Android/Linux compile properly to a 64 bit version...it's another thing to have drivers for all the interfaces. In the past, device manufacturers have had a hard enough time producing recent versions of Android to run on year old phones...most of the time they don't even bother. The first 64 bit Android phones will be Nexus phones from Google...that much is certain. But I wouldn't be surprised to see 64 bit hardware running 32 bit Android builds a year from now.
DED got the story mostly correct. I don't need to provide extra links to verify my claims. DED already has them in his editorial. Moreover, all you really need to know to realize my claims are true is that Apple innovates its hardware and software together and manages its supply-chain wisely.
This article is full of useful information and good reporting BUT you badly need and editor.
if you're going to criticize someone's editing, make sure you look in the mirror before you post. I'm only being a spelling fascist because the OP was whining about editing, using a really bad edit.
I thought this article was well written and informative. This kind of substantive reporting is why I enjoy AI so much. I've pretty much stopped reading the other 'Apple press' - AI has really become the 'paper of record' for Apple reporting.
DED sometimes goes over the top with his pro-Apple cheerleading hyperbole, but this was an outstanding article.
It's just a matter of time before Daniel is offered a tech writer position at the NYT or elsewhere. (Daniel, PLEASE don't go to work for Wired - ugh! They're the National Enquirer of tech news).
For consideration as Daniel's next place of business, I would suggest the Amazon Times (er) Washington Post - there's been some excellent reporting coming out of the WP since Bezos (who I loathe) bought the paper.
I like iWork, especially KeyNote, but for Enterprise use, Pages and Numbers aren't really a big deal, they're pretty, but the biggest feature for Enterprise users is collaboration and backoffice, and iWork basically doesn't compete with Google Docs or Office in that regard, and I'm not sure Pages and Numbers are a big draw for consumers.
Attention USS Enterprise, Apple's firing photon torpedos across your bow. The iWork suite probably contributes little to Apple's expenses (certainly less than marketing), so when they start giving it away on their devices and the web, it will become a de facto standard in its own right.
Remember BYOD? Get ready for BYOA - bring your own apps / access. "Collaboration and backoffice"? As tablets replace laptops, the mobile space will be where people collaborate.
I agree that Pages, Numbers et al do not have the heft of Word and Excel . . . yet. Also, Apple's execution of mobile collaboration sucks today.
However, my wife is a grad student and HATES HATES HATES MS Word - and she uses it on the Mac.
Once she figured out how to footnote in Pages, she left the MBP at home and now takes the iPad to class.
64-bit software is going to allow a lot of new standards to be defined in the mobile arena. After Apple gets basic 'officelike' functionality working well in iOS and OS X, collaboration will be cleaned up, and the USS Enterprise will change course.
Not to mention that the real money and growth is in automating the millions of small businesses who keep word and excel docs on the "Y" drive to run their business. That paradigm is very 20th century and fading fast.
Yes this is what I'm talking about. I have to BUMP my phone because Apple does not have NFC. Samsung has had Wifi Direct since the Galaxy S2, and it is amazing. Why can't Apple do such a thing. File transfers are incredibly fast. Please help me make Apple better so we no longer have to download an App and ridiculously Bump our expensive iPhones. These phone are like jewels, we should not be forced to treat them this way just to transfer files and use up data. Wifi Direct is extremely easy, no need to bump anything, and it uses absolutely no data. Maybe you have some suggestions on how we can get Apple to implement this. I'm open to anything to help the iPhone get better and better to be the best iPhone ever.
64-bit software is going to allow a lot of new standards to be defined in the mobile arena. After Apple gets basic 'officelike' functionality working well in iOS and OS X, collaboration will be cleaned up, and the USS Enterprise will change course.
Not to mention that the real money and growth is in automating the millions of small businesses who keep word and excel docs on the "Y" drive to run their business. That paradigm is very 20th century and fading fast.
And at $300 or so a pop for Office, small business is just looking to get it replaced. Big corporations will start looking to in order to shed the site license fees.
Java has always been 64-bit (long data types), and the Java VM has supported 64-bit addressing for years due to Java's use in the enterprise. Dalvik adheres to this spec and supports 64-bit data types and addresses. For application developers on Android, you won't even need to recompile software if it uses no native code, you'll get 64-bit use automatically once Dalvik is deployed at 64-bit.
I'm not sure Dalvik needs to be 64-bit. Android uses a separate Dalvik VM instance for each app, and it's unlikely an individual app will need more than 4 GB of memory.
For x86, I'd think Google would use the new x32 ABI. That has the architectural improvements of x64 (more registers, faster syscalls, faster dynamic linking, etc), without the pointer bloat.
As for ARM, I agree -- drivers will be stumbling block.
Comments
New A6s and the A7 (28nm) are both dual-sourced from Samsung and TSMC. A8 (20nm) will likely also be dual sourced (Apple's CEO is a supply-chain expert).
Samsung was not blindsided by A7. ARMv8 is still new and even ARM itself continues to find aspects of AArch64 (ARMv8) that need to be specified with greater precision or clarity and significant bugs in their own 64-bit core designs. Also there hasn't been much urgency among the Android and Chrome communities for 64-bit software and cores. (Phones really don't need 64-bit. There is however a significant ARMv8 Linux effort). So if there is surprise at the 64-bitness of Apple's A7 it may simply be that Samsung was surprised that Apple would risk publicizing that their premier product was ARMv8 when the architecture itself, let alone the open-source compiler and low-level libraries, are still technically immature. Hence Samsung's "ARMv8 in the fullness of time" attitude. I don't have knowledge of Apple's internal ARM software ecosystem, but it seems by this 64-bit A7 announcement that Apple is either trying to use 64-bitness as a diversion, and/or more likely, to demonstrate that their proprietary ARMv8 software environment is mature enough to workaround the bugs and ready to take on iOS, OS-X and desktop/laptop class productivity apps like Numbers, Keynote, etc. That it is a very short step from here to A7-based OS-X low-tier high-volume MacBooks is clearly not lost on Intel. At a minimum, Apple's MacBook processor pricing from Intel will now be more as if they were dual-sourced. As one of the possible second sources (among other reasons), Samsung stands to benefit from Apple's announcement and Samsung knows it.
The surprise here, although it shouldn't be in Apple's case (especially to AI readers), isn't the first mass production ARMv8 cores, as difficult as that was, it is the ARMv8 software and everything that goes into it. Hats off to Apple for being first to both and hats off to Apple's leaders for using that technical achievement to increase their leverage over processor pricing from both Samsung and Intel at the same time.
Your first post. You claim to know a lot but didn't provide any links to backup up anything.
Well that threw a cat in amongst the pigeons.
I learned a lot from this article. Incendiary, but completely brilliant and thoroughly researched. It really does show you how tech journalism has devolved into regurgitating press releases. People aren't thinking deeply, strategically or long term.
I have always suspected Apple were playing the long game and Samsung were running a food fight; throwing mud and seeing what sticks. I didn't realise Samsung were not even taking the time to lay the foundations in their manufacturing division. I've felt for a while that Samsung is very much at risk of tripping over it's own short-sighted success. Too quick to grab this sale at the expense of the next ten. What happens when you run out of poorly-implemented ideas? What happens when your gimmicks start impacting adversely on battery life? How do you convince someone with a 6-inch phone to upgrade? Sell them a 7/8/9/10-inch phone? Sell adjunct accessories with no inherent reason for being? Clearly their strategy has diminishing returns.
People will eventually tire of complicated, poorly-implemented gimmicks. And when they do Apple is ready to sell them a functional, integrated solution from a family of devices at the optimal crux of design, usability, features, battery life and cost.
Siri has been panned but I suspect it's a sleeper hit waiting to happen. Apple Maps was an uncomfortable move forced by Google withholding turn-by-turn data and wanting to implement steep charges for vendors accessing its map data. Though much maligned, Apple Maps was at least successful at manoeuvring Google to provide turn-by-turn data to iPhone users, which was the entire point.
Apple will soon build themselves into a position where the have the volume, proprietary hardware and power efficiency such that no one will be able to compete in terms of form-factor, battery life and, eventually, cost.
Some may argue that we are already there.
Java has always been 64-bit (long data types), and the Java VM has supported 64-bit addressing for years due to Java's use in the enterprise. Dalvik adheres to this spec and supports 64-bit data types and addresses. For application developers on Android, you won't even need to recompile software if it uses no native code, you'll get 64-bit use automatically once Dalvik is deployed at 64-bit.
But Dalvik runs on top of Linux, so the question is, is Linux 64-bit ready? Yes, it was the first consumer OS to be 64-bit, before Apple and Microsoft. What is usually not 64-bit bit ready are proprietary binary device drivers that you can from Qualcomm, Nvidia, et al.
But, there is evidence this isn't going to be a problem. The Android x86 project shipped Android running on 64-bit x86 AMD/Intel chips a long time ago and it works.
Android will have an easier time moving to 64-bit (for Java based software, not NDK software) precisely because it is virtualized. It's like asking when will Javascript sites work on 64-bit, and the answer is, as soon as the Javascript VM is modified to leverage it, everything will benefit automatically. The stuff about needing Oracle is utter nonsense. Oracle has nothing to do with Android's Java implementation, and Oracle's implementation of Java is already 64-bit capable and has been for years.
What I find interesting is, when Apple is not the first to market (multicores, bigger ram, bigger screens, etc), then "specs don't matter" and Apple is not "following", but when Apple is first, all of a sudden, specs are the most important thing in the world, and anyone who was thinking the same thing, but late out of the gate is a copycat.
The reality is, 64-bit was inevitable, as mobile phones are already within a factor of 4 of the upper RAM limit, and ARMv8 was specced out in 2011 and vendors licensed SoCs in 2012 with predictions of shipping in 2014. Apple made it first, but being first out of the gate isn't always best either. It's like when NVidia and ATI used to release ultra powerful GPUs, but no games could really leverage them to the fullest, because it would fragment the market against mostly everyone else who had lower end HW. 64-bit on the 5S is going to give only modest speedups for the time being, nothing like the 2x quoted.
What's missing from this cheery discussion is the effect that pushing bigger die sizes with more transistors and switching fabs has on yields. The iPhone 5s seems to indicating short supply, this is due to either the fingerprint sensor, the 64-bit CPU, or a combination of both. My guess is the A7 is having yield problems. TSMC is notorious for this, and NVidia and ATI which both used TSMC used to have to frequently respin their silicon when they started hitting +1billion trannies. The more trannies and die area, the higher the probability of defects.
Thus, the A7 may in fact be costing Apple delays in parts and margins, because the more bad chips that come off of a wafer, the worse the margins. When most of the industry goes 64-bit in 2014, no one's going to care that Apple was first, just like no one cared who had the first dual core, quad core, or octa-core. Consumers don't care, only fanboys do, so they can engage in continuous penis measuring contests.
The iPhone 5S confers no benefit in battery life. Imagine if instead of doubling the number of transistors, Apple had instead, used the new semiconductor process to end up with a fall smaller SoC, it would drain less power, and be cheaper, and battery life would be greater. The question needs to be asked, does the iPhone already perform well enough? Does it really need 2x more CPU? Will consumers really notice that, or maybe they'll notice 20 hr battery life instead of 10? It's like having the ability to design a car with 2x the HP or 2x the gas mileage. Increasing the power isn't always the best win, as we learned from the desktop, eventually there are marginal returns.
(I'm guessing I'll be banned for writing an article that speaks positively of Android and semi-critical of Apple, as it seems you can get banned by these forums for merely stating the facts, while other people spew downright nasty ad hominems and nothing ever seems to happen, as long as you tow the Apple party line, it seems criticizing Apple is too hurtful)
If that's the case, then the majority won't get it before 2016/2017. Wow.
From reading that Android blog, it looks like it's mandatory to be stupid. Yes, Android. For the stupidities of us.
How can the majority get it in 2016/17?
The majority runs a several generations old Android at any time, I have 2 Andoids in my household, they were bought based on price only, and they are not close to running the latest version of A. I also have 2 iPhones (4 and 5), they obviously have always been fully up to date, but for the Androids that has never been an option.
This is quality in-depth and thinking person's writing. The hardware equivalent of a John Siracusa OS X analysis!
Keep it up please.
yeah sure, Android coulda, shoulda, woulda. plus some pure speculation and penis trash talk.
why, you'll fit right in!
... It really does show you how tech journalism has devolved into regurgitating press releases.
You really didn't need the word "tech" in that sentence.
Saying that there aren't really any apps on iOS that take advantage of 64-bit is missing the point really. The hardware has to be there for it to be taken advantage of. All of Apple's iOS7 apps on the 5S will be 64-bit but these are existing applications. I'm sure it won't be long before Apple are creating apps that will do things previously not possible, or at least useable in 32-bit form.
Apple, as usual, are laying down the groundwork for what's coming. As Tim Cook said on Tuesday, there is nothing like iWork for iOS on Android and I expect that Apple are putting the finishing touches to an app that will only exist on 64-bit iOS. It will help drive sales of the 5S of course, and probably the next iPad which is also seems likely to be 64-bit. They will want a software and hardware synthesis that Samsung and the others really can't copy, at least for some time.
Saying that there aren't really any apps on iOS that take advantage of 64-bit is missing the point really. The hardware has to be there for it to be taken advantage of. All of Apple's iOS7 apps on the 5S will be 64-bit but these are existing applications. I'm sure it won't be long before Apple are creating apps that will do things previously not possible, or at least useable in 32-bit form.
Apple, as usual, are laying down the groundwork for what's coming. As Tim Cook said on Tuesday, there is nothing like iWork for iOS on Android and I expect that Apple are putting the finishing touches to an app that will only exist on 64-bit iOS. It will help drive sales of the 5S of course, and probably the next iPad which is also seems likely to be 64-bit. They will want a software and hardware synthesis that Samsung and the others really can't copy, at least for some time.
I like iWork, especially KeyNote, but for Enterprise use, Pages and Numbers aren't really a big deal, they're pretty, but the biggest feature for Enterprise users is collaboration and backoffice, and iWork basically doesn't compete with Google Docs or Office in that regard, and I'm not sure Pages and Numbers are a big draw for consumers. The iPhone "won" because it won over consumers, while Blackberry and others thought creating devices for Enterprise users was key. I don't think enterprise software really strengthens the case for most people. Are we now saying the "5s" is for guys who carry briefcases, and the 5c is for everyone else? Seems weird.
Leveraging 64-bit performance requires crafting software to leverage 64-bit math. If you're got a game, and you've got features, like enhanced physics engine or particle effects on 64-bit iOS, but not on 32-bit, then you've fragmented the market. Fragmentation-by-performance increases cost for developers. Thus, I don't see 64-bit being that usable until a large number of 5s and 64-bit iPads are sold, enough to justify the design of killer apps for it.
But if you look at how 64-bit played out on the desktop, 64-bit never really mattered much in terms of "doing stuff that couldn't be done before". Most performance boosts came more from SIMD-extensions, not 64-bit scalars or MMX.
yeah sure, Android coulda, shoulda, woulda. plus some pure speculation and penis trash talk.
why, you'll fit right in!
It's not really penis trash talk to point out that people have been writing Java programs on 64-bit architectures for a long time and that, as applied to mobile, the switch over won't be difficult for non-native apps, it's just basic facts, and the "analyst" being quoted about how Android has to wait until Oracle upgrades Java to 64-bit or some such is basically clueless.
The biggest issue with 32-bit to 64-bit on Android, and there will be issues, is apps that use the NDK -- stuff written in C code and combined to ARM directly, and device drivers. Google is moving towards LLVM bitcode based solutions for this as Android will have to content with Intel Bay Trail oriented devices soon. My guess is, there's no rush, with 1 billion devices out there, developers really aren't going to care if even 1% of them are 64-bit at this point.
I so took this the wrong way.
How will we know if this is a fact?
Saying that there aren't really any apps on iOS that take advantage of 64-bit is missing the point really. The hardware has to be there for it to be taken advantage of. All of Apple's iOS7 apps on the 5S will be 64-bit but these are existing applications. I'm sure it won't be long before Apple are creating apps that will do things previously not possible, or at least useable in 32-bit form.
Apple, as usual, are laying down the groundwork for what's coming. As Tim Cook said on Tuesday, there is nothing like iWork for iOS on Android and I expect that Apple are putting the finishing touches to an app that will only exist on 64-bit iOS. It will help drive sales of the 5S of course, and probably the next iPad which is also seems likely to be 64-bit. They will want a software and hardware synthesis that Samsung and the others really can't copy, at least for some time.
First, all of the shipped apps by Apple for iOS7 are supposed to be 64 bit. But the real beneficiary early on for 64 bit performance is probably the camera app and the related logic in the A7 chip for the image processor. I'm still carrying a 3 year old iPhone 4 (soon to be upgraded to the 5s) and I've seen the cameras for my mother's 4s and my wife's 5. Both are much better than mine but the burst mode stuff for the 5s camera that is looking at every image at 10 fps, evaluating every one on six major criteria factors and presenting the best picture? Really? You don't think that 64 bittiness isn't playing a role here with all of that data having to be slung around and evaluated in real time?
As for Android going 64 bit, it is true that the virtualization that the platform already features will help. Recently I had a large enterprise customer who was having a lot of Java related server problems and we came to discover that their enterprise production system was running on the ragged edge of memory for what the 32-bit JVM could do. A move to the 64 bit version solved the problem, without a change to the production code. Of course, running in bytecode is never going to be as fast as running natively, which is why Android phones frequently clock their processors faster than what Apple does with the A-series...they just have to for proper performance.
But I think the real problem for Android going 64 bit will again be the vendors. It's one thing to have Android/Linux compile properly to a 64 bit version...it's another thing to have drivers for all the interfaces. In the past, device manufacturers have had a hard enough time producing recent versions of Android to run on year old phones...most of the time they don't even bother. The first 64 bit Android phones will be Nexus phones from Google...that much is certain. But I wouldn't be surprised to see 64 bit hardware running 32 bit Android builds a year from now.
DED got the story mostly correct. I don't need to provide extra links to verify my claims. DED already has them in his editorial. Moreover, all you really need to know to realize my claims are true is that Apple innovates its hardware and software together and manages its supply-chain wisely.
This article is full of useful information and good reporting BUT you badly need and editor.
if you're going to criticize someone's editing, make sure you look in the mirror before you post. I'm only being a spelling fascist because the OP was whining about editing, using a really bad edit.
I thought this article was well written and informative. This kind of substantive reporting is why I enjoy AI so much. I've pretty much stopped reading the other 'Apple press' - AI has really become the 'paper of record' for Apple reporting.
DED sometimes goes over the top with his pro-Apple cheerleading hyperbole, but this was an outstanding article.
It's just a matter of time before Daniel is offered a tech writer position at the NYT or elsewhere. (Daniel, PLEASE don't go to work for Wired - ugh! They're the National Enquirer of tech news).
For consideration as Daniel's next place of business, I would suggest the Amazon Times (er) Washington Post - there's been some excellent reporting coming out of the WP since Bezos (who I loathe) bought the paper.
I like iWork, especially KeyNote, but for Enterprise use, Pages and Numbers aren't really a big deal, they're pretty, but the biggest feature for Enterprise users is collaboration and backoffice, and iWork basically doesn't compete with Google Docs or Office in that regard, and I'm not sure Pages and Numbers are a big draw for consumers.
Attention USS Enterprise, Apple's firing photon torpedos across your bow. The iWork suite probably contributes little to Apple's expenses (certainly less than marketing), so when they start giving it away on their devices and the web, it will become a de facto standard in its own right.
Remember BYOD? Get ready for BYOA - bring your own apps / access. "Collaboration and backoffice"? As tablets replace laptops, the mobile space will be where people collaborate.
I agree that Pages, Numbers et al do not have the heft of Word and Excel . . . yet. Also, Apple's execution of mobile collaboration sucks today.
However, my wife is a grad student and HATES HATES HATES MS Word - and she uses it on the Mac.
Once she figured out how to footnote in Pages, she left the MBP at home and now takes the iPad to class.
64-bit software is going to allow a lot of new standards to be defined in the mobile arena. After Apple gets basic 'officelike' functionality working well in iOS and OS X, collaboration will be cleaned up, and the USS Enterprise will change course.
Not to mention that the real money and growth is in automating the millions of small businesses who keep word and excel docs on the "Y" drive to run their business. That paradigm is very 20th century and fading fast.
Yes this is what I'm talking about. I have to BUMP my phone because Apple does not have NFC. Samsung has had Wifi Direct since the Galaxy S2, and it is amazing. Why can't Apple do such a thing. File transfers are incredibly fast. Please help me make Apple better so we no longer have to download an App and ridiculously Bump our expensive iPhones. These phone are like jewels, we should not be forced to treat them this way just to transfer files and use up data. Wifi Direct is extremely easy, no need to bump anything, and it uses absolutely no data. Maybe you have some suggestions on how we can get Apple to implement this. I'm open to anything to help the iPhone get better and better to be the best iPhone ever.
NFC is going to be looked at as gimmicky at best and Apple realized this long ago. http://gigaom.com/2013/09/10/with-ibeacon-apple-is-going-to-dump-on-nfc-and-embrace-the-internet-of-things/
Originally Posted by vaporland
...
64-bit software is going to allow a lot of new standards to be defined in the mobile arena. After Apple gets basic 'officelike' functionality working well in iOS and OS X, collaboration will be cleaned up, and the USS Enterprise will change course.
Not to mention that the real money and growth is in automating the millions of small businesses who keep word and excel docs on the "Y" drive to run their business. That paradigm is very 20th century and fading fast.
And at $300 or so a pop for Office, small business is just looking to get it replaced. Big corporations will start looking to in order to shed the site license fees.
Java has always been 64-bit (long data types), and the Java VM has supported 64-bit addressing for years due to Java's use in the enterprise. Dalvik adheres to this spec and supports 64-bit data types and addresses. For application developers on Android, you won't even need to recompile software if it uses no native code, you'll get 64-bit use automatically once Dalvik is deployed at 64-bit.
I'm not sure Dalvik needs to be 64-bit. Android uses a separate Dalvik VM instance for each app, and it's unlikely an individual app will need more than 4 GB of memory.
For x86, I'd think Google would use the new x32 ABI. That has the architectural improvements of x64 (more registers, faster syscalls, faster dynamic linking, etc), without the pointer bloat.
As for ARM, I agree -- drivers will be stumbling block.