Hi, Thanks for your reply
> 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? About GC locking up the thread or pre-empting the CPU, no I haven't solved that, nor had I thought about it. I am kind of new to developing for Android, and may be my expertise on the platform can be considered "Average". And I haven't developed or deployed image processing algorithms on Android either (though I have done that a bit on other embedded platforms), so I do not know the specifics involved. I am mapping what I know from optimizing algorithms for DSPs and what I get from profile data and trying to come up with solutions. Could you provide me with some resources (docs) for what you mention? (I will of course try googling for it ;-) ) It would be interesting to know that, as I am really trying to learn more about Android platform also (apart from imaging stuff). Finally, I'll take a look at the jsr-239 java.nio; I haven't used it or seen samples of it earlier, so totally new to me. Thanks again for your pointers. Amit On Aug 20, 3:25 am, Indicator Veritatis <[email protected]> wrote: > 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 onAndroid) 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 forAndroid'sjava.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 signalprocessingalgorithms > > 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 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
