x PhoneArena is looking for new authors! To view all available positions, click here.
  • Home
  • News
  • What will it take for Google to bring 64-bit support to Android?

What will it take for Google to bring 64-bit support to Android?

Posted: , by Michael H.

Tags:

What will it take for Google to bring 64-bit support to Android?
Last week, I posed the question concerning how much credit Apple deserves for the coming 64-bit evolution. The TL:DR version goes like this: 64-bit was already in the works in mobile in various ways. Apple certainly built the base quickly, and switched over its platform quite seamlessly, but being first to fully push into 64-bit doesn't necessarily mean that Apple deserves credit for something that was inevitable, especially since the ARMv8 architecture that the A7 uses was first unveiled two years ago. However, it is obvious that Apple deserves credit for making the switch so quickly, and such a long time before any other mobile platform. Apple also deserves credit for making the issue so public, and forcing the competition to move faster on their plans because of how quickly iOS is making the switch.

Interestingly, the comment thread of the editorial didn't focus so much on the question that I had posed, but rather on a run of information from a reader by the name of JakeLee. JakeLee didn't so much refute the points I had laid out as he claimed that Google has a long, difficult road ahead if it expects to optimize Android for 64-bit in the near future. The info from JakeLee has helped to inform this article. Although, my own research into the matter, and help from the Android Developers community on Google+ has shown that the future may not be as troubled for Android as JakeLee made it sound. 

First off, I need to clear up a misconception that is often made, and one that I had myself before doing the research for this piece: when talking about mobile devices, there is no real reason to talk about the 4GB RAM limit that 64-bit helps to surpass. 64-bit is actually a misdirection in the mobile space, because the real issue is moving to the ARMv8 processor architecture. ARMv8 and its brand new instruction set architecture (ISA) are responsible for the real performance boosts that we will see, and it just so happens that this change coincides with the switch to 64-bit. The reason that 64-bit is mentioned and not ARMv8 is because 64-bit is a term that even average consumers and mass media understands to a certain extent. There are plenty of performance benefits to be had on devices that are nowhere near 4GB of RAM, like the iPhone 5s.

As we just learned from HTC, chipset makers build the drivers for processors when Google releases the source code for a new Android release, so ARMv8 support is probably already in the works, but Google still needs to optimize Android for the new hardware.

The work that has been done


What will it take for Google to bring 64-bit support to Android?
There are pieces of the puzzle that are already in place for Android. As has been mentioned before, the Android kernel includes 64-bit support, which it has inherited from Linux. It is also known that multiple manufacturers are working on 64-bit processors for the next generation of Android handsets. Samsung let it be known very soon after Apple's announcement of the iPhone 5s and A7 SoC that it was working on a 64-bit version of its Exynos chipset. Qualcomm obviously had a bit of a PR fiasco after Apple's announcement, but then recently introduced its first 64-bit mobile processor, the Snapdragon 410, with the implication being that the mid and high-end Snapdragon 610 and 810 would be on the way at some point, and also support 64-bit.

Some also mistakenly try to point to Android 2.3 Gingerbread as a point where Google trying to push Android into a 64-bit world. When Gingerbread came out about three years ago, Google made it a requirement when compiling the actual Android system software to use a 64-bit environment. But, this requirement didn't actually bring the Android software itself any closer to 64-bit support, it was only done in order to reduce the time it took to build the system software.

The work left to be done


Yep. That's it. That's all that has been done. Some of you may have expected that last section to be longer, but so far Google has not been taking many steps to bring 64-bit to Android. In fact, there has been no change to the Android Developers documentation, which still states that “Android is currently expected to run on 32-bit platforms. In theory it could be built for a 64-bit system, but that is not a goal at this time.”

All of the Android runtime libraries (media, graphics, file system, etc) and the drivers for the myriad devices are all 32-bit, and would need to up rebuilt for 64-bit, but this shouldn’t be too difficult to do. Really, I could end this section right here, because that’s all the work that needs to be done to move Android to 64-bit compatibility, at least on Google’s side. 

**Beginning technical section. It has been simplified as much as possible, but feel free to skip down if you don't want to muddle through the jargon.**

Another issue that came up quite a bit in JakeLee’s comments was the fact that Android’s Dalvik Virtual Machine uses a 32-bit register, but that turns out to not really be an issue at all. To simplify the explanation of how an Android app works - a developer will write the app code in Java which gets compiled and packaged as an APK. There are then two ways APK is run on an Android device - either the Dalvik VM will execute it directly as bytecode using the Dalvik just-in-time (JIT) compiler. Or, the new ART (Android Runtime introduced in Android 4.4),
What will it take for Google to bring 64-bit support to Android?
Android will move to an ahead-of-time (AOT) runtime, which means the app is broken down to bytecode at the time of installation and only the necessary portions of code will be run at the time it is needed. 

Right now, both the Dalvik VM and ART use a 32-bit register, and there is really no way to change that with the current implementation. But, these registers are abstract entities not related to hardware, so they wouldn’t really cause any problems in switching Android to 64-bit. As stated above, the app code is executed directly, so any apps written in Java would be able to run without issue. At most, an app might have to pass through an interpreter, because of minor differences in coding for 32 and 64-bit in Java. But ultimately, using Dalvik or ART makes it easier for Android to move to new hardware (ARMv7, ARMv8, x86, etc) rather than making it more difficult.

**End technical section**

The only real issue that Google would face as far as apps and compatibility is with apps that use Android’s NDK to code with C/C++. Those apps would need to have the native bits rewritten for 64-bit compatibility, or else Android would have to have two different versions of the runtime to accommodate those apps, which could lead to performance and battery life issues. 

The same major roadblock as always


All of that aside, you hit the only real roadblock, which is the same roadblock that has caused problems with Android since its first days. Google would have to do something that it has never been able to do before with Android - getting developers and manufacturers to follow the plan, not jump the gun on hardware, and push software updates quickly.

This has been a constant struggle for Android, and one that has been getting better over time, but one that still isn't fixed enough to make the transition to 64-bit any easier. As we’ve seen with tablets and multi-core processors, Android hardware makers never want to wait for the system to be optimized before introducing new hardware. Android tablets first shipped well before the system
What will it take for Google to bring 64-bit support to Android?
was ready, leading to the forgotten Android 3.0 Honeycomb update, which was just a stop-gap on the way to the proper Android 4.0 Ice Cream Sandwich update. 

The real work will be in getting developers to update apps with native code for the new 64-bit platform; but it is obvious that the 64-bit hardware is coming soon, much sooner than it will take Google to update Android for 64-bit. This will lead the whole ecosystem to end up in the same vicious cycle where manufacturers will push hardware before the software is ready, and then will likely be slow to update software once the optimizations are done. The first part of the problem will likely occur not through any fault of Google's, but rather because manufacturers (read: Samsung) will want to make sure they have that 64-bit processor in the newest flagship device - and more importantly, in its marketing campaign - before Android is ready to handle it. Then, once Android does get the update to 64-bit, users will have to wait a bit for manufacturers to push out that update.

Of course, this isn’t necessarily a problem for consumers per se, more of an annoyance for those of us who pay attention and understand the real story. All it means is that we will all be subjected to marketing campaigns touting features that offer no real value, which is nothing new. We've seen plenty of features gracing various marketing campaigns that don't really make much difference to the majority of users, like Air Gestures, Face Unlock, and Siri. Samsung and others will undoubtedly market that their products have 64-bit processors, and will conveniently leave out that they offer little to no benefit because the software isn’t ready. But, that is the way marketing works all around anyway, and the average consumer won’t know the difference anyway.

A slow path to faster speeds


While hardware manufacturers plan to jump the gun and put out 64-bit hardware running software that isn’t optimized, Google hasn’t mentioned at all when we should expect a 64-bit optimized version of Android. Getting there will doesn’t look to be that rough of a road, but it will certainly take time to get there. So, it’s impossible to say when Android will be fully optimized from top to bottom.

What will it take for Google to bring 64-bit support to Android?
The earliest we could hope to see Android with proper 64-bit support and optimization throughout the system would be in the summer along with the Nexus 7 (2014), but even that is pushing it too much. More likely, we’ll see a minor update to Android 4.4 KitKat at Google I/O, and Android 5.0 (Laffy Taffy, maybe?) with proper 64-bit optimization in the fall with the Nexus 5 (2014). Even then, users will have to wait for manufacturers to update devices; and, to make things worse, that hardware is likely going to be claiming 64-bit on spec sheets well before Android is ready.

All of this needs to be sorted out, because ARM processors are quickly hitting a performance plateau, because of an outdated instruction set architecture (ISA). ARMv8 has introduced a completely new ISA, and made the switch to 64-bit, both changes which will lead to faster speeds as long as software is optimized properly. Unlike on desktops, the argument about hitting the 4GB RAM limit is nowhere near the most important factor when talking about the performance benefits of moving to ARMv8 and 64-bit. Clock speeds can’t get much faster without causing heat and battery issues, and adding more cores will only get you so far, unless they are specialized cores to offload low-power processes, like we’ve seen with the motion and voice coprocessors in the Moto X and iPhone 5s. The most efficient way to increase performance on an ARM chip is to switch to the ARMv8 architecture because it can do the same in a single transfer as 32-bit ARM can in as many as 32 transfers, but that requires the software optimizations before you see the real performance increase. 

So, we should all prepare ourselves for a lot of empty promises from Android hardware makers over the next year. But, if we keep an eye on Google, and the news coming out about the official software optimizations, we should get a much better idea of when to expect the real changes. 64-bit is certainly on the way, but the real news will be when Android is properly optimized for ARMv8. 

reference: Is Android 32-bit or 64-bit?, Android Developers 1 & 2, +Android Development Community (a special thanks to Bartlomiej Janusz for being so patient with my questions)

128 Comments
  • Options
    Close




posted on 27 Dec 2013, 12:45 6

1. starandmountain (Posts: 50; Member since: 01 Apr 2012)


nice story again! thanks:)

posted on 27 Dec 2013, 12:59 8

10. rf1975 (Posts: 238; Member since: 01 Aug 2011)


Only different is, if this was done by any other manufacturer or Google, then most of them including PA will call it as a real innovation.

posted on 27 Dec 2013, 13:41 3

18. Ashoaib (Posts: 1212; Member since: 15 Nov 2013)


What will it take from google to bring 64bit support? very simple answer.... a hard work for few months, and thats it... ;)

posted on 27 Dec 2013, 14:12 4

29. androiphone20 (Posts: 1393; Member since: 10 Jul 2013)


I recommend you go through the article again, it wont go down that easy pushing 64bit support will likely be seen next to Nexus 7 (2014) and is also too early. Google will have to ask developers who use native code (NDK) to move to 64bit. Manufactures and developers would have to wait for Google's call but some already rushed to it (Sammy)

posted on 27 Dec 2013, 16:13 4

52. tedkord (Posts: 4268; Member since: 17 Jun 2009)


Very few apps in Android use native code. Most are written in Java. Hardware drivers, the ROM itself, yes. Those aren't Google's responsibility.

The other consideration is we don't know what work Android has already done. It doesn't become open source until they release it.

This isn't going to be nearly as difficult as some partisans want to paint it.

posted on 27 Dec 2013, 23:22 2

82. JakeLee (limited) (Posts: 651; Member since: 02 Nov 2013)


What do you think is in the ROM? AOSP by none other than Google.

And what does make you think most apps are written in Java?

Google introduced NDK around the launch of Eclair, and it's exactly the time Android apps became interesting.

posted on 28 Dec 2013, 02:05 1

87. arcone1 (Posts: 18; Member since: 28 Dec 2013)


Most apps are written in java, most games are written in native - this is why Google introduced NDK, to allow seamless and easy way to port games.

posted on 28 Dec 2013, 06:03

102. JakeLee (limited) (Posts: 651; Member since: 02 Nov 2013)


I'd say most simple client apps.

I don't think PowerAmp is written in Java. Hard to imagine fft running properly when written in Java.

