"Hate to sound like I'm harping on the same stuff, but then (assuming that the JVM/JIT compiler is doing good enough), the memory bottleneck still remains."
Yep, much of our effort on iSeries went into the memory bottleneck area. Eg, we got fairly astounding improvements (ca 20%) when we "packed" objects so that the fields of "SubclassOfA" filled in the "holes" left from aligning the fields of "A". And even more improvement by packing the Char array owned by a String into the String and arranging it so that the two shared a single header. (BTW, with regard to alignment, note that most processors can handle, eg, unaligned ints and longs, but often the storage accesses are several times longer if unaligned, so alignment may be very important, even if "unnecessary".) On Aug 19, 12:54 pm, Amit <[email protected]> wrote: > Hi Dan, > > Thanks for the response > > > In general, JITed Java code is as fast as or faster than the > > equivalent native code, if the JIT is reasonably good, and if the > > specific application can be coded efficiently in Java. > > I was actually banking on this. I don't know too much of the hairy > details (am not really a compiler person), but from what I have read > recent improvements by Google to the Dalvik VM make it *comparable* if > not equal in performance to native code ... > > Hate to sound like I'm harping on the same stuff, but then (assuming > that the JVM/JIT compiler is doing good enough), the memory bottleneck > still remains. > > Thanks, > Amit > > On Aug 19, 10:11 pm, DanH <[email protected]> wrote: > > > In general, JITed Java code is as fast as or faster than the > > equivalent native code, if the JIT is reasonably good, and if the > > specific application can be coded efficiently in Java. The problem is > > that some specific data processing patterns are not easy to code > > efficiently in Java, and I suspect that certain of the bit-bashing > > algorithms used in image processing fall into this category. > > > In such cases the most efficient approach is "native Java", but I only > > know of one JVM (the IBM iSeries "classic" JVM) that permits this, and > > then only for system code. Otherwise it's a bit of a tradeoff to get > > the right partitioning between Java and native, since crossing the > > Java/native boundary tends to be relatively expensive. > > > On Aug 19, 7:03 am, Fabrizio Giudici <[email protected]> > > wrote: > > > > -----BEGIN PGP SIGNED MESSAGE----- > > > Hash: SHA1 > > > > On 8/19/10 13:35 , Amit wrote: > > > > > Now, I know that native code will *not* yield any significant > > > > performance improvement over Java code > > > > Well, specifically for image processing this won't be true, for sure > > > up to 2.1 included (as the bytecode is purely interpreted); in 2.2 we > > > have JIT, but can't speak as I haven't seen it yet. > > > > - -- > > > Fabrizio Giudici - Java Architect, Project Manager > > > Tidalwave s.a.s. - "We make Java work. Everywhere." > > > java.net/blog/fabriziogiudici -www.tidalwave.it/people > > > [email protected] > > > -----BEGIN PGP SIGNATURE----- > > > Version: GnuPG/MacGPG2 v2.0.14 (Darwin) > > > Comment: Using GnuPG with Mozilla -http://enigmail.mozdev.org/ > > > > iEYEARECAAYFAkxtHakACgkQeDweFqgUGxe83wCfSDP1NEN+TLD0iOCZ/zSvQDRw > > > I5cAoJOEoC7eREU5KuPU7m93/GDj9VUr > > > =2ZDf > > > -----END PGP SIGNATURE----- -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
