or Connect
AppleInsider › Forums › Mobile › iPhone › Apple partner Qualcomm pans iPhone 5s A7 CPU as 'gimmick,' yet hints at own 64-bit chip
New Posts  All Forums:Forum Nav:

Apple partner Qualcomm pans iPhone 5s A7 CPU as 'gimmick,' yet hints at own 64-bit chip - Page 4

post #121 of 168
Not the flash used in the iPhone as secondary storage. There are flash chips that can be addressed that way, but you need to think of the flash in the iPhone as sort of a SSD. In this sense the flashed is accessed via a controller that is most likely built into the SoC by now.
Quote:
Originally Posted by spacekid View Post

Does Flash memory not use the address space? Seems it is larger than 4GB so wouldn't it be able to take advantage of the 64 bits?
post #122 of 168

Anyone who claims the only reason to go to 64-bit is to address more memory is either an idiot, or being disingenuous.  Hell, the address bus does not always follow the internal archtecture width- it's quite possible to have a CPU with a 64 bit internal bus, 64 bit data bus and a 32 bit address bus-- thus only able to address 4GB of RAM.  Hell, even the A7 may be this way.

 

Address bus width is only relevant when you need to address more RAM.  Since phones don't need that, he's being an idiot.

 

It's like saying "A retina display is useless because it doesn't improve your typing speed."

 

Astounding that the "tech" press reports this stuff without realizing it is idiotic.

post #123 of 168
Quote:
Originally Posted by sranger View Post
 

To be fair, with only 1GB or RAM there is a limit as to how much of an advantage a 64 bit OS really is at this point....

 

 

That's not "being fair", that's showing you haven't the first clue what it means to be a 64 bit CPU or OS.  NOT THE FIRST CLUE.

 

Addressable RAM is COMPLETELY IRRELEVANT.  64 bit CPUS can have 32 bit address busses, and this one probably does!

post #124 of 168
Quote:
Originally Posted by cferry View Post

So Qualcomm's Chief Marketing Officer spins self-serving BS. What else is new? Isn't that his job?

But it's Interesting to see he considers himself an engineering expert too. Perhaps in his next emission he'll explain why this mere "marketing gimmick" inspired such purple prose from Gizmodo, not usually considered an Apple fanboi site.

"We just ran benchmarks on Apple's new iPhone 5S, revealing that, yup, this is the dopest smartphone silicon ever made. This thing freaking churns, crushing every other smartphone out there on both computational power and graphics."

http://gizmodo.com/iphone-a7-chip-benchmarks-forget-the-specs-it-blows-e-1350717023

I'm actually shocked that Gizmodo would report on anything Apple related in such a positive manner.
post #125 of 168
Quote:
Originally Posted by sranger View Post

To be fair, with only 1GB or RAM there is a limit as to how much of an advantage a 64 bit OS really is at this point....

However, it does sound like sour grapes at this point....

The focus on RAM in this discussion is asinine. Look at it this way, how many 64 bit computers out there implement all of the RAM a 64 bit address allows for? More so Apples iOS 32 bit implementations don't implement al the RAM possible with a 32 bit address.

In this case 64 bit is bringing Apple all sorts of advantages even without a bump in RAM. Tricks with pointers for example improve performance. More registers improve performance. In general it appears that the architecture is more efficient and. No some areas vastly improved.

In any event you are right about the sour grapes.

Frankly I'd laugh my ass off if Apple introduces the next iPad with 4GB of RAM. IPad may or may not need it depending upon your perspective but it would shut up a lot of people.
post #126 of 168
Quote:
Originally Posted by wizard69 View Post

Frankly I'd laugh my ass off if Apple introduces the next iPad with 4GB of RAM. IPad may or may not need it depending upon your perspective but it would shut up a lot of people.

 

5GB would be good for a laugh.