posted on 28 Dec 2013, 11:41 1

117. KRONeage (Posts: 39; Member since: 17 Apr 2011)


Java is actually a great language to code in. Because of it being a containerized Application layer. That can be written in any language for near any system. Including 64bit Apps and games on PC's to mobiles.

Even the greatest games can run in the Dalvik VM and it.... unlike Java can run more than one App at a time. You can stuff a monster 4K video in a java VM. Because it's designed as a cross platform equalizing container capable of even running a whole OS if a developer wants it to inside a VM. Not unlike Sun's Looking Glass Project!

But..... Google has a whole new ground up written replacement in Android Kit-Kat for a runtime replacement and it's actually no longer compiled at run time with a "Just in time Compiler (JIT)". The libraries for Android aren't just Java you know. They've written some of their own code and all they're doing is making it easier for developers to code in a high level language they already know!

Would any developer in his right mind stuff any high end game to run in a Java VM today? Not on your life! ....but Android is a different story. Especially with the new Dalvik replacement compiled at install. Like games on desktops or Consoles!

posted on 28 Dec 2013, 14:09 1

118. tedkord (Posts: 4268; Member since: 17 Jun 2009)


What is in the ROM depends on the OEM. If it were simply AOSP, updates would be almost instantaneous.

Most apps are written in java because it's simpler, easier to debug and has almost no penalty because of Dalvik.

posted on 27 Dec 2013, 23:19 2

81. JakeLee (limited) (Posts: 651; Member since: 02 Nov 2013)


An extremely hard work for a whole year at least, and lots of extra workloads for many years to come - all thanks to the fragmentation.

posted on 29 Dec 2013, 16:17

124. arcone1 (Posts: 18; Member since: 28 Dec 2013)


Iit's at most few month of work (which is probably done already).

posted on 27 Dec 2013, 14:32 3

32. Droid_X_Doug (Posts: 5529; Member since: 22 Dec 2010)


+1 on thanks for the informative article. Given the timeline for 64-bit to fully populate (hardware, O/S and apps), it would seem that rushing to upgrade to 64-bit in the Android space until probably 2015 is something of a fools errand.

posted on 27 Dec 2013, 17:47

65. steedsofwar (Posts: 223; Member since: 07 Oct 2013)


To me the article is saying that

a) it isn't really to do with 64bit but more to do with armv8? which the i5s has?
b) even though the i5s has armv8 and 64bit ready and has optimised its OS to be compatible, the app store apps are yet to update and enjoy the benefits. i.e. Apple is two thirds of the way there.
c) even in its current form, the improvements in real world usage over the other 32bit non armv8 devices is still arguably negligible RIGHT NOW.
d) It isn't hard for Google to do the same as Apple but they ARE behind. Samsung will simply meet one third of the equation by providing the hardware for the other two parts to catch up i.e. the OS (up tp Google to optimise) and the apps (up to individual apps to optimise).

posted on 27 Dec 2013, 12:45 2

2. Rajanvir (Posts: 21; Member since: 11 Dec 2013)


I m just waiting for LG G3 with NVIDIA Tegra 5 inside

posted on 27 Dec 2013, 13:22 2

16. Teja171 (unregistered)


According to the rumours, the LG G3 will come with their home grown LG ODIN octa-core soc.... Even i wish that it comes with an Nvidia Soc. :)

posted on 27 Dec 2013, 13:43

19. Ashoaib (Posts: 1212; Member since: 15 Nov 2013)


Shhhhh! LG is reading n they will release with tegra5 for you :p

posted on 27 Dec 2013, 14:34 1

33. Droid_X_Doug (Posts: 5529; Member since: 22 Dec 2010)


Hopefully the manufacturers will focus on other areas to innovate. Like camera modules with full OIS and low-noise image processing. That would helpd bridge the roughly 2 year gap before 64-bit was fully populated.

posted on 27 Dec 2013, 12:49 7

3. Loubielou (Posts: 194; Member since: 11 Jul 2012)


