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 5

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

 

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 Dalvik developers won't be able use AArch64 features explicitly. 

I'm still not convinced that reworking DalvikVM for 64-bits is a monumental task. Perhaps even, the benefit might only be minimal...

(But I'll be the first to admit I don't know a lot about Dalvik :-) )

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

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. 

 

 

 

Agreed. But the point of virtualization is that, in most cases, the VM invokes architecture-specific features for you. 

 

Here is an example of virtualized apps getting performance increases for free when the VM is ported to newer hardware: http://software.intel.com/en-us/articles/intel-aes-ni-performance-testing-on-linuxjava-stack#enable-intel-eas-ni-in-oracle-jvm. That report measures the performance of the same java app depending on whether the VM uses Intel's AES-NI instructions behind the scenes. The only difference between the two trials is whether AES-NI is enabled in BIOS.


Edited by d4NjvRzf - 10/4/13 at 2:22pm
post #163 of 168
Quote:
Originally Posted by patpatpat View Post
 

I'm still not convinced that reworking DalvikVM for 64-bits is a monumental task. Perhaps even, the benefit might only be minimal...

(But I'll be the first to admit I don't know a lot about Dalvik :-) )

 

I haven't said it's an impossible task,  still a task no one as done yet and potentially have some major compatibility impact. I'm sure it will be done soon enough but I'm curious how they will implemented it. 

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

Agreed. But the point of virtualization is that, in most cases, the VM invokes architecture-specific features for you. 

 

Here is an example of virtualized apps getting performance increases for free when the VM is ported to newer hardware: http://software.intel.com/en-us/articles/intel-aes-ni-performance-testing-on-linuxjava-stack#enable-intel-eas-ni-in-oracle-jvm. That report measures the performance of the same java app depending on whether the VM uses Intel's AES-NI instructions behind the scenes. The only difference between the two trials is whether AES-NI is enabled in BIOS.

 

Yes, this is more or less the same advantages native apps got when calling system API.  I just didn't get why they are using a VM when it doesn't need cross-platform apps, VM apps can't beat native code on efficiency.

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

 

Yes, this is more or less the same advantages native apps got when calling system API.  I just didn't get why they are using a VM when it doesn't need cross-platform apps, VM apps can't beat native code on efficiency.

 

I've seen reports of native being 20x faster (and higher) than Java on android. 

post #166 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"

 

My Galaxy S4 is on 4.2.2, a firmware "update" appeared the other day but it wasn't to 4.3 which as far as I know is the "latest" version.

 

I updated my iPhone 4 to iOS 7, on the day of release and it's over three years old.

 

There is the difference.

A problem occurred with this webpage so it was reloaded.A problem occurred with this webpage so it was reloaded.A problem occurred with this webpage so it was reloaded.A problem occurred with this...
Reply
A problem occurred with this webpage so it was reloaded.A problem occurred with this webpage so it was reloaded.A problem occurred with this webpage so it was reloaded.A problem occurred with this...
Reply
post #167 of 168
Quote:
Originally Posted by patpatpat View Post
 

 

I've seen reports of native being 20x faster (and higher) than Java on android. 

 

Speed is a very subjective matter and can be fixed with many subterfuge like Samsung has demonstrate with their overdriven benchmarks, I much prefer talking about efficiency.   While I found 20x a bit high, I do tend to believe there is a big energy taxes using JVM than using native code.

post #168 of 168

From Daring Fireball:

 

Agam Shah, reporting for IDG:

“The comments made by Anand Chandrasekher, Qualcomm CMO, about 64-bit computing were inaccurate,” said a Qualcomm spokesperson in an email. “The mobile hardware and software ecosystem is already moving in the direction of 64-bit; and, the evolution to 64-bit brings desktop class capabilities and user experiences to mobile, as well as enabling mobile processors and software to run new classes of computing devices.”

Qualcomm did not provide further comment.

 

http://daringfireball.net/linked/2013/10/08/qualcomm

 

Oh boy.

"We're Apple. We don't wear suits. We don't even own suits."
Reply
"We're Apple. We don't wear suits. We don't even own suits."
Reply
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