Better than my Bose, better than my Skullcandy's, listening to Mozart through my LeBron James limited edition PowerBeats by Dre is almost as good as my Sennheisers.
Reply
Better than my Bose, better than my Skullcandy's, listening to Mozart through my LeBron James limited edition PowerBeats by Dre is almost as good as my Sennheisers.
Reply
post #127 of 168
Quote:
 Such claims, though, have been met with skepticism from many in the tech industry, with Chandrasekher being the latest among those.

Because there all marketing people and there companies are all butt hurt they didn't get there first.

Quote:
 At the same time, though, Chandrasekher seemed to hint that Qualcomm ? which supplies the LTE chips used inside Apple's mobile devices ? would itself be rolling out a 64-bit mobile processor at some point in the future.

But wait?  I thought they offered no advantage at all?  Why build one then?

What a stupid moron.  He contradicts himself in his own interview.

 

There coming out with one obviously because it is very important as many articles have shown. The least of which is being able to address more than 4 Gig of memory.

post #128 of 168
Quote:
Originally Posted by Jessi View Post
 

 

That's not "being fair", that's showing you haven't the first clue what it means to be a 64 bit CPU or OS.  NOT THE FIRST CLUE.

 

Addressable RAM is COMPLETELY IRRELEVANT.  64 bit CPUS can have 32 bit address busses, and this one probably does!

 

Actually "Cyclone" the A7 does both 32bit and 64bit address busses.  It supports the ARM AAarch32 and ARM AArch64.  Because of ARMv8's new ISA it can do both on one chip.

To quote Anand Lal Shimpi:

 

Quote:
 

Unlike the 64-bit x86 transition, ARM’s move to 64-bit comes with a new ISA rather than an extension of the old one. The new instruction set is referred to as A64, while a largely backwards compatible 32-bit format is called A32. Both ISAs can be supported by a single microprocessor design, as ARMv8 features two architectural states: AArch32 and AArch64. Designs that implement both states can switch/interleave between the two states on exception boundaries. In other words, despite A64 being a new ISA you’ll still be able to run old code alongside it. As always, in order to support both you need an OS with support for A64. You can’t run A64 code on an A32 OS. It is also possible to do an A64/AArch64-only design, which is something some server players are considering where backwards compatibility isn’t such a big deal.

Cyclone is a full implementation of ARMv8 with both AArch32 and AArch64 states. Given Apple’s desire to maintain backwards compatibility with existing iOS apps and not unnecessarily fragment the ARM ecosystem, simply embracing ARMv8 makes a lot of sense.

He has a good explanation of it here.

post #129 of 168
Quote:
Originally Posted by wizard69 View Post


Frankly I'd laugh my ass off if Apple introduces the next iPad with 4GB of RAM. IPad may or may not need it depending upon your perspective but it would shut up a lot of people.

 

Quote:
Originally Posted by hill60 View Post
 

 

5GB would be good for a laugh.

I think Apple is laying the ground work for just that,  future options,  one being able to address more than 4 Gig of ram, but that is a minor reason like you have said for going to ARMv8 and 64 bit.  There are a ton of reasons now. That improve everything on the A7.  

post #130 of 168
The most important part is that it creates an exclusive, both for Apple and for their new coming gadgets.
This means exclusive new software and a needed transition by customers over time, thus creating eventual necessity of a purchase upgrade.

The fragmentation aspect as always is irrelevant. Non fragmentations causes problems of its own doing.
post #131 of 168
Next Apple will design a chip with 128 bit data path and all the idiots out there will follow as well saying simply it is a marketing trick....
post #132 of 168

Unless the device has more than 4GB or memory - it is indeed just marketing fluff (yes the chip has other advantages, but that's not what's being pushed as being so great - it's just that it's a 64-bit chip).

 

But so what? Apple is the only company where marketing plays up their products to a simplistic consumer?

post #133 of 168
Quote:
Originally Posted by pondosinatra View Post
 

Unless the device has more than 4GB or memory - it is indeed just marketing fluff (yes the chip has other advantages, but that's not what's being pushed as being so great - it's just that it's a 64-bit chip).

 

But so what? Apple is the only company where marketing plays up their products to a simplistic consumer?

 

