Hi Dan, Thanks for your reply
Yes, I looked at alignment as the first choice for optimization, but was unable to find any directives that would help you do that in C. (Specifically, for C and those that would compile on the Android NDK). What I have done, however, (as I mentioned earlier) is refactoring the code to take advantage of those optimizations (at a later stage) through the use of compiler directives ... Then I was searching for any docs related to them (compiler directives), but didn't find any. Haven't searched too extensively, but from a preliminary search, didn't see any. Or on a different track (one that I haven't explored till now; and neither used earlier, so excuse the ignorance), are there such directives in Java? If there are, then I would consider implementing the entire algorithm in Java (anyways the gains from using NDK are doubtful at best, and I'm only using that to reduce dev. effort). Thanks again, Amit On Aug 19, 11:47 pm, DanH <[email protected]> wrote: > "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 dataprocessingpatterns are not easy to code > > > efficiently in Java, and I suspect that certain of the bit-bashing > > > algorithms used inimageprocessingfall 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 forimageprocessingthis 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
