This sounds all find and good, but I still haven't heard anything about the far more common cause of delay: the garbage collector locking up the thread or pre-empting the CPU. Or has Amit already solved this problem?
As for alignment, OpenGL as implemented by JSR-239 (therefore available on Android) solves this problem by using the JSR-239 java.nio Buffer classes. If you use one of these, you are guaranteed word-alignment on the ARM. NB: I say "jsr-239 java.nio" because there may be subtle implementation differences between those and the original java.nio classes. For example, JSR-239 does not expect flip() to be useful, nor is supporting Mark required. NB: the online docs for Android's java.nio do not mention alignment: I found this info in one of the OpenGL ES specs (I forget which one): I forget whether or not the Buffer must be allocated Direct or not to get this benefit. On Aug 19, 12:40 pm, Marc <[email protected]> wrote: > I have spent a lot of time optimizing signal processing algorithms > using both arm assembly and memory optimizations. The memory > optimizations can be huge. I remember one project the speed more than > doubled once we only using cache memory. That is the entire working > data set was less than 8k. > > The process is fairly straight forward: Determine the size of your > cache, then use only that much memory. This typically requires doing > tricks like making the output buffer overlap the input buffer. > Basically you need to know exactly where every byte of memory is being > used. Java tends to be allocate as you need memory model, but for > cache optimizations you need tighter control of memory usage. > > On Aug 19, 11:47 am, 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 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