Here is some good reading for you, please educate yourself on the matter before claiming anything stupid again.

 

http://www.mikeash.com/pyblog/friday-qa-2013-09-27-arm64-and-you.html

 

http://www.anandtech.com/show/7335/the-iphone-5s-review/4

post #134 of 168
Quote:
Originally Posted by dillio View Post

If Apple set itself up for people to not care about these specs (ex. how much RAM my iPhone has, etc.) then it should live by those expectations. I could care less that the new iPhone has 32 or 64-bit processor in it. Focus on showing me what this phone can do that others don't and don't even mention the 64-bit chip. I'm sure people will find out how many bits it is. But I guess when you only have so many updates to your mid-cycle, even Apple likes to make a big deal of specs.

 

I think most people here are confuse between Apple marketing message and the blogosphere hype one. You should watch the iPhone 5s keynote, beside pointing the A7 has the first 64 bit SoC in mobile phone,  Apple itself has say very little about it, the whole iPhone 5s presentation was focusing on showing features and the 64 bit thing was mention only once, time of one slide for the A7 presentation.  In contrast, Apple has made a way bigger deal before with launching the first 64 bit PowerMac G5.

 

 


Edited by BigMac2 - 10/3/13 at 1:46pm
post #135 of 168
Quote:
Originally Posted by dillio View Post

If Apple set itself up for people to not care about these specs (ex. how much RAM my iPhone has, etc.) then it should live by those expectations. I could care less that the new iPhone has 32 or 64-bit processor in it. Focus on showing me what this phone can do that others don't and don't even mention the 64-bit chip. I'm sure people will find out how many bits it is. But I guess when you only have so many updates to your mid-cycle, even Apple likes to make a big deal of specs.

Besides what BigMac2 states you really miss the point if you don't understand by now how new ARM instruction set for 64-bit benefits the user over the old. There are 4 pages in this thread that go over every beneficial detail about how we will all benefit from this going forward so I implore to actually read this thread.
post #136 of 168
Quote:
Originally Posted by BigMac2 View Post

I think most people here are confuse between Apple marketing message and the blogosphere hype one. You should watch the iPhone 5s keynote, beside pointing the A7 has the first 64 bit SoC in mobile phone,  Apple itself has say very little about it, the whole iPhone 5s presentation was focusing on showing features and the 64 bit thing was mention only once, time of one slide for the A7 presentation.  In contrast, Apple as made a way bigger deal before with launching the first 64 bit PowerMac G5.
 

It's amazing how outdated those specs are now. I suppose, for me, part of it is that the G5 tower design is still be sold today and it'll still look great once the next Mac Pro launches.
post #137 of 168
Quote:
Originally Posted by dillio View Post

If Apple set itself up for people to not care about these specs (ex. how much RAM my iPhone has, etc.) then it should live by those expectations. I could care less that the new iPhone has 32 or 64-bit processor in it. Focus on showing me what this phone can do that others don't and don't even mention the 64-bit chip. I'm sure people will find out how many bits it is. But I guess when you only have so many updates to your mid-cycle, even Apple likes to make a big deal of specs.

They did.

2 hour presentation. 15 seconds on 64 bit. One hour, 59 minutes and 45 seconds on other topics.

Seems to me that Apple didn't hype 64 bit at all.
"I'm way over my head when it comes to technical issues like this"
Gatorguy 5/31/13
Reply
"I'm way over my head when it comes to technical issues like this"
Gatorguy 5/31/13
Reply
post #138 of 168
Quote:
Originally Posted by pondosinatra View Post
 

Unless the device has more than 4GB or memory - it is indeed just marketing fluff (yes the chip has other advantages, but that's not what's being pushed as being so great - it's just that it's a 64-bit chip).

 

But so what? Apple is the only company where marketing plays up their products to a simplistic consumer?

 

Apple pushed the message of the sheer speed difference 64 bit makes, a claim borne out in many benchmarks where the A7 excels even against those who cheat on the scores.

