or Connect
New Posts  All Forums:

Posts by BigMac2

 What is your points? Yes they are other bytecode environment, iOS and OSX compiler itself is the prime example of a low level virtual machine bytecode runtime environment as LLVM stands for.   Beside you can't compare a byte coded binary apps coming from compiler like .NET or LLVM, running on a really thin abstraction layer more like a virtual hypervisor than fully Virtualized machine like Java SE, DalvikVM or ART.  The performance taxes much less to do with how fast the...
 You've got a good point here, ART can run Dalvik apps, so it should use the same Java-ish API from Dalvik. 
 That make me laugh, ART is still a VM but instead of a JIT like Dalvik, ART is an OAT (Ahead-of-time), this mean apps still got a performance taxes from running inside a virtual machine abstraction layer.   If ART yields so much better performance, but still can't match native compiled C code, does it confirm how bad current Dalvik performances are?
 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...
 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...
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...
 True, Android operating system could run natively on a 64bit hardware. But porting Dalvik on another architecture It doesn't change Dalvik virtual processor specs, since Dalvik are a register base VM and not a traditional stack VM like Java SE, the virtualized register are fixed width at 32bit and can't be change without a major revision of DalvikVM specs.   It's like using a 32 bit virtual machine with Parallels desktop, even if you're using a 64 bit host computer, the...
 Running the VM on a 64bit processor is one thing,  the virtualized environment where apps are running is still a 32 bit one.
I think there is another reason not addressed in the article for Google to move away from Dalvik VM.  By using a register based Java virtual machine, Androids runtimes are forever stuck in a 32 bit environment and unable to directly use new hardware features of future ARM SoC.
The rule of thumb is avoid buy/use anything you can't identify a brand on it.   If the mfg is ashamed to put his name on it, why you should trust their product?
New Posts  All Forums: