How much credit does Apple deserve for the coming mobile 64-bit evolution?
It's an evolution, not a revolution
The credit that Apple deserves
...Full of sound and fury, signifying nothing
1. Ninetysix (Posts: 1010; Member since: 08 Oct 2012)
Apple the trend-setter. Fandroids pray to the Operating System Gods that v5.0 will be 64-bit aware.
5. sprockkets (Posts: 846; Member since: 16 Jan 2012)
Or the OEM ships a dalvik that works with armv8, which it has done for the 3 arm instruction sets android has used.
11. tedkord (Posts: 3778; Member since: 17 Jun 2009)
Only if the device has 4gb or more of ram. Even then I won't care much.
20. PBXtech (Posts: 465; Member since: 21 Oct 2013)
Exactly. Google has done major progress on getting Android fast and smooth without 64 bit processing. Until flagship, medium level, and entry level phones can run it, going 64 bit isn't necessary at this point in time.
62. Finalflash (Posts: 875; Member since: 23 Jul 2013)
Problem is that Apple has started a numbers game that does nothing to push the industry forward. It is purely marketing which really gets the consumer no benefit because everyone will expend a ridiculous amount of resources catching up to Apple's marketing genius. Regardless, I am hoping the Android OEMs keep delivering multiple upgrades (useful and not so much) unlike Apple and their 1 new marketing point every year.
93. joaolx (Posts: 326; Member since: 16 Aug 2011)
Since when is a 64bit SoC a marketing strategy? It might be but the performance benefits are also there.
98. joaolx (Posts: 326; Member since: 16 Aug 2011)
It's not just about RAM. There is more to 64bit than using more than 4GB of RAM.
29. grahaman27 (Posts: 160; Member since: 05 Apr 2013)
Android has supported 64bit since 2.3...
Hi, have you met java?
31. grahaman27 (Posts: 160; Member since: 05 Apr 2013)
34. JakeLee (Posts: 372; Member since: 02 Nov 2013)
An article from September right after the A7 announcement, a pathetic excuse resorting to Intel versions.
You may google for 64-bit Android. You will find nothing since then.
Why? Cuz there is nothing to talk about. A 64-bit version of the Linaro toolchian. That's all.
117. Pancholo (Posts: 365; Member since: 27 Feb 2012)
You seem relatively annoyed, brother.
Are you a fangirl or a tecchie? Here - Let me help you answer... *hugs*
36. fanboy1974 (Posts: 942; Member since: 12 Nov 2011)
64-bit is a gimmick until one of 2 things happen.
1. When we start seeing 4gig's of ram on phones.
2. When 64-bit apps have a clear advantage over it's 32-bit counterpart.
Now I'm not saying that Apple should not have released a 64-bit processor and OS. What I'm saying is that Apple is a long way from having either of the 2. Even if you use a iPhone 5 and iPhone 5s side by side it's not a night a day difference. Actually I noticed more crashes on the 5s vs the 5. I had the iPhone 5s and the joy of knowing that it's 64-bit wore off after 1 day of use. The sad part is that the phone is still gimped with 1gig of memory. The only reason why were talking about 64 bit is because the phone blogs bring it up. Your average Apple user don't even know (or care) what 64-bit is. But I bet that those same people will understand 1gig vs. 2gigs of ram.
86. TheOldOne (Posts: 51; Member since: 29 Mar 2012)
Acctually, after step2 "When 64-bit apps have a clear advantage over it's 32-bit counterpart." we will discover that acctually we need more than 4GB.
92. joaolx (Posts: 326; Member since: 16 Aug 2011)
64 bit isn't just about supporting more than 4GB of RAM. Why does everybody think it's just that? There is more to it than that.
56. taikucing (unregistered)
As a fandroid, I respect Apple for making 64-bit chip with more than 1 billion transistors (almost reaches Core i7 transistor count) & making ARM architecture almost competitive to x86 architecture (it even blows Intel bay trail out of the water with just 1.2 GHz). I hope someday ARM can surpass Intel. And what I've heard, Apple will replace intel CPU for the desktop with its own ARM CPU.
94. joaolx (Posts: 326; Member since: 16 Aug 2011)
If it continues to go like this I can't see a reason not to replace x86 CPUs. The power usage and heat is incredibly reduced compared to most ARM chips and WAY lower compared to any x86 CPU. In a few years it might easily catch, in performance, most laptop CPUs. The evolution of performance has doubled every year while the heat and power usage has always stayed the same. In a few years we might have Macbooks with ARM chips with equivalent performance to Intel CPUs and have better battery life and reduced heat, so less fans and more space for thinner laptops. And lets not forget that the mobile GPUs have also taken a big step forward, specifically nVidia Tegra, PowerVR and others.
116. nlbates66 (Posts: 170; Member since: 15 Aug 2012)
sorry, but the reality is still that no ARM chip has anywhere near the processing power of a standard mid-range x86 chip from even 4 years ago
58. taikucing (unregistered)
FYI, Apple A7 smokes Intel Celeron 2955U (1,4 GHz) & Intel Pentium 2117U (1.8 GHz) in some benchmarks.
respect Apple for making ARM architecture competitive to x86...
80. JakeLee (Posts: 372; Member since: 02 Nov 2013)
An interesting possibility :
- Apple can and will omit Aarch32 on the upcoming A8 thanks to the completed transition.
- Apple replaces the GPU with a simple 2D graphics IP.
- Apple makes it 16 core
What do we have here? A top-notch chip feasible for servers.
And what prevents Apple from dominating the server market?
- Top-notch SoC almost FREE of the heavy design cost every year
- Top-notch HW
- Top-notch design
- Top-notch OS
- Top-notch SW
- Top-notch IDE (XCode)
- Top-notch marketing
- Top-notch buying power
Apple will sell servers to Google!
100. brrunopt (Posts: 206; Member since: 15 Aug 2013)
comparing to a very low end x86 cpu, right , makes total sense... The a7 reaches the very low end of x86...
81. mayur007 (Posts: 178; Member since: 10 Apr 2012)
exactly you took my words lol .. this exactly i think of apple
i always see apple as trend starter not a innovator..
105. XperiaFanZone (Posts: 723; Member since: 21 Sep 2012)
Not at all. 64-bit archs aren't useful in mobile phones. Just waste of bits.
118. designerfx (Posts: 63; Member since: 26 Mar 2013)
64 bit is potentially useful, but that's not a guarantee. It's entertaining in that it brings things closer to par with laptops, etc - but Apple is about as much a trendsetter as nothing - look at their wonderful battery life with the 5s!
2. W.P._Android_in_that_Order (Posts: 205; Member since: 15 Feb 2012)
Everything will be 64 bit in a few years anyway.
23. JakeLee (Posts: 372; Member since: 02 Nov 2013)
Dalvik is a *32-bit* machine.
Even if the OS and VM get 64-bit porting, Dalvik is and remains a *32-bit* machine.
It's set to stone.
And it won't change.
30. grahaman27 (Posts: 160; Member since: 05 Apr 2013)
Source? Dalvik supports 64 bit since android 2.3
33. JakeLee (Posts: 372; Member since: 02 Nov 2013)
Here you are.
It's kinda a definition of the Dalvik machine, a 32-bit one.
I repeat : the bit numbers emulators are running in doesn't affect the bit numbers of the emulated machines.
And the link you gave just shows how sensitively they reacted to Apple's A7. Cuz they had and have nothing comparable.
They were so desperate that they had to resort to Intel versions.
What have we been hearing from them since then so far?
64-bit Linaro toolchain. That's all. Nothing in sight.
49. grahaman27 (Posts: 160; Member since: 05 Apr 2013)
Eh hem the linaro toolchain was released: years after gingerbread came out. you are not proving anything other than how misguided you are
54. JakeLee (Posts: 372; Member since: 02 Nov 2013)
Linaro, founded in June 2010, released its *first* 64-bit toolchain in September 2013.
We were talking about 64-bit ones, right?
Stop talking about things you don't know a thing about.
60. grahaman27 (Posts: 160; Member since: 05 Apr 2013)
"What have we been hearing from them since then so far?
64-bit Linaro toolchain. That's all. "
My point is that you keep mentioning that android only has 32 bit support except for linaro which is not true. In 2010 when 2.3 was introduced, a 64 bit version of dalvik was also introduced. This has NOTHING to do with hardware, I couldn't care less about the A7. My point is that android is already prepared.
Another point- you sound like a butt hurt fanboy. What logic concludes that an article is invalid simply because it was released at a RELEVANT time?
Get to know how android works. The android developer link that you posted only describes how to truncate 64 bit code into 32 bit which is done across the board today because there are no 64bit android devices.
Lastly, 64bit is not so much the exciting part for phones, but rather the new armv8 instruction set and the more efficient lithography. The A7 is built on 28nm which is last years tech. 20nm will be released in a couple months, with 14/16nm rolling out soon after.
I don't know where you come up with this, but I guess you can't expect much from PA fans.
69. JakeLee (Posts: 372; Member since: 02 Nov 2013)
If you read the ARM32 instruction set manual, you'll find many instructions bearing similarities to the Dalvik ones, spanning 64bit values over two 32-bit registers for example.
The bit width of registers is what defines the chip's bit width. And the Dalvik machine is a 32-bit architecture, just like ARM32.
Want to make Dalvik 64? Very well. They have to design a new Dalvik *architecture*.
Can Google do this? It most probably requires a permission from Oracle. And Oracle will eagerly fry Google even for thinking about this.
And do you honestly think all those article would have appeared without the A7 announcement? C'mon, people are better than that. No one including Qualcomm, Sammy, Google expected a 64-bit chip/OS from Apple this year.
They were shocked, desperate, and had to counter the A7. Et voila, all those articles about 64-bit Android on *Intel* flooding tech sites.
What does Android have on 64-bit ARM now?
Immature toolchain plus immature Linux kernel.
x86_64 versions mean nothing for ARM64. The kernel, the VM, and pretty much everything in OS level consists of large blocks of codes written in architecture specific assembly language.
Lastly, you can't push ARM32 any further beyond the Cortex-A15. It's dead end due to the RISC nature.
Unlike x86, 64-bit is *necessary* for ARM to increase performance.
Unlike x86_64, ARM64 actually benefits from the extra architectural registers, thus increasing the performance considerable.
Unlike on PC, power efficiency is crucial on mobile. ARM64 heavily serves this purpose out of the box, and its increased performance means the clock rate can be throttled down for even more power efficiency.
In case you don't know : the power consumption gets increased *exponentially* in relation to the clock rate.
A chip clocked at 1Ghz consumes only 25% of what it consumes at 2Ghz.
All technical facts. Get to know how CPUs work.
Do you still think 64-bit is an overkill on mobile?
It's also ridiculous to see someone mentioning the process size the chips are produced in. If you find a fab capable of doing it in 14nm with enough yield, do it. If not, stay at higher numbers. It's such a trivial thing and isn't related to Apple in any way.
Stop believing and spreading utter BS.
40. Zero0 (Posts: 557; Member since: 05 Jul 2012)
And you can run multiple instances of 32-bit Dalvik. Each app will only get 32 bits, but the overall system can exceed 4GB of RAM without PAE.
46. JakeLee (Posts: 372; Member since: 02 Nov 2013)
On x86, the larger addressing range is by far the most striking benefit of 64-bit computing, absolutely correct.
The true reasons behind this is :
- A modern Windows app is so demanding that it runs so much better with 4+GB RAM
- x86 doesn't benefit much from 64-bit computing in first place due to its CISC nature.
Neither of the two reasons doesn't apply to mobile.
On ARM, a new ISA was ABSOLUTELY NECESSARY for increasing the performance beyond the Cortex-A15, and it also ABSOLUTELY REQUIRES a new OS built around this new ISA.
It's just that this new ISA happens to be a 64-bit one.
A single memory read consumes more power than executing 100+ instructions on ARM.
Writing to RAM costs even more.
The new ISA allows the 64-byte cache line to be completely filled and the data transfer to occur with a single access. A performance/power efficiency par excellence.
On ARM32, only very simple arithmetics can fill 8bytes from those 64. In usual cases, this value lies between 2 and 4.
For what ARM64 does with a single transfer, ARM32 requires 4~32 transfers. What a difference!
If you asked anyone *proficient* with the ARM architecture, he'd list the benefits of 64-bit computing on ARM in the order of importance :
1. power efficiency
3. addressing range
Why bother when Android has neither a 64-bit Chip nor the 64-bit version?
Even if it did, why bother when Dalvik is a 32-bit machine?
Why bother when there won't be a meaningful number of 64-bit native apps for roughly five years thanks to the fragmentation?
You should worry about Android's "true" multitasking instead, because that's gonna backfire very badly on ARM64 due to its *mandatory* EL handling when switching between 32 and 64-bit mode.
A single 32-bit app running on 64-bit Android will cause performance issues for the WHOLE SYSTEM in addition to draining the battery to no end.
Forget what you witnessed on Windows x64.
ARM64 bears much more similarities to the Itanium than to the x86_64 that makes the transition extremely hard.
What Apple pulled out with this is indeed exceptional considering the Itanium fiasco.
Stop discounting this milestone.
And how was Apple capable of doing this so painlessly?
1. Everything in-house : OS, SoC, HW, toolchain, AppStore
2. Extremely low level of fragmentation
3. XCode with fat binary submission system
You see? Exactly areas Google sucks the most in.
47. JakeLee (Posts: 372; Member since: 02 Nov 2013)
Neither of the two reasons doesn't apply to mobile.
Neither of the two reasons applies to mobile.
57. Zero0 (Posts: 557; Member since: 05 Jul 2012)
Wow. A well researched and thought out response.
When did I leave the Internet?
Kudos to you, sir.
61. grahaman27 (Posts: 160; Member since: 05 Apr 2013)
Its like you know terms but you don't know concepts. Android does not require a specific architecture to run proficiency. Be it x86, amd64, arm, MIPS, PowerPC, it all works. This is because of the VM that android uses. The reason android does not behave like a 64 bit is right now is because the market currently lacks 64bit hardware. Once you stick android on a 64bit machine and make a few modifications to the runtime it becomes a fully 64bit os. Most if not all apps today are written for 64 bit android and scaled Down for 32 bit apps dynamically.
I'm sorry I don't have second PA accounts and Yes-men friends to come like my comments, but you sir are far gone and have no hope at this point.
65. Finalflash (Posts: 875; Member since: 23 Jul 2013)
Who cares what he thinks and does not think Android can do (which is really just cherry picked info fanboy style)? By the time (in 4 years) when Apple can finally use their 64 bit to its full effect, Android will be 64 bit and far ahead as usual. Right now, it barely catches up to the Note 3 and other Android flagships in performance so who cares how 64 bit iOS is.
71. bigstrudel (Posts: 518; Member since: 20 Aug 2012)
Your post is all guessing and the usual gang Apple bashing. Fanboy.
73. JakeLee (Posts: 372; Member since: 02 Nov 2013)
As I said earlier. An emulated SNES is a 16-bit *machine* regardless of the bit number of the *emulator* or the bit number of the *OS* it runs on.
And it's the *concept* behind virtual machines you are talking about without knowing the details.
Dalvik is a 32-bit machine. period.
It's a really amazing job from Google making people believe all those compromises and lacks in Android were advantageous. - utter BS!
The answer at the SO link you gave says exactly the same thing as I'm doing. Bit number of the OS doesn't matter.
What he omitted is "Dalvik is a 32-bit machine anyway"
I assume you are an app developer but not a system developer.
The whole AOSP is a monster project with lots of system level routines written in assembly which are architecture specific.
There have been *mature* 64-bit compilers for quite some time for the x86_64.
ARM64 on the other hand got the *immature* first version two months ago.
That's merely the starting point and not the end.
The Linux kernel seems to be ready, but still immature.
Now people have to work on the monster AOSP with the *immature* toolchain based on the *immature* kernel.
Don't you smell trouble here?
64-bit for x86_64 is arguably easy since all those 64-bit instructions are just *extensions*. They can leave many parts in 32-bit and add/replace with some 64-bit *extended* instructions.
What about ARM64? The ISA is a completely different one. Every single line in assembly has to be completely rewritten, even the whole structure could have to be redone. Mixing 32-bit and 64-bit instructions like on x86_64 is *off the table*.
Doesn't it remind you of Intel's Itanium?
Google for "Itanium fiasco" and you'll find lots of articles about it.
Unless Google does something really really good, we gotta see an "Android64 fiasco" next year.
110. NexusPhan (Posts: 318; Member since: 11 Jul 2013)
Who uses Dalvik anymore? It's all about ART.
Java is pretty much immune to the differences between 64 and 32 bit. That only leaves the virtual machine. I'm not sure at all, but I assume that ART is/will be 64 bit ready.
I really want to hear your thought on this. Will Android run into all the problems you listed above? Or will it be better equipped because of ART, the Linux kernel and java?
112. JakeLee (Posts: 372; Member since: 02 Nov 2013)
ART is the name of JIT on KitKat.
A *Dalvik* Just In Time compiler called Android RunTime that runs *Dalvik* byte codes generated by the ADK.
Java is immune to bit numbers? All it does is leveling down everything to 32-bit.
All the fancy abstractions in higher level programming languages like Java give even the more experienced developers the illusion of this kind of versatility until the generated codes get actually executed by the CPU which only understands it own machine language instructions.
The price of this kind of versatility is quite steep. A native app running on GS1 will easily smoke a comparable Java one running on Note3.
1. Java code gets compiled to JVM byte codes by JDK
2. JVM byte code gets converted to dex Dalvik codes by ADK
3. Dex get executed by the Dalvik VM on Android or compiled to machine language by the JIT in runtime and executed by the CPU directly.
Unlike on x86_64, it's a matter of all or nothing on ARM64.
While 32 and 64-bit apps get along very well on Windows x64, a single 32-bit native app running on 64-bit Android will brake the whole system just like it actually does on iPhone 5s.
By how much you may ask, the switching overhead isn't exactly cheap. The CPU has to halt all the tasks, backup all the registers, flush the cache, dive into exception level, change to supervisor mode, toggle the mode, and move back all the way in reversed order.
Run a 32-bit game on 5s, send an sms to it for the notification to appear. The 32-bit game will almost come to an halt during the 64-bit notification's animations.
Both 32-bit and 64-bit don't get along very well on ARM, unlike on x86.
It's not much of a deal on iOS due to its "lackluster" multitasking. A 32-bit app only has to deal with the 64-bit OS that generously provides all the dedicated 32-bit framework for seamless operations with a few exceptions like the 64-bit-only notification.
It's quite different on Android thanks to its "true" multitasking though. Every task demands its share of processor time on Android. When they are a mixture of both 32 and 64-bit apps, the switching occurs periodically, hundreds of times per second consuming cycles and draining the battery.
By far the best solution to this problem would be making everything 64-bit which would be extremely hard for Android thanks to its way too high fragmentation.
- Java apps hardly benefit from 64-bit
- Native apps cannot be converted to 64-bit easily due to the fragmentation, and 32-bit natives apps will cripple the UX on 64-bit Android.
Quite a dilemma, right?
You should urge Google to push the transition.
If a dev can target as low as 4.0 ICS for 64-bit deployments, the transition will be less problematic.
But if Google sets this requirement at 5 (probably the first 64-bit version) for example, it's asking for disasters.
Unfortunately, the Google I know would go for the latter.
Let's hope Google learned something from Apple, 64-bit requiring iOS6.
79. JakeLee (Posts: 372; Member since: 02 Nov 2013)
Search SO with tags [arm] and [neon]. There you will find many answers I gave. Just in case you doubt my proficiency with ARM.
85. Victor.H (Posts: 369; Member since: 27 May 2011)
Brilliant analysis, JakeLee. Second your comments here and appreciate you taking the time to break it down.
87. JakeLee (Posts: 372; Member since: 02 Nov 2013)
Glad you agree.
Why don't you write an exclusive article on this? That would be something really special no other site has done so far.
The challenge would be how to make this understandable without diving too deep into tech stuff and how to avoid enraging Android fans at the same time.
If you plan to do, I'd gladly assist you.
You have my email address.
122. Victor.H (Posts: 369; Member since: 27 May 2011)
Absolutely, your posts are a great framework. I will definitely try to make this happen in the very near future. I actually don't yet have your email, but I've reached out via PM.
88. TheOldOne (Posts: 51; Member since: 29 Mar 2012)
...why I have found your posts here, especially this reply, more interresting that the article itself :D
3. LordCaedus (Posts: 45; Member since: 01 Nov 2013)
Is there even a need for a phone to have a 64 bit architecture? Seems a little overkill to me.
4. bucky (Posts: 1200; Member since: 30 Sep 2009)
I think it's more valuable than octa core processors and 10gb ram
13. tedkord (Posts: 3778; Member since: 17 Jun 2009)
He's exaggerating to make a point. It's an incorrect point, since to this day one of the best performance boosts you can give a PC is more RAM.
18. brrunopt (Posts: 206; Member since: 15 Aug 2013)
i would say a SSD is a bigger performance boost..
50. bucky (Posts: 1200; Member since: 30 Sep 2009)
not an incorrect point at all. 64 bit lays ground work. octa core and 3-4 gigs of ram is a gimmick. Let the software mature enough to actually use it.
RAM? lol now i know u buy your pc's from bestbuy rather than build them. Thats one of the last things one would need once u hit the minimum nowadays of 4 gb on a computer.
My point still stands.
59. Whateverman (Posts: 3150; Member since: 17 May 2009)
Question... if 64 bit is "laying ground work", how can the requirement (3 to 4 GB) for that groundwork to actually work be a gimmick? Wouldn't they both qualify as groundwork? And if we're talking real world here, the boost in ram is the only one with a measurable effect on the performance. The Note 3 is blazing fast, as is the iphone. But it's not because of the 64 bit soc.
72. bigstrudel (Posts: 518; Member since: 20 Aug 2012)
You're right. Its not because of 64 bit. But ARMv8 instructions are a big performance improvement over ARMv7. And guess what it requires and goes hand in hand with?
104. Whateverman (Posts: 3150; Member since: 17 May 2009)
Cool! So do you think 64 bit socs and 3 and 4gbs of ram would both be considered breakthroughs?
89. JakeLee (Posts: 372; Member since: 02 Nov 2013)
Let me explain.
Note3 is a beast, a vast improvement over Note2.
How will the Note4 fare compared to Note3?
It depends on the chip being an ARMv8 one or not. (with 64-bit Android as well)
ARMv7 cannot be pushed further beyond the Coretex-A15. Increasing the clock rate is also off the table due to the possible heat/battery issues.
Note4 will flop with ARMv7. The then much cheaper Note3 will sell like crazy instead. A prime example for cannibalism. A problem all the OEMs will be facing with their flagships.
64-bit chip and 64-bit Android is absolutely necessary for God's sake, but the situation is really grim.
64-bit SoC is relatively easy. Both Qualcomm and Sammy are very well capable of designing this. No doubts in that.
But 64-bit AOSP is a hell of workloads :
- the toolchain is immature
- not sufficient boards for developers
- many parts relying on contributors
- too many parts of different origins
- AOSP is simply much more complex than iOS
It would require a miracle for the GS5 to come with a 64-bit Android early next year. To be realistic, I think the N6 in autumn 2014 will be the first 64-bit Android phone.
Don't believe anything the a few apparent Android devs here are saying. They may be proficient with Java, but they usually don't know much about CPUs and AOSP itself. It's a low level thing and not a high level one Java devs are talking about.
Summing it up :
Any Android flagship next year without ARM64 will flop. Not because of Apple, but because of their own predecessors.
106. Whateverman (Posts: 3150; Member since: 17 May 2009)
Nice break down! But do you say the Note 4 would flop in the face of a cheaper Note 3? The GS3 and even the GS2 still manage to sell well after the GS4 came out. Why would the Note 4 be any different? Most people won't be concerned about it being 64 or 32 as long as it's fast.
108. JakeLee (Posts: 372; Member since: 02 Nov 2013)
Note4 with ARM32 will be just a face lifted version of Note3.
And the Note3 is simply too good. I can hardly imagine Note4 with a chip of the same caliber being so much better than the Note3 justifying the price difference late next year.
That's a real problem.