Better than my Bose, better than my Skullcandy's, listening to Mozart through my LeBron James limited edition PowerBeats by Dre is almost as good as my Sennheisers.
Reply
Better than my Bose, better than my Skullcandy's, listening to Mozart through my LeBron James limited edition PowerBeats by Dre is almost as good as my Sennheisers.
Reply
post #139 of 168
Quote:
Originally Posted by dillio View Post

If Apple set itself up for people to not care about these specs (ex. how much RAM my iPhone has, etc.) then it should live by those expectations. I could care less that the new iPhone has 32 or 64-bit processor in it. Focus on showing me what this phone can do that others don't and don't even mention the 64-bit chip. I'm sure people will find out how many bits it is. But I guess when you only have so many updates to your mid-cycle, even Apple likes to make a big deal of specs.

 

10fps burst mode on the 5s camera vs HTC One 4fps and Galaxy S4 6fps.

 

There's one thing for starters.

 

So what you think of the minor iterative upgrade to the Note 2, the super expensive Note 3?

Better than my Bose, better than my Skullcandy's, listening to Mozart through my LeBron James limited edition PowerBeats by Dre is almost as good as my Sennheisers.
Reply
Better than my Bose, better than my Skullcandy's, listening to Mozart through my LeBron James limited edition PowerBeats by Dre is almost as good as my Sennheisers.
Reply
post #140 of 168
Quote:
Originally Posted by akqies View Post


It's amazing how outdated those specs are now. I suppose, for me, part of it is that the G5 tower design is still be sold today and it'll still look great once the next Mac Pro launches.

 

It amazed me to see how near the A7 specs is from the first G5, keep in mind the G5 needed a 1 kilowatts power supply and never made into a mobile platform. This is why Apple have been "forced" to switch to Intel, their PowerBook at that time was stuck with G4 for too long and unable to evolve any further. 

post #141 of 168
Quote:
Originally Posted by Mechanic View Post
Actually "Cyclone" the A7 does both 32bit and 64bit address busses.  It supports the ARM AAarch32 and ARM AArch64.  Because of ARMv8's new ISA it can do both on one chip.

 

You're confused.  AArch32 and AArch64 are ISA-- instruction set architectures.  And yes, the A7 does support both.  Which means it can run code built for 32 bit. 

 

Completely irrelevant to my point.  These are not "address busses".  They are internal to the core.  The Address lines are the physical connections off chip to address locations in RAM, which is offchip (Though it may be inside the same multi-chip package).  It's unlikely these are 64 bit, which is why all the talk about the need to go to 64 bit only to address more RAM is asinine. 

post #142 of 168
Quote:
Originally Posted by Jessi View Post
 

 

You're confused.  AArch32 and AArch64 are ISA-- instruction set architectures.  And yes, the A7 does support both.  Which means it can run code built for 32 bit. 

 

Completely irrelevant to my point.  These are not "address busses".  They are internal to the core.  The Address lines are the physical connections off chip to address locations in RAM, which is offchip (Though it may be inside the same multi-chip package).  It's unlikely these are 64 bit, which is why all the talk about the need to go to 64 bit only to address more RAM is asinine. 

Very true. I believe that since A4 the internal data bus between memory and ARM cpu has been 64-bits wide. I also recall that even on 64-bit ARM core the address bus only goes up as far as 48 bits wide and can be configured for lower.

 

Edit>> Corrected 48 bits PA size

post #143 of 168
Quote:
Originally Posted by BigMac2 View Post
 

 

Here is some good reading for you, please educate yourself on the matter before claiming anything stupid again.

 

http://www.mikeash.com/pyblog/friday-qa-2013-09-27-arm64-and-you.html

 

http://www.anandtech.com/show/7335/the-iphone-5s-review/4

 

Speaking of stupid....obviously you missed where I said it's being marketed by keying in on the fact it's 64-bit as if by that very virtue it's all super awesome.

post #144 of 168
Quote:
Originally Posted by pondosinatra View Post
 

 

