x PhoneArena is hiring! Reviewer in the USA
  • Options

How much credit does Apple deserve for the coming mobile 64-bit evolution?

0. phoneArena posted on 18 Dec 2013, 17:21

There has been a lot of talk over the past few months about the move to 64-bit processors mobile processors. Obviously, the talk began with Apple's surprise announcement that the A7 system-on-a-chip (SoC) that would be found in the iPhone 5s was a 64-bit processor, making it the first 64-bit processor in a smartphone. But, as always happens when Apple does something like this, there is a debate about who was really "first"; so, I wanted to take a look at the entire ecosystem and talk about how much credit Apple really deserves in the coming mobile 64-bit evolution...

This is a discussion for a news. To read the whole news, click here

posted on 18 Dec 2013, 21:45 4

60. grahaman27 (Posts: 361; 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.

posted on 18 Dec 2013, 22:51 3

69. JakeLee (banned) (Posts: 1021; 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.

That's all.

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.

posted on 18 Dec 2013, 19:50

40. Zero0 (Posts: 592; 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.

posted on 18 Dec 2013, 20:43 5

46. JakeLee (banned) (Posts: 1021; 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
2. performance
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.

posted on 18 Dec 2013, 20:49 4

47. JakeLee (banned) (Posts: 1021; Member since: 02 Nov 2013)

Correction :
Neither of the two reasons doesn't apply to mobile.


Neither of the two reasons applies to mobile.

posted on 18 Dec 2013, 21:30 4

57. Zero0 (Posts: 592; Member since: 05 Jul 2012)

Wow. A well researched and thought out response.

When did I leave the Internet?

Kudos to you, sir.

posted on 18 Dec 2013, 21:56 2

61. grahaman27 (Posts: 361; 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.

posted on 18 Dec 2013, 22:21 2

65. Finalflash (Posts: 3527; 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.

posted on 18 Dec 2013, 23:54 2

71. bigstrudel (Posts: 529; Member since: 20 Aug 2012)

Your post is all guessing and the usual gang Apple bashing. Fanboy.

posted on 19 Dec 2013, 00:00 4

73. JakeLee (banned) (Posts: 1021; 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.


posted on 19 Dec 2013, 06:19 1

110. NexusPhan (Posts: 632; 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?

posted on 19 Dec 2013, 07:33 1

112. JakeLee (banned) (Posts: 1021; 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.

posted on 19 Dec 2013, 00:17 2

79. JakeLee (banned) (Posts: 1021; 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.

posted on 19 Dec 2013, 02:18 1

85. Victor.H (Posts: 785; Member since: 27 May 2011)

Brilliant analysis, JakeLee. Second your comments here and appreciate you taking the time to break it down.

posted on 19 Dec 2013, 02:55 1

87. JakeLee (banned) (Posts: 1021; 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.

posted on 20 Dec 2013, 03:27

122. Victor.H (Posts: 785; 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.

posted on 19 Dec 2013, 02:59 3

88. TheOldOne (Posts: 196; Member since: 29 Mar 2012)

...why I have found your posts here, especially this reply, more interresting that the article itself :D

posted on 18 Dec 2013, 17:30

3. LordCaedus (Posts: 85; 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.

posted on 18 Dec 2013, 17:34 6

4. bucky (Posts: 3136; Member since: 30 Sep 2009)

I think it's more valuable than octa core processors and 10gb ram

posted on 18 Dec 2013, 17:47 1

6. Commentator (Posts: 3722; Member since: 16 Aug 2011)

10gb ram?

posted on 18 Dec 2013, 18:11 2

13. tedkord (Posts: 14133; 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.

posted on 18 Dec 2013, 18:19 2

18. brrunopt (Posts: 742; Member since: 15 Aug 2013)

i would say a SSD is a bigger performance boost..

posted on 18 Dec 2013, 21:01 2

50. bucky (Posts: 3136; 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.

posted on 18 Dec 2013, 21:37 1

59. Whateverman (Posts: 3284; 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.

posted on 18 Dec 2013, 23:59 2

72. bigstrudel (Posts: 529; 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?

64 Bit.

posted on 19 Dec 2013, 00:10 2

76. JakeLee (banned) (Posts: 1021; Member since: 02 Nov 2013)

Absolutely correct.

posted on 19 Dec 2013, 05:29

104. Whateverman (Posts: 3284; Member since: 17 May 2009)

Cool! So do you think 64 bit socs and 3 and 4gbs of ram would both be considered breakthroughs?

posted on 19 Dec 2013, 03:42 2

89. JakeLee (banned) (Posts: 1021; 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.

posted on 19 Dec 2013, 05:39 1

106. Whateverman (Posts: 3284; 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.

posted on 19 Dec 2013, 06:01 1

108. JakeLee (banned) (Posts: 1021; 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.

Want to comment? Please login or register.

Latest stories