Hi, As per the last msg on this thread, I did check out about GC pre- empting the CPU/locking up the thread. As I said, I hadn't considered this possibility, and I wasn't aware of it either, to be honest.
I googled around to check out more on it, and came across another thread on the forums http://groups.google.com/group/android-ndk/browse_thread/thread/6bc6b9b0c3540c27 I believe the same thing is happening in my case: except that I am doing image/video processing as opposed to the audio processing that this thread above concerns. Will post back/share as I learn more.. Another related stuff is I was checking out some docs relating to writing efficient/optimized code for ARM11 architecture. For the record, the processor I am running my stuff on has the ARM1176JZF-S which has independent I/D caches of 16 KB each and two TCMs (Tightly Coupled Memories) also of 16KB each... I did some tests on a simple loop which I was using to define my image data (one naive code vs. "ARM code") but did not notice significant difference... What is more is that the profile time varies significantly. I checked the logs to see what the GC is upto and sure enough you see the GC thread doing its stuff... So I guess I am going to tackle this more basic issue first, and then think about optimizing the C code :) thanks, Amit On Aug 20, 2:35 pm, Amit <[email protected]> wrote: > 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