Speaking of stupid....obviously you missed where I said it's being marketed by keying in on the fact it's 64-bit as if by that very virtue it's all super awesome.

 

Like I said in a later post, many are confused between what Apple really said about the A7 during their keynote and how its been assimilated by the media. 

post #145 of 168
Quote:
Originally Posted by pondosinatra View Post

Speaking of stupid....obviously you missed where I said it's being marketed by keying in on the fact it's 64-bit as if by that very virtue it's all super awesome.

Since we're talking about ARM the fact that it's 64-bit is super awesome. You really should read the info in the links BigMac2 supplied.
post #146 of 168

I am actually eagerly anticipating Android's transition to 64-bit computing, if only to see if the industry can pull it off as seamlessly as Apple supposedly is attempting to.

 

First, Google has to release a 64-bit version of Android.

 

Based on my understanding, OEMs and app developers have to support with 64-bit processors and apps of their own. This represents a catch-22 scenario. The various OEMs and telcos are already having a hard time ensuring that OS updates cascade down to the end user in a time fashion (if at all). After so many years, just under 50% of users are reportedly running 4.0 and above. Only Samsung seems like they have the resources and financial muscle to pull this off (their phones would be the first to run 4gb of ram, but I doubt their touchwiz would properly support it anyways). 

 

Likewise, if I were an app developer, and I didn't think there are enough users on 4.4 (assuming it runs 64-bit) to justify me expending additional time and resources supporting 64-bit, then I simply won't. Why should I, when there are enough buyers still on 32-bit Android phones to market to? Nor am I going to actually code an app that requires the full 4gb of ram to run properly, because most phones would still be on 2gb of ram or less.

 

And you want to further fragment this with both 32-bit and 64-bit phones?

 

Apple may not be new with their 64-bit processor, but I think they are actually trying to force Android's hand here. Making OEMs rush to incorporate it into their phones, without first taking the time to ensure their products are properly optimised or think if it is really necessary. 

 

In short, expect chaos. 

post #147 of 168
Quote:
Originally Posted by abazigal View Post
 

 

Likewise, if I were an app developer, and I didn't think there are enough users on 4.4 (assuming it runs 64-bit) to justify me expending additional time and resources supporting 64-bit, then I simply won't. 

 

 

You do realize that Java application code is completely independent of the processor architecture. As a developer there is nothing you need to do to support 64 bit.  (Unless you have some very specific native interface code in your app, which is not very common)

All apps compile to machine independent java byte code.

Googles 64-bit Dalvik VM has the task at runtime to convert the byte code into 64-bit processor specific instructions.

 

Quote:
After so many years, just under 50% of users are reportedly running 4.0 and above

Form latest reports 48% of android users are on the latest android JellyBean (4.1+) which was released in July 2012. I'm not sure what you mean by "so many years"


Edited by patpatpat - 10/4/13 at 7:12am
post #148 of 168
Quote:
Originally Posted by abazigal View Post


And you want to further fragment this with both 32-bit and 64-bit phones?

It's not fragmentation, it's progression. 1wink.gif
melior diabolus quem scies
Reply
melior diabolus quem scies
Reply
post #149 of 168
You're not stupid, so what else drives your need to look stupid ?? Perhaps some pressure from a customer ... perhaps a company whose name starts with ... S ... a ... m ... s ... u ... n ... g ??

You know well that speaking to developers of high performance apps and games would illuminate your deceit. Surprised you'd put your personal rep at risk for something so transparent

MK
post #150 of 168
Quote:
Originally Posted by patpatpat View Post
 

You do realize that Java application code is completely independent of the processor architecture. As a developer there is nothing you need to do to support 64 bit.  (Unless you have some very specific native interface code in your app, which is not very common)

All apps compile to machine independent java byte code.

Googles 64-bit Dalvik VM has the task at runtime to convert the byte code into 64-bit processor specific instructions.

 

Form latest reports 48% of android users are on the latest android JellyBean (4.1+) which was released in July 2012. I'm not sure what you mean by "so many years"

 

