The claim about threading is really weird because Dalvik should be mapping Java threads to OS threads, anything different from that is stupid. And it's the OS that should be aware of HT or not, not the Dalvik VM. It's also really backwards to think that a lack of HT would confuse a thread scheduler, why would it behave any differently than any other normal 4 core processor? The whole thing is mind boggling.
Looking at those AndEBench numbers is really depressing. Those are the same algorithms and everything, one coded for Java and the other coded for C.. and the Java version is 28x slower even for the S800. Part of this is going to be due to differences in "natural" Java vs C coding style and the nature of their standard libraries, and part of it will be fundamental to the nature of JIT vs AOT compilation. But it shouldn't be anywhere close to this bad, yet it is. Dalvik clearly still sucks with JIT code quality. Some analysis on EEMBC's part shows that AndE is spending a lot of time in the interpreter despite consisting heavily of tight loops https://groups.google.com/forum/?hl=en#!topic/eembc-andebench/hubWNcf-rLE But that's probably just the tip of the iceberg.
It's really quite comical when you stop and think about it. People will declare that company A will crush company B when their CPU is a little faster or a little bit more power efficient. But when looking at software problems that cause orders of magnitude inferior performance than could be attained everyone looks the other way (or probably doesn't realize it). Too many mobile benchmarks people focus on today are with these extremely inefficient languages/VMs and extremely inefficient software written to use them. I'm really looking more at Javascript than anything, not a ton of Dalvik benches out there.
Looking at those AndEBench numbers is really depressing. Those are the same algorithms and everything, one coded for Java and the other coded for C.. and the Java version is 28x slower even for the S800. Part of this is going to be due to differences in "natural" Java vs C coding style and the nature of their standard libraries, and part of it will be fundamental to the nature of JIT vs AOT compilation. But it shouldn't be anywhere close to this bad, yet it is. Dalvik clearly still sucks with JIT code quality. Some analysis on EEMBC's part shows that AndE is spending a lot of time in the interpreter despite consisting heavily of tight loops https://groups.google.com/forum/?hl=en#!topic/eembc-andebench/hubWNcf-rLE But that's probably just the tip of the iceberg.
It's really quite comical when you stop and think about it. People will declare that company A will crush company B when their CPU is a little faster or a little bit more power efficient. But when looking at software problems that cause orders of magnitude inferior performance than could be attained everyone looks the other way (or probably doesn't realize it). Too many mobile benchmarks people focus on today are with these extremely inefficient languages/VMs and extremely inefficient software written to use them. I'm really looking more at Javascript than anything, not a ton of Dalvik benches out there.
Facebook
Twitter