Originally Posted by d4NjvRzf
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.
Edited by BigMac2 - 12/4/13 at 5:17pm