This is not entirely true, java source code is alway 32 bit.  Dalvik byte code can run on any plateform compiled for sure, but this is where Qualcomm Rep is right about. Since VM platform completely masqueraded the CPU ISA, developer can't got all benefits of 64 bit native code in a byte code vm,  and will have very little performance gain (about 3% according to this site).

post #151 of 168
Quote:
Originally Posted by BigMac2 View Post
 

 

This is not entirely true, java source code is alway 32 bit.  Dalvik byte code can run on any plateform compiled for sure, but this is where Qualcomm Rep is right about. Since VM platform completely masqueraded the CPU ISA, developer can't got all benefits of 64 bit native code in a byte code vm,  and will have very little performance gain (about 3% according to this site).

 

That is the same for pretty much any 32-64 bit transition where the chip architecture doesn't undergo a major transformation. With the vastly optimized instruction set of armV8 you are going to get a similar performance boost that A7 got, just by virtue of the streamlined instruction set.

post #152 of 168
Quote:
Originally Posted by patpatpat View Post
 

 

That is the same for pretty much any 32-64 bit transition where the chip architecture doesn't undergo a major transformation. With the vastly optimized instruction set of armV8 you are going to get a similar performance boost that A7 got, just by virtue of the streamlined instruction set.

 

Not true,  DalvikVM is a 32 bit register base virtual machine, even compiled on a 64 bit plateform Dalvik virtual processor registers are still 32 bit only.  with a native compiled language like C or C++ for example when you declare an INT it will be 32 bit wide when compiled on a 32 bit platform and 64 bit wide on a 64 platform in java INT are always 32 bit.  Mike Ash article explain where Apple being in control of their own hardware and IDE can squeeze all benefits the A7 can gives. 


Edited by BigMac2 - 10/4/13 at 11:52am
post #153 of 168
Quote:
Originally Posted by BigMac2 View Post
 

 

Not true,  DalvikVM is a 32 bit register base virtual machine, even compiled on a 64 bit plateform Dalvik virtual processor registers are still 32 bit only.  with a native compiled language like C or C++ for example when you declare an INT it will be 32 bit wide when compiled on a 32 bit platform and 64 bit wide on a 64 platform in java INT are always 32 bit.  Mike Ash article explain where Apple being in control of their own hardware and IDE can squeeze all benefits the A7 can gives. 

 

It's pretty much been established that moving from 32 to 64 bit compilation will only result in about a 6% performance improvement. It has been generally agreed here and in most of the tech press that the major improvement in A7 was not the 64-bitness per se, rather the move to a much more efficient instruction set and additonal core functions like crypto. Any application that compiles for that instruction set, even the DalvikVM can take advantage of that.

post #154 of 168
Quote:
Originally Posted by BigMac2 View Post
 

 

Since VM platform completely masqueraded the CPU ISA, developer can't got all benefits of 64 bit native code in a byte code vm,  and will have very little performance gain (about 3% according to this site).

Wouldn't the VM itself be able to run faster once it's ported to ARMv8? I thought one of the main benefits of the abstraction layer afforded by the VM is that, at least in theory, the VM does all the hard work of tailoring programs to a specific architecture. For example, it's the VM's job to decide how to actually execute AES bytecode. Once Dalvik is ported to ARMv8 it should automatically run AES bytecode using the new AES hardware instructions with no input required of the program developers.

post #155 of 168
Quote:
Originally Posted by patpatpat View Post
 

 

It's pretty much been established that moving from 32 to 64 bit compilation will only result in about a 6% performance improvement. It has been generally agreed here and in most of the tech press that the major improvement in A7 was not the 64-bitness per se, rather the move to a much more efficient instruction set and additonal core functions like crypto. Any application that compiles for that instruction set, even the DalvikVM can take advantage of that.

 

I wonder how an apps developed on a 32 bit VM can tap all benefit of a 64 bit platform.  Apps running in a VM are stuck with the VM limits (8-16 bits opcode, 32 bits registers for DalvikVM). 