Samsung deserves the Credit not Apple for creating the 64gb bit processor,thats whats people have got stop praising Apple to much,without Samsung ,Apple would find it hard to get someone else to do this for them,just can"t wait to see the new Samsung Galaxy S5 at the MWC

posted on 27 Dec 2013, 12:49 11

4. PapaSmurf (Posts: 7326; Member since: 14 May 2012)


... You mean ARM?

posted on 27 Dec 2013, 12:58 3

9. rf1975 (Posts: 238; Member since: 01 Aug 2011)


There is a big different between manufacturing & designing.

posted on 27 Dec 2013, 12:59 1

12. bigstrudel (Posts: 518; Member since: 20 Aug 2012)


Thats like saying you created a peice of furniture that came out of Ikea.

posted on 27 Dec 2013, 13:02 3

13. Quezdagreat (Posts: 411; Member since: 05 Apr 2012)


Apple designed, samsung manufactured and copied

posted on 27 Dec 2013, 16:16 4

54. tedkord (Posts: 4268; Member since: 17 Jun 2009)


Samsung copied something that ARM announced as coming out in Q1 2014 a full year before the A7? That's prescient.

posted on 27 Dec 2013, 18:54

69. Quezdagreat (Posts: 411; Member since: 05 Apr 2012)


How come they called it a marketing gimmick when Apple came out with it even though Samsung manufactured it?

posted on 28 Dec 2013, 14:14

119. tedkord (Posts: 4268; Member since: 17 Jun 2009)


Because the 64bit was a marketing gimmick aimed at people who think 64bit means twice as good as 32bit. They retracted it because they are and have been for some time planning their own 64bit mobile SOCs (also based on ARMs new instruction set) and knew that the comments would haunt them later.

posted on 29 Dec 2013, 13:57

121. Quezdagreat (Posts: 411; Member since: 05 Apr 2012)


64 bit is a gimmick for android because the os is not 64 bit ready

posted on 27 Dec 2013, 23:55 3

84. kabhijeet.16 (Posts: 626; Member since: 05 Dec 2012)


Samsung created the 64-bit chip for Apple..
Apple used it..
So apple is innovative...
LOL

posted on 27 Dec 2013, 13:48 3

20. Ashoaib (Posts: 1212; Member since: 15 Nov 2013)


this is a thing, people praise apple for making designs on paper although it doesnt has a capacity to create anything physically, while the one(sammy) who has a capacity n capability to do things practicly is booed for copy

posted on 27 Dec 2013, 14:18 2

30. bigstrudel (Posts: 518; Member since: 20 Aug 2012)


Dude its normal procedure for every smartphone maker to part out their manufacturing. Every Galaxy device sold in the US in the last couple years is using processors designed in the US by Qualcomm and fabricated in Taiwan.

posted on 27 Dec 2013, 15:00

43. Ashoaib (Posts: 1212; Member since: 15 Nov 2013)


it is but you didnt catch my point, qualcomm can manufacture their processors too while apple has to relia on others or has to purchase technology to do so

posted on 27 Dec 2013, 15:08 5

44. bigstrudel (Posts: 518; Member since: 20 Aug 2012)


Qualcomm doesn't manufacture their processors either. They licence it to TMSC in Taiwan. A chip fab that only creates chips from other companies' designs.

posted on 27 Dec 2013, 16:15 1

53. joaolx (Posts: 341; Member since: 16 Aug 2011)


How so? It wan't Samsung that created the ARMv8 architecture but it was Apple that designed and first made commercially available a smartphone with 64bit. Not to mention they actually make the OS unlike Samsung which probably has their arms crossed waiting for google to do the dirty work. btw what the hell is 64gb bit????

posted on 27 Dec 2013, 12:51 9

5. PapaSmurf (Posts: 7326; Member since: 14 May 2012)


Waiting for Qualcomm's 64-bit Snapdragon and Samsung's Exynos.

JakeLee in 3..2..1..

posted on 27 Dec 2013, 12:55

7. apple4never (Posts: 917; Member since: 08 May 2013)


lol i was about to say that, better get some popcorn...\**/ \**/ \**/

posted on 27 Dec 2013, 18:28 4

66. Finalflash (Posts: 1433; Member since: 23 Jul 2013)


I can't believe they wrote a full article to shut him up. Judging by his absence it might actually have worked.

posted on 28 Dec 2013, 00:21 4

85. JakeLee (limited) (Posts: 651; Member since: 02 Nov 2013)


Wow, what an impressive statement.

What this article says is :
- Android is far from ready for 64-bit
- Android will have problems with native apps during the transition.
- ARMv8 is certainly efficient

Exactly what I've been saying the whole time.

The only thing Michael doesn't agree with me on is Dalvik. What I can say is that he asked the wrong person about Dalvik in addition to somewhat misunderstanding my former contents.

I clarified this in another comment.

posted on 28 Dec 2013, 02:10

88. arcone1 (Posts: 18; Member since: 28 Dec 2013)


Yeah, what do I know - I write android apps (lately Artflow Studio, quite successful drawing app) for 4 years and previously I worked with java (that is I worked with JVM porting).

posted on 27 Dec 2013, 16:22

58. JC557 (Posts: 839; Member since: 07 Dec 2011)


After the introduction of 64-bit desktop and laptop processors it was pretty much expected for manufacturers like Qualcomm and ARM to create a 64-bit chip for them to enter the embedded and server market. I remember reading about this in magazines like PC World and MaxmimumPC years ago.

The only problem is the usual chicken and egg conundrum. Software won't be 64-bit unless there's a large population running 64-bit capable hardware while the hardware manufacturers won't do so until there's demand on the software side. It took Windows some time to make that transition but too many people stuck with 32-bit and insisted on running much older software.

posted on 27 Dec 2013, 20:52 4

74. JakeLee (limited) (Posts: 651; Member since: 02 Nov 2013)


Did you call for an exterminator, Smurfette?

64-bit SoC is no problem. 64-bit AOSP is THE problem.

posted on 27 Dec 2013, 12:53

6. Hammerfest (Posts: 360; Member since: 12 May 2012)


I really want to see more phones and tablets that have the same core base as my old Sony CLIE UX50, the separate audio processor on that thing made battery life unreal! Go Co-Processor's!
Now with one for LP-Voice, and more features coming as well, the next 5 years are shaping up to be pretty amazing!

For all those optimizations a new battery tech would make it all irreverent except for processing time!

posted on 27 Dec 2013, 16:17 1

55. joaolx (Posts: 341; Member since: 16 Aug 2011)


I rather have co-processors like the one in Moto X or in the iPhone 5s than having quad/octa core cpu that will never be optimized.

posted on 27 Dec 2013, 12:56 2

8. bigstrudel (Posts: 518; Member since: 20 Aug 2012)


Too bad most people wont be able to fathom anything but faster clock speed + more cores = faster device. Increasing clock speed is the least efficient way to increase performance as far as battery life is concerned. And more cores would be effective if Android better took advantage of muti threaded apps. But most of Android is still a single threaded affair. Nice Article.

posted on 27 Dec 2013, 12:59 3

11. apple4never (Posts: 917; Member since: 08 May 2013)


i just had to go back and troll jakelee's comments after this lol

posted on 27 Dec 2013, 20:55 2

75. JakeLee (limited) (Posts: 651; Member since: 02 Nov 2013)


Where was I wrong? This well researched article just says almost the same .

posted on 27 Dec 2013, 23:06 4

79. MichaelHeller (Posts: 2648; Member since: 26 May 2011)


As mentioned in a different comment, you were right about the benefits of ARMv8, but well off in your comments about Dalvik and moving to 64 bit

posted on 27 Dec 2013, 23:23 2

83. JakeLee (limited) (Posts: 651; Member since: 02 Nov 2013)


Read that, and answered that. :)

Kudos.

posted on 27 Dec 2013, 13:03 1

14. taz89 (Posts: 2008; Member since: 03 May 2011)


Don't know much about this 64bit stuff but wondering is the end user going to see any real world noticeable differences or will it literally maybe a second or milliseconds quicker here and there. I don't even think the average consumers know there laptops or whatever is 64bit lol so I really don't think the move to 64bit will bother consumers any bit at all.

