so unless I'm not understanding this correctly, the new Android Run Time is Google's response to the situation with Dalvik. As I understand it, ART allows the CPU to directly execute the native code of android apps, rather than having to first be interpreted, a la Dalvik (this is how java works as well). The advantages are obvious in terms of performance.
And the best part? you can enable ART right now, and most apps are working fine without any tweaks. Many apps have benefited with a noticeable increase in performance, as well. I'm running ART on my nexus 5/7, and all my apps are working with the exception of whatsapp. here is a good explanation of ART vs. Dalvik
So in summary, I think the premise of this article is flawed. chrome is not the solution, ART is, and it's already baked into Android 4.4
Very good read, and for those who thing ART is the fix, think again. It just another band-aid in an already poor architecture Andy choose to go forward with. I never realize that Android was an interrupter and the apps were not actually compiles. This allows for bad programming habits and explain why Android apps just do not work as well as they iOS equivalent.
The google store will still be load with Apps design to run in a Java environment and you have to guess how long it will take developers to convert all their apps to be compiled code. You know as long as old non-ART version are still out there developers will hold off. Every time you load an apple it have to make sure the ART feature is enable so that it compiles the program so it will run faster otherwise it will be like running on non-ART systems. What a kludge they have put together here.
As I said before it will be another level of fragmentation they will introduce to developers and consumer to deal with.
Running the VM on a 64bit processor is one thing, the virtualized environment where apps are running is still a 32 bit one.
Is there anything preventing 32bit apps in the VM from nonetheless benefiting from the improvements in AArch64? If I understand correctly, It's important for programs running directly on the CPU to be recompiled for AArch64 because ARMv8 only exposes its new instructions and other architectural improvements to to programs compiled for AArch64; 32 bit apps run on ARMv8 essentially using an ARMv7 compatibility mode and perform as if they are running on an ARMv7 chip. This is different from the situation with Intel CPUs, where both x86 and x86-64 programs can use instructions like AES-NI and SSE. If you are virtualizing a processor, however, what prevents you from, for example, providing 32 bit virtual AES instructions to applications which the VM executes using the AArch64 AES hardware instructions?
Android is pathetic and it served as the os for all those cheap ass black Friday $49.99 tablets Best Buy had tossed into those big ole plastic grab and go(suckers) containers.
I never realize that Android was an interrupter and the apps were not actually compiles. This allows for bad programming habits and explain why Android apps just do not work as well as they iOS equivalent.
An interpreter you mean? Yes and no, DalvikVM is a JIT compiler which is an in-between from interpreter and compiler. The byte code output from source code is like an intermediate pre-digested from of compiled code ready to be interpreted at runtime, which obfuscate the source code in distributed apps and offer greater performance than plain interpreted codes.
But all this magic doesn't gives you performance on par with true compiled apps, like you said those are band-aids solution for heterogenous hardware platform mess that Android already is.
An interpreter you mean? Yes and no, DalvikVM is a JIT compiler which is an in-between from interpreter and compiler. The byte code output from source code is like an intermediate pre-digested from of compiled code ready to be interpreted at runtime, which obfuscate the source code in distributed apps and offer greater performance than plain interpreted codes.
But all this magic doesn't gives you performance on par with true compiled apps, like you said those are band-aids solution for heterogenous hardware platform mess that Android already is.
sorry i was paraphrasing a bit without rehashing the entire article. It is still a screwed up architecture that is for sure, and they appear to be making it worse, just another layer of things to deal with. The question is when will or will they go to ART only which mean it will obsolete all apps which is not compiled to begin with, or they will have to compile on download with is asking for issue. When I wrote code some program work fine while running under an interpreter, and they had issue once compiled so they are not always 100% the same.
Is there anything preventing 32bit apps in the VM from nonetheless benefiting from the improvements in AArch64? If I understand correctly, It's important for programs running directly on the CPU to be recompiled for AArch64 because ARMv8 only exposes its new instructions and other architectural improvements to to programs compiled for AArch64; 32 bit apps run on ARMv8 essentially using an ARMv7 compatibility mode and perform as if they are running on an ARMv7 chip. This is different from the situation with Intel CPUs, where both x86 and x86-64 programs can use instructions like AES-NI and SSE. If you are virtualizing a processor, however, what prevents you from, for example, providing 32 bit virtual AES instructions to applications which the VM executes using the AArch64 AES hardware instructions?
Nothing can prevent a VM based apps from running on any environment as long the VM is compiled to run on this environment. But you've got to understand the difference between the host architecture and the virtualized one, both got their own specs that doesn't depend from each other. It's like having an emulator, Google could have choose Dosbox has runtime VM, porting Dosbox on any platform won't change specs of the VM seeing by any apps running inside the VM, this is what assuring apps targeted for DalvikVM to run on anywhere the VM can be compiled on.
Commonly VM won't tap any feature specific some hardware to preserve they're portability nature, and the virtualized environment needs to keeps there instructions set and register width fixed for compatibility propose. You can check at Microsoft .NET mess, .NET is based on a register VM and because of that every major revision of .NET is incompatible with the previous version, forcing every user to keeps multiple version of .NET lib up to date on their computer.
Nothing can prevent a VM based apps from running on any environment as long the VM is compiled to run on this environment. But you've got to understand the difference between the host architecture and the virtualized one, both got their own specs that doesn't depend from each other. It's like having an emulator, Google could have choose Dosbox has runtime VM, porting Dosbox on any platform won't change specs of the VM seeing by any apps running inside the VM, this is what assuring apps targeted for DalvikVM to run on anywhere the VM can be compiled on.
Commonly VM won't tap any feature specific some hardware to preserve they're portability nature, and the virtualized environment needs to keeps there instructions set and register width fixed for compatibility propose. You can check at Microsoft .NET mess, .NET is based on a register VM and because of that every major revision of .NET is incompatible with the previous version, forcing every user to keeps multiple version of .NET lib up to date on their computer.
My original post was in regards to your quote "Running the VM on a 64bit processor is one thing, the virtualized environment where apps are running is still a 32 bit one." Maybe I didn't read this correctly, but it seems that your implication was that the particular fact that the virtualized registers are 32 bits wide is holding back the apps from benefiting from AArch64's performance improvements. My point was that the number "32" becomes somewhat of a red herring when apps don't directly see the underlying hardware because the VM might be able to abstract some of the architectural improvements of AArch64 from the register width. As seen in this example (http://software.intel.com/en-us/articles/intel-aes-ni-performance-testing-on-linuxjava-stack), the VM decides behind the scenes whether to use hardware-specific instructions like AES-NI while presenting the same virtual machine to programs.
The fact that many standard CPU benchmarks are java based suggests that a well-designed VM should be able to tailor its execution to the underlying hardware independently of the virtual interface it presents to bytecode, and that performance of programs on such VMs should directly reflect the capabilities of the hardware. While you may have a point about hardware-specific features when they are sufficiently obscure, ARMv8 is hardly a niche architecture. Perhaps there's something specific to the implementation of Dalvik that prevents it from providing such automatic benefits, but I don't think those have been discussed here.
I read this up until I saw the words "MORANIAN MULLEUR~"
Moranian has already admitted in court to being a paid schill for Oracle and Microsoft. For any one to quote him as an authority is just ridiculous. He should have lost all credibility last year when he guaranteed that Oracle had 6 BILLION in the bag on the initial complaint.
Author must be 12 years old or not able to research.
so unless I'm not understanding this correctly, the new Android Run Time is Google's response to the situation with Dalvik. As I understand it, ART allows the CPU to directly execute the native code of android apps, rather than having to first be interpreted, a la Dalvik (this is how java works as well). The advantages are obvious in terms of performance.
And the best part? you can enable ART right now, and most apps are working fine without any tweaks. Many apps have benefited with a noticeable increase in performance, as well. I'm running ART on my nexus 5/7, and all my apps are working with the exception of whatsapp. here is a good explanation of ART vs. Dalvik
So in summary, I think the premise of this article is flawed. chrome is not the solution, ART is, and it's already baked into Android 4.4
Well that may be the official story of what Android will be doing, but given that the majority of quite new Android phones can’t run Android 4.4, and won’t ever get updates, there is not an installed base of A4.4 to write software.
Given that nobody is starting their business on Android, and that even successful developers only make placeholder efforts to support Android users, why would anyone target the new ART platform running on a sliver of the installed base of iOS 7 devices? They might as well write apps for BB10, WP8 or PalmOS.
Simple story is that Mueller has form, and that takes away his credibility. Just Google his name, blog name and Groklaw in the same sentence, and his track record as a paid shill is laid bare. Honest bloggers declare any financial interest; it doesn't normally need Techcrunch or Judge Alsup to out them first.
Who he selectively picks words from is of no consequence. He makes his own bed as far as credibility is concerned.
If you read Mueller’s work he supports his opinions with legally sound ideas that, over time, have an extremely high accuracy rate. Compare that to the Android fans who love Google so much they are now on the fifth generation of expectation of the Coming of the Android Prophet Phone.
Google has failed worldwide in courts on both sides: found to be willingly infringing IP of others while professing a disdain for patents, and at the same time hypocritically suing other companies over Standards Essential Patents. That’s something that both the US and EU have been investigating as antitrust behavior. Abusively trying to hurt customers (like Apple’s push mail service in Germany, feature blocked by a temporary injunction that Google got before it failed to prove involved any infringement).
As for your personal attacks about how Mueller is a consultant in an industry where he works for some of the companies he reports on: baseless, character assassination makes you look very lacking in credibility.
Fair use? Google claims that their use of Java Code is fair use? Building a whole line of business based on someone else's proprietary material is fair use? Ha, ha, ha.
Not only that, they copied the Java codes without even changing the name and "comments", just plain copy and paste...wtf.
so unless I'm not understanding this correctly, the new Android Run Time is Google's response to the situation with Dalvik. As I understand it, ART allows the CPU to directly execute the native code of android apps, rather than having to first be interpreted, a la Dalvik (this is how java works as well). The advantages are obvious in terms of performance.
And the best part? you can enable ART right now, and most apps are working fine without any tweaks. Many apps have benefited with a noticeable increase in performance, as well. I'm running ART on my nexus 5/7, and all my apps are working with the exception of whatsapp. here is a good explanation of ART vs. Dalvik
So in summary, I think the premise of this article is flawed. chrome is not the solution, ART is, and it's already baked into Android 4.4
It is a sensationalist article. The idea that Google is shifting to Chrome as a solution is complete nonsense. Google is moving towards ART like you mentioned which compiles downloaded apps to native code rather than interpreted via Dalvik. Plus, it yields far better performance.
Well that may be the official story of what Android will be doing, but given that the majority of quite new Android phones can’t run Android 4.4, and won’t ever get updates, there is not an installed base of A4.4 to write software.
Given that nobody is starting their business on Android, and that even successful developers only make placeholder efforts to support Android users, why would anyone target the new ART platform running on a sliver of the installed base of iOS 7 devices? They might as well write apps for BB10, WP8 or PalmOS.
Developers do not need to target ART. Enabling ART on Android 4.4+ just compiles apps into native code upon download for that phone's architecture.
My original post was in regards to your quote "Running the VM on a 64bit processor is one thing, the virtualized environment where apps are running is still a 32 bit one." Maybe I didn't read this correctly, but it seems that your implication was that the particular fact that the virtualized registers are 32 bits wide is holding back the apps from benefiting from AArch64's performance improvements. My point was that the number "32" becomes somewhat of a red herring when apps don't directly see the underlying hardware because the VM might be able to abstract some of the architectural improvements of AArch64 from the register width. As seen in this example (http://software.intel.com/en-us/articles/intel-aes-ni-performance-testing-on-linuxjava-stack), the VM decides behind the scenes whether to use hardware-specific instructions like AES-NI while presenting the virtual machine to programs.
The fact that many standard CPU benchmarks are java based suggests that a well-designed VM should be able to tailor its execution to the underlying hardware independently of the virtual interface it presents to bytecode, and that performance of programs on such VMs should directly reflect the capabilities of the hardware. While you may have a point about hardware-specific features when they are sufficiently obscure, ARMv8 is hardly a niche architecture. Perhaps there's something specific to the implementation of Dalvik that prevents it from providing such automatic benefits, but I don't think those have been discussed here.
I agree, I put it badly. Here is some precisions.
I implied any VM like Dalvik acted just like a DosBox or an emulator, the recompiled VM itself will gain benefit of new AArch64 improvements like any other compiled apps for that platform, but those benefit will be out of control from apps running inside of the VM, for those apps nothing change: Instruction set, number of register and register width. I do realize, just like real CPU, those thing can be "augmented" or improve overtime, but if you remember the early PC days the passage from the XT to the AT those things tend to break legacy stuff, this is why we are now using OS with kernels to hide the hardware as much as they can from the software, now having a kernels in a VM is a stupid things to add an other level of HAL over Dalvik and Android OS already. So they kept Dalvik VM as simple as it should for running apps quickly with the lowest memory footprint as possible and never being designed for future improvements in mind.
Also, Java SE and DalvikVM are designed differently, where one use a stack without fixed register count or width, the other is replicating the real hardware approach of a fixe count and width of register and a set of ASM instructions. For the java performance test, Intel needed a new compiler, an OS running natively on the platform, some special lib, a recompiled version of JavaVM with those special lib and a java test apps that can only run on this JavaVM setup. I don't say It can't be done, I just say Google got a very long road ahead to fully update their environment before developers could harvest every benefits of a 64bit platforms. They already can't tap every ARMv7 current feature from inside the DalvikVM. Google approach just look like Microsoft one as they just keep multiplying new runtimes environment: Win32, Win64, and every iteration of .NET since.
Comments
so unless I'm not understanding this correctly, the new Android Run Time is Google's response to the situation with Dalvik. As I understand it, ART allows the CPU to directly execute the native code of android apps, rather than having to first be interpreted, a la Dalvik (this is how java works as well). The advantages are obvious in terms of performance.
And the best part? you can enable ART right now, and most apps are working fine without any tweaks. Many apps have benefited with a noticeable increase in performance, as well. I'm running ART on my nexus 5/7, and all my apps are working with the exception of whatsapp. here is a good explanation of ART vs. Dalvik
http://www.extremetech.com/computing/170677-android-art-google-finally-moves-to-replace-dalvik-to-boost-performance-and-battery-life
So in summary, I think the premise of this article is flawed. chrome is not the solution, ART is, and it's already baked into Android 4.4
Very good read, and for those who thing ART is the fix, think again. It just another band-aid in an already poor architecture Andy choose to go forward with. I never realize that Android was an interrupter and the apps were not actually compiles. This allows for bad programming habits and explain why Android apps just do not work as well as they iOS equivalent.
The google store will still be load with Apps design to run in a Java environment and you have to guess how long it will take developers to convert all their apps to be compiled code. You know as long as old non-ART version are still out there developers will hold off. Every time you load an apple it have to make sure the ART feature is enable so that it compiles the program so it will run faster otherwise it will be like running on non-ART systems. What a kludge they have put together here.
As I said before it will be another level of fragmentation they will introduce to developers and consumer to deal with.
Running the VM on a 64bit processor is one thing, the virtualized environment where apps are running is still a 32 bit one.
Is there anything preventing 32bit apps in the VM from nonetheless benefiting from the improvements in AArch64? If I understand correctly, It's important for programs running directly on the CPU to be recompiled for AArch64 because ARMv8 only exposes its new instructions and other architectural improvements to to programs compiled for AArch64; 32 bit apps run on ARMv8 essentially using an ARMv7 compatibility mode and perform as if they are running on an ARMv7 chip. This is different from the situation with Intel CPUs, where both x86 and x86-64 programs can use instructions like AES-NI and SSE. If you are virtualizing a processor, however, what prevents you from, for example, providing 32 bit virtual AES instructions to applications which the VM executes using the AArch64 AES hardware instructions?
My comment was written in the hypothetical situation that Android is dead in the water and they have no other option. That is what I'd call a win win.
I'll drink to that! :smokey:
They are that expensive! Really?
I never realize that Android was an interrupter and the apps were not actually compiles. This allows for bad programming habits and explain why Android apps just do not work as well as they iOS equivalent.
An interpreter you mean? Yes and no, DalvikVM is a JIT compiler which is an in-between from interpreter and compiler. The byte code output from source code is like an intermediate pre-digested from of compiled code ready to be interpreted at runtime, which obfuscate the source code in distributed apps and offer greater performance than plain interpreted codes.
But all this magic doesn't gives you performance on par with true compiled apps, like you said those are band-aids solution for heterogenous hardware platform mess that Android already is.
An interpreter you mean? Yes and no, DalvikVM is a JIT compiler which is an in-between from interpreter and compiler. The byte code output from source code is like an intermediate pre-digested from of compiled code ready to be interpreted at runtime, which obfuscate the source code in distributed apps and offer greater performance than plain interpreted codes.
But all this magic doesn't gives you performance on par with true compiled apps, like you said those are band-aids solution for heterogenous hardware platform mess that Android already is.
sorry i was paraphrasing a bit without rehashing the entire article. It is still a screwed up architecture that is for sure, and they appear to be making it worse, just another layer of things to deal with. The question is when will or will they go to ART only which mean it will obsolete all apps which is not compiled to begin with, or they will have to compile on download with is asking for issue. When I wrote code some program work fine while running under an interpreter, and they had issue once compiled so they are not always 100% the same.
Is there anything preventing 32bit apps in the VM from nonetheless benefiting from the improvements in AArch64? If I understand correctly, It's important for programs running directly on the CPU to be recompiled for AArch64 because ARMv8 only exposes its new instructions and other architectural improvements to to programs compiled for AArch64; 32 bit apps run on ARMv8 essentially using an ARMv7 compatibility mode and perform as if they are running on an ARMv7 chip. This is different from the situation with Intel CPUs, where both x86 and x86-64 programs can use instructions like AES-NI and SSE. If you are virtualizing a processor, however, what prevents you from, for example, providing 32 bit virtual AES instructions to applications which the VM executes using the AArch64 AES hardware instructions?
Nothing can prevent a VM based apps from running on any environment as long the VM is compiled to run on this environment. But you've got to understand the difference between the host architecture and the virtualized one, both got their own specs that doesn't depend from each other. It's like having an emulator, Google could have choose Dosbox has runtime VM, porting Dosbox on any platform won't change specs of the VM seeing by any apps running inside the VM, this is what assuring apps targeted for DalvikVM to run on anywhere the VM can be compiled on.
Commonly VM won't tap any feature specific some hardware to preserve they're portability nature, and the virtualized environment needs to keeps there instructions set and register width fixed for compatibility propose. You can check at Microsoft .NET mess, .NET is based on a register VM and because of that every major revision of .NET is incompatible with the previous version, forcing every user to keeps multiple version of .NET lib up to date on their computer.
Nothing can prevent a VM based apps from running on any environment as long the VM is compiled to run on this environment. But you've got to understand the difference between the host architecture and the virtualized one, both got their own specs that doesn't depend from each other. It's like having an emulator, Google could have choose Dosbox has runtime VM, porting Dosbox on any platform won't change specs of the VM seeing by any apps running inside the VM, this is what assuring apps targeted for DalvikVM to run on anywhere the VM can be compiled on.
Commonly VM won't tap any feature specific some hardware to preserve they're portability nature, and the virtualized environment needs to keeps there instructions set and register width fixed for compatibility propose. You can check at Microsoft .NET mess, .NET is based on a register VM and because of that every major revision of .NET is incompatible with the previous version, forcing every user to keeps multiple version of .NET lib up to date on their computer.
My original post was in regards to your quote "Running the VM on a 64bit processor is one thing, the virtualized environment where apps are running is still a 32 bit one." Maybe I didn't read this correctly, but it seems that your implication was that the particular fact that the virtualized registers are 32 bits wide is holding back the apps from benefiting from AArch64's performance improvements. My point was that the number "32" becomes somewhat of a red herring when apps don't directly see the underlying hardware because the VM might be able to abstract some of the architectural improvements of AArch64 from the register width. As seen in this example (http://software.intel.com/en-us/articles/intel-aes-ni-performance-testing-on-linuxjava-stack), the VM decides behind the scenes whether to use hardware-specific instructions like AES-NI while presenting the same virtual machine to programs.
The fact that many standard CPU benchmarks are java based suggests that a well-designed VM should be able to tailor its execution to the underlying hardware independently of the virtual interface it presents to bytecode, and that performance of programs on such VMs should directly reflect the capabilities of the hardware. While you may have a point about hardware-specific features when they are sufficiently obscure, ARMv8 is hardly a niche architecture. Perhaps there's something specific to the implementation of Dalvik that prevents it from providing such automatic benefits, but I don't think those have been discussed here.
I read this up until I saw the words "MORANIAN MULLEUR~"
Moranian has already admitted in court to being a paid schill for Oracle and Microsoft. For any one to quote him as an authority is just ridiculous. He should have lost all credibility last year when he guaranteed that Oracle had 6 BILLION in the bag on the initial complaint.
Author must be 12 years old or not able to research.
Yup. And 16-bit DOS programs can, and in fact run, on 64-bit intel processors already.
Google stole Android? The company that does no evil? Maybe that's weevil.
so unless I'm not understanding this correctly, the new Android Run Time is Google's response to the situation with Dalvik. As I understand it, ART allows the CPU to directly execute the native code of android apps, rather than having to first be interpreted, a la Dalvik (this is how java works as well). The advantages are obvious in terms of performance.
And the best part? you can enable ART right now, and most apps are working fine without any tweaks. Many apps have benefited with a noticeable increase in performance, as well. I'm running ART on my nexus 5/7, and all my apps are working with the exception of whatsapp. here is a good explanation of ART vs. Dalvik
http://www.extremetech.com/computing/170677-android-art-google-finally-moves-to-replace-dalvik-to-boost-performance-and-battery-life
So in summary, I think the premise of this article is flawed. chrome is not the solution, ART is, and it's already baked into Android 4.4
Well that may be the official story of what Android will be doing, but given that the majority of quite new Android phones can’t run Android 4.4, and won’t ever get updates, there is not an installed base of A4.4 to write software.
Given that nobody is starting their business on Android, and that even successful developers only make placeholder efforts to support Android users, why would anyone target the new ART platform running on a sliver of the installed base of iOS 7 devices? They might as well write apps for BB10, WP8 or PalmOS.
Bye bye, Android. Hardly knew ya.
Simple story is that Mueller has form, and that takes away his credibility. Just Google his name, blog name and Groklaw in the same sentence, and his track record as a paid shill is laid bare. Honest bloggers declare any financial interest; it doesn't normally need Techcrunch or Judge Alsup to out them first.
Who he selectively picks words from is of no consequence. He makes his own bed as far as credibility is concerned.
If you read Mueller’s work he supports his opinions with legally sound ideas that, over time, have an extremely high accuracy rate. Compare that to the Android fans who love Google so much they are now on the fifth generation of expectation of the Coming of the Android Prophet Phone.
Google has failed worldwide in courts on both sides: found to be willingly infringing IP of others while professing a disdain for patents, and at the same time hypocritically suing other companies over Standards Essential Patents. That’s something that both the US and EU have been investigating as antitrust behavior. Abusively trying to hurt customers (like Apple’s push mail service in Germany, feature blocked by a temporary injunction that Google got before it failed to prove involved any infringement).
As for your personal attacks about how Mueller is a consultant in an industry where he works for some of the companies he reports on: baseless, character assassination makes you look very lacking in credibility.
Fair use? Google claims that their use of Java Code is fair use? Building a whole line of business based on someone else's proprietary material is fair use? Ha, ha, ha.
Not only that, they copied the Java codes without even changing the name and "comments", just plain copy and paste...wtf.
so unless I'm not understanding this correctly, the new Android Run Time is Google's response to the situation with Dalvik. As I understand it, ART allows the CPU to directly execute the native code of android apps, rather than having to first be interpreted, a la Dalvik (this is how java works as well). The advantages are obvious in terms of performance.
And the best part? you can enable ART right now, and most apps are working fine without any tweaks. Many apps have benefited with a noticeable increase in performance, as well. I'm running ART on my nexus 5/7, and all my apps are working with the exception of whatsapp. here is a good explanation of ART vs. Dalvik
http://www.extremetech.com/computing/170677-android-art-google-finally-moves-to-replace-dalvik-to-boost-performance-and-battery-life
So in summary, I think the premise of this article is flawed. chrome is not the solution, ART is, and it's already baked into Android 4.4
It is a sensationalist article. The idea that Google is shifting to Chrome as a solution is complete nonsense. Google is moving towards ART like you mentioned which compiles downloaded apps to native code rather than interpreted via Dalvik. Plus, it yields far better performance.
Well that may be the official story of what Android will be doing, but given that the majority of quite new Android phones can’t run Android 4.4, and won’t ever get updates, there is not an installed base of A4.4 to write software.
Given that nobody is starting their business on Android, and that even successful developers only make placeholder efforts to support Android users, why would anyone target the new ART platform running on a sliver of the installed base of iOS 7 devices? They might as well write apps for BB10, WP8 or PalmOS.
Developers do not need to target ART. Enabling ART on Android 4.4+ just compiles apps into native code upon download for that phone's architecture.
My original post was in regards to your quote "Running the VM on a 64bit processor is one thing, the virtualized environment where apps are running is still a 32 bit one." Maybe I didn't read this correctly, but it seems that your implication was that the particular fact that the virtualized registers are 32 bits wide is holding back the apps from benefiting from AArch64's performance improvements. My point was that the number "32" becomes somewhat of a red herring when apps don't directly see the underlying hardware because the VM might be able to abstract some of the architectural improvements of AArch64 from the register width. As seen in this example (http://software.intel.com/en-us/articles/intel-aes-ni-performance-testing-on-linuxjava-stack), the VM decides behind the scenes whether to use hardware-specific instructions like AES-NI while presenting the virtual machine to programs.
The fact that many standard CPU benchmarks are java based suggests that a well-designed VM should be able to tailor its execution to the underlying hardware independently of the virtual interface it presents to bytecode, and that performance of programs on such VMs should directly reflect the capabilities of the hardware. While you may have a point about hardware-specific features when they are sufficiently obscure, ARMv8 is hardly a niche architecture. Perhaps there's something specific to the implementation of Dalvik that prevents it from providing such automatic benefits, but I don't think those have been discussed here.
I agree, I put it badly. Here is some precisions.
I implied any VM like Dalvik acted just like a DosBox or an emulator, the recompiled VM itself will gain benefit of new AArch64 improvements like any other compiled apps for that platform, but those benefit will be out of control from apps running inside of the VM, for those apps nothing change: Instruction set, number of register and register width. I do realize, just like real CPU, those thing can be "augmented" or improve overtime, but if you remember the early PC days the passage from the XT to the AT those things tend to break legacy stuff, this is why we are now using OS with kernels to hide the hardware as much as they can from the software, now having a kernels in a VM is a stupid things to add an other level of HAL over Dalvik and Android OS already. So they kept Dalvik VM as simple as it should for running apps quickly with the lowest memory footprint as possible and never being designed for future improvements in mind.
Also, Java SE and DalvikVM are designed differently, where one use a stack without fixed register count or width, the other is replicating the real hardware approach of a fixe count and width of register and a set of ASM instructions. For the java performance test, Intel needed a new compiler, an OS running natively on the platform, some special lib, a recompiled version of JavaVM with those special lib and a java test apps that can only run on this JavaVM setup. I don't say It can't be done, I just say Google got a very long road ahead to fully update their environment before developers could harvest every benefits of a 64bit platforms. They already can't tap every ARMv7 current feature from inside the DalvikVM. Google approach just look like Microsoft one as they just keep multiplying new runtimes environment: Win32, Win64, and every iteration of .NET since.