Edited by BigMac2 - 10/4/13 at 1:00pm
post #156 of 168
Quote:
Originally Posted by d4NjvRzf View Post
 

Wouldn't the VM itself be able to run faster once it's ported to ARMv8? I thought one of the main benefits of the abstraction layer afforded by the VM is that, at least in theory, the VM does all the hard work of tailoring programs to a specific architecture . For example, it's the VM's job to decide how to actually execute AES bytecode. Once Dalvik is ported to ARMv8 it should automatically run AES bytecode using the new AES hardware instructions with no input required of the program developers.

 

True, the VM itself would run faster once ported to ARMv8 in either AArch32 or AArch64 ISA,  but without major revision of the DalvikVM, virtualized apps is still running in a 32 bit environment only. 

post #157 of 168
Quote:
Originally Posted by BigMac2 View Post

True, the VM itself would run faster once ported to ARMv8 in either AArch32 or AArch64 ISA,  but without major revision of the DalvikVM, virtualized apps is still running in a 32 bit environment only. 

Why a major revision? There are plenty of 64bit jvms out there, I imagine that the dalvik switch to 64bit would be a fairly straightforward engineering task. It would have to be done in any case.
As far as java code is concerned, an int is always 32 bits and and a long is always 64. It doesn't matter whether the jvm is 64/32.
post #158 of 168
Quote:
Originally Posted by patpatpat View Post


Why a major revision? There are plenty of 64bit jvms out there, I imagine that the dalvik switch to 64bit would be a fairly straightforward engineering task. It would have to be done in any case.
As far as java code is concerned, an int is always 32 bits and and a long is always 64. It doesn't matter whether the jvm is 64/32.

 

Most JVMs are stack base, Dalvik in an other hand is register base with fixed width. 

post #159 of 168
Quote:
Originally Posted by BigMac2 View Post
 

 

True, the VM itself would run faster once ported to ARMv8 in either AArch32 or AArch64 ISA,  but without major revision of the DalvikVM, virtualized apps is still running in a 32 bit environment only. 

 

It's true that as long as Dalvik only exposes 32-bit registers to programs, virtualized apps would still run in a 32-bit environment. 
But they should still experience performance benefits as the VM handles the associations between bytecode and hardware instructions behind the scenes. In this case, a 64-bit Dalvik would run bytecode using the AArch64 ISA. The apps won't be able to take advantage of 64 bit registers, but as your Red Hat link shows, when all other factors are equal the performance delta between 32 bit and 64 bit builds of a program is quite small except in memory constrained situations.

post #160 of 168
Quote:
Originally Posted by d4NjvRzf View Post
 

 

It's true that as long as Dalvik only exposes 32-bit registers to programs, virtualized apps would still run in a 32-bit environment. 
But they should still experience performance benefits as the VM handles the associations between bytecode and hardware instructions behind the scenes. In this case, a 64-bit Dalvik would run bytecode using the AArch64 ISA. The apps won't be able to take advantage of 64 bit registers, but as your Red Hat link shows, when all other factors are equal the performance delta between 32 bit and 64 bit builds of a program is quite small except in memory constrained situations.

 

DalvikVM is a 32 bit virtual computer (machine), while the VM can be ported on any platform, the virtualized machine always have the same 32 bit specs regarding is opcode and register,  limiting apps on a virtualized 32 bit platform only.  

 

To be clear, I agree DalvikVM and virtualized Apps should have some benefit from all the changes in the ARMv8 platform like any other apps.  But apps developers for DalvikVM won't be able use AArch64 features explicitly. 


Edited by BigMac2 - 10/4/13 at 1:48pm
New Posts  All Forums:Forum Nav:
  Return Home
  Back to Forum: iPhone
  • Apple partner Qualcomm pans iPhone 5s A7 CPU as 'gimmick,' yet hints at own 64-bit chip
AppleInsider › Forums › Mobile › iPhone › Apple partner Qualcomm pans iPhone 5s A7 CPU as 'gimmick,' yet hints at own 64-bit chip