posted on 27 Dec 2013, 13:20

15. apple4never (Posts: 917; Member since: 08 May 2013)


i see what you did there ;)

posted on 27 Dec 2013, 13:54 1

22. Ashoaib (Posts: 1212; Member since: 15 Nov 2013)


No! End user is not going to see the difference like iphone now has 64bit n you cant observe any difference bcoz it is not making any difference at the moment. Most probably, end user will not feel a significant difference bcoz the change will be a rapid one, not a quicker one. It will take all players to be on board then performace will reach the peak and all players are not going to be on board at a time

posted on 27 Dec 2013, 14:03 1

25. androiphone20 (Posts: 1393; Member since: 10 Jul 2013)


You clearly wanted to say something, I just can't figure it out. Your argument is not solid it needs a little, y'know

posted on 27 Dec 2013, 16:21 1

57. joaolx (Posts: 341; Member since: 16 Aug 2011)


It doesn't mean much right now because mobile devices don't require the same amount of processing has laptops or desktops. Right now the only apps having benefits with the A7 in the iPhone are heavy apps like audio editing but don't mean much. Beyond that the 64bit can still have some benefits in terms of battery I think.

posted on 27 Dec 2013, 13:35

17. vishalaestro (Posts: 38; Member since: 08 Dec 2013)


I still have some trust in intel mobile platform because intel and amd implemented 64 bit way back in 2003 and the windows platform also supported it ,just hoping to see a windows phone with intel processor in it with rocking specs with 64 bit processing because both intel and Microsoft are more experienced than any other mobile os platforms and manufacturers.

posted on 27 Dec 2013, 13:54

21. bigstrudel (Posts: 518; Member since: 20 Aug 2012)


If Im not mistaken all of Intel's Android processors are already 64bit enabled and are just waiting on Google.

posted on 27 Dec 2013, 19:34

70. fireblade (Posts: 629; Member since: 27 Dec 2013)


ARM is REAL 64bit not extensions like x86. Too many windows clickers believe that 64bit is all about memory. They don’t understand that its a windows problem where 64bit code is 3% slower then 32bit code.

On real OSes with real 64bit you see huge performance gains just because its 64bit and you can crunch more numbers at the same time.

X86 uses 64bit extensions
ARM/PPC/SPARC/Power and so on uses FULL 64bit instructions and that's so amazing. It has both 32bit and 64bit instructions in it. Its “two” processors. Not one with extensions.

posted on 28 Dec 2013, 02:44

93. arcone1 (Posts: 18; Member since: 28 Dec 2013)


X86_64 is real 64bit, but it doesn't offered big gains (indeed most of the apps were a bit slower) because ISA doesn't change that much during this transition. ARMv8 however is a big change in ISA and this finally allow CPU to use modern optimization techniques (like highly OOE with wide fetch thanks to dropping conditional bits).

posted on 27 Dec 2013, 13:54

23. androiphone20 (Posts: 1393; Member since: 10 Jul 2013)


Anand Chandrasekher called 64-bit processor a gimmick just so he could cool down all the attention it was getting, they were caught off guard even when it was in the works. There was simply no better way to do it than to buy some time until Qualcomm developed their own chip.

posted on 27 Dec 2013, 14:03 1

26. bigstrudel (Posts: 518; Member since: 20 Aug 2012)


Lying is standard procedure in business.

posted on 27 Dec 2013, 16:20 1

56. tedkord (Posts: 4268; Member since: 17 Jun 2009)


He spoke the truth, but Qualcomm was in the process of designing their own 64bit processors, and knew his comments would haunt their own products as well.

posted on 27 Dec 2013, 14:00

24. 1701nino (Posts: 227; Member since: 07 Dec 2010)


Sorry a little off topic but i don't get this all siri is bad google now is awesome nonsence???I have both on my nexus 4 and on my ipad and i can say that i use siri a hole lot more then google now and improvments in ios 7 are great i mean it's a whole another category siri is basicly an AI while google now is a service.

Want to comment? Please login or register.

Latest stories