You are benchmarking some math functions. If you compile the C Code with the default setting from the NDK all floating point operations are emulated. The Java version executed on the Dalvik VM will hopefully use real floating point instructions - if the CPU supports it.
So, as all benchmarks this isolated one has very little value. Try some integer functions instead of doubles. The C version will be a lot faster than the Java version (I estimate 10 timers faster than Java) Enable hardware support for floats with a compiler switch. Again the C version will be much faster again. Try it with 32 Bit unsigned integers. The Java version will be a lot slower, because there are no unsigned integers in Java... Alloc (and free) lots of memory. The Java version will win (hopefully!). ... 2010/4/8 Menion <[email protected]> > I'm doing some little research school project, together with learning > basics of C++ (thanks to JNI) and here is some simple example ... > > Java function: > ------------------------------------------- > public double doClickAction04J() { > double x = 45.0 / (180.0 / Math.PI); > double result = 0.5; > for (int i = 0; i < 1000000; i++) { > result += Math.pow(Math.cos(x), 2.0); > result -= Math.pow(Math.sin(x), 2.0); > result = Math.log(result); > result = Math.exp(result); > } > return result; > } > > and C code > ------------------------------------ > JNIEXPORT jdouble JNICALL > Java_menion_android_jnitest_Main_doClickAction04C > (JNIEnv *env, jclass thiz) { > double x = 45.0 / (180.0 / M_PI); > double result = 0.5; > int i; > for (i = 0; i < 1000000; i++) { > result += pow(cos(x), 2.0); > result -= pow(sin(x), 2.0); > result = log(result); > result = exp(result); > } > return result; > } > > > and the results? > Java: 5250ms > C : 1600ms > > I then enabled experimental version of JIT compilator (in 2.1-r1 > system) and new results > Java: 4700ms > C : 1600ms > > so ... these are facts. I'm not really experienced with C, but this > seems for me as very objective test. > > > On Apr 7, 6:26 pm, Ralf Schneider <[email protected]> wrote: > > There exists 4444 (GL_UNSIGNED_SHORT_4_4_4_4) Textures. > > May be this helps a litle bit. > > > > I'm not sure but switching to VBOs might not bring an improvement. > > My observation on a Nexus One is: VBOs are great if there are many tris > > (>250) to render per call. For billboards it really doesn't matter that > > match. > > But I don't have any hard numbers this is just an observation on a > specific > > device. > > > > Many have observed most devices are currently fill-rate-limited. So, if > you > > have lots of overdraw it might be worth checking if you can reduce it. > > > > 2010/4/7 MrChaz <[email protected]> > > > > > 100 is a low estimate but it's around that point that the frame-rate > > > seems to get into the sub 30's. > > > I'm already doing pretty much everything you've mentioned except using > > > VBOs - most sprites are rendered via the draw_texture extension. > > > Unfortunately pretty much all the sprites have some transparency so > > > I'm using ARGB_8888 for the texture atlas's. > > > > > > -- > 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]<android-developers%[email protected]> > For more options, visit this group at > http://groups.google.com/group/android-developers?hl=en > > To unsubscribe, reply using "remove me" as the subject. > -- 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
