Fine! As a comparatively easy to design-and-implement yet very powerful solution to boost the computational performance of Android, you might consider adding a basic vector function API. Think java.lang.System.arraycopy() and java.util.Arrays.fill(), but then much enriched to cover most computational needs in media and signal processing. For instance, array_add(a, b) would add arrays a and b through native code, potentially further exploiting SIMD based hardware acceleration if/once available, making it all nicely future- proof. If the arrays are long enough, say > 100, the overhead of the Android vector function calls over the native code execution times becomes negligible. This approach easily extends to logical operators, say array_xor(a, b), left/right shift operators (needed for convolution type of processing and typical pixel-level image filtering operations involving nearest neighbors within a couple of image lines), multiplication by and addition of scalars, and so on. Importantly, it also to a large extent covers (replaces) the need for costly looping over conditional branches at Android level through the use of mask vectors, as you can find explained in section 2.5 of the online tutorial
http://www.kernel.org/pub/linux/kernel/people/geoff/cell/ps3-linux-docs/ps3-linux-docs-08.06.09/CellProgrammingTutorial/BasicsOfSIMDProgramming.html An image processing example of how to use vector operators to implement Prewitt or Sobel edge enhancement can be found in Table 1 (p. 30) of http://wsnl.stanford.edu/papers/icdsc07_mapp.pdf Having support for a basic set of vector operators may replace a (likely more restrictive) image processing kernel, as well as avoid the alternative of developing a dedicated compiler for a Java language subset (a balancing act with a possible future generic JIT compiler). A first generation implementation - for an early performance boost to Android - can simply be realized by implementing the array operators as for-loops in C code, generating native code from that and linking the object code through JNI (all under the hood, such that the Android application developer never sees any JNI stuff!). For computational work in media and signal processing this will likely give an order of magnitude speed improvement over the Dalvik interpreter, and/or improve battery life because far fewer CPU cycles are spent on a given task. The memory footprint will remain small too because it involves only a small amount of code underneath the API. Later speed optimizations may use platform dependent hand-coded assembly and hardware acceleration. Any future JIT compiler support in Android would be complementary, by improving efficiency in higher level processing. The vector operators would not become obsolete because a JIT compiler would in all likelihood never reach the efficiency for low level processing obtainable through hand-crafted or even hardware accelerated implementations of the small set of vector operators under the proposed media and signal processing API. Of course it remains the responsibility of the Android application programmer to make good use of the vector operators to replace the most costly Android for-loops and conditional branches. Regards On Feb 12, 5:29 am, Dave Sparks <[email protected]> wrote: > I think we'll be able to give you something that will meet your needs. > It's always a balancing act between taking the time to get the API > just right and getting a product to market. > > Keep making suggestions, we are listening. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
