x PhoneArena is hiring! Reviewer in the USA
  • Options

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

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

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, 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:00 2

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

posted on 18 Dec 2013, 21:20 3

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

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: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, 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: 3394; 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, 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, 23:54 2

71. bigstrudel (Posts: 523; 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, 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: 736; 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 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 19 Dec 2013, 06:19 1

110. NexusPhan (Posts: 630; 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 20 Dec 2013, 03:27

122. Victor.H (Posts: 736; 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 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: 2995; 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: 3715; Member since: 16 Aug 2011)

10gb ram?

posted on 18 Dec 2013, 18:11 2

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

14. ZeroCide (Posts: 785; Member since: 09 Jan 2013)

He wants to run VM phone OS's, WP, Android, Jolla, Ubuntu and Firefox all running at the same time.

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, 19:24

35. superduper (Posts: 151; Member since: 20 Oct 2013)

Overkill in a phone maybe. However, did you notice that this year Apple didn't release a beefed up A7X version of their SoC for the new iPads? This leads me to the conclusion that the A7 was designed primarily for the iPad (rather than the other way round). The iPhone 5s just got a free ride.

posted on 18 Dec 2013, 19:43

38. fanboy1974 (Posts: 1345; Member since: 12 Nov 2011)

I would actually take a quad core processor and 3gb of ram vs. a 64-bit platform. That would have been more useful.

posted on 18 Dec 2013, 21:01 2

50. bucky (Posts: 2995; 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: 523; 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:05 4

74. bigstrudel (Posts: 523; Member since: 20 Aug 2012)

The iPhone could not support that kind of power draw. Notice that every Snapdragon 800 chip is in a phone over 5 inches and every one of them has an oversized battery. Instead Apple developed its own custom SoC that delivers the same raw performance using more advanced ARMv8 instructions, thats better optimized and can run using half the power. I know which one I prefer.

posted on 19 Dec 2013, 00:06 3

75. bigstrudel (Posts: 523; Member since: 20 Aug 2012)

Really it just shows that the A7 has more than enough power to account for any differences in display resolution without losing performance.

Want to comment? Please login or register.

Latest stories