Performance comparison NDK vs SDK

by MrChaz » Tue, 06 Apr 2010 21:24:40 GMT


Sponsored Links
 Does anyone have any numbers showing the difference in performance
between the NDK and SDK?

I'm curious how much difference it makes in terms of fps / number or
polys on the screen that kind of thing

--



Performance comparison NDK vs SDK

by Disconnect » Tue, 06 Apr 2010 21:59:22 GMT


 NDK has no way to write to the screen, so it gets zero fps. ISTR the droid
(or is it nexus?) is limited to something like 25 fps because of the
hardware design. So the SDK is 25fps faster, or [image: \infty] percent. :)




>


Sponsored Links


Performance comparison NDK vs SDK

by Mark Murphy » Tue, 06 Apr 2010 22:08:21 GMT


 > NDK has no way to write to the screen, so it gets zero fps.

Actually, the NDK has access to OpenGL, though I don't know the details.

-- 
Mark Murphy (a Commons Guy)
 http://commonsware.com 
Android App Developer Books:  http://commonsware.com/books.html 


--



Performance comparison NDK vs SDK

by Disconnect » Tue, 06 Apr 2010 22:18:23 GMT


 Ah, yah so I see. Nice.




>



Performance comparison NDK vs SDK

by Ralf Schneider » Tue, 06 Apr 2010 22:37:50 GMT


 You will probably not get a clear anwser from anyone. The questions is far
more complex than it looks like.

It is no problem to put the same number of polys out in OpenGL be it with
the NDK or SDK. After all it's just same OpenGL calls. The time to render
the polys (in a batch) exeeds the time of the function call overhead by
orders of magnitude. So it is usually completely neglectable.

But as soon as an application gets more complex and performs some serious
calculations(AI, Scene Graph Management, Culling, Image processing, Number
crunching, etc.) the native version will usually be much faster.

And there is another thing: Beside the fundamental problem that there
currently is no JIT Compilation.
The current dalvikvm with its compiler seems to be very basic, without doing
any optimizations - even not the most basic ones!

There is this (very good) video: Google I/O 2009 - Writing Real-Time Games
for Android < http://www.youtube.com/watch?v=U4Bk5rmIpic> ;
After I have seen it, it was clear for me I will definitely use C++ with the
NDK.

For example: He is talking about the overhead of function calls "Don't use
function calls".
... So yeah we are back - before 1970 and start talking about the cost of
structured programming and the performance advantage of using only global
vars and gotos.

The garbage collection is a real problem for games. So you will spend a lot
of your time thinking how you can avoid it. Even formatting a string will
create new objects. So there are tips like: don't show the FPS!
Seriously, if you know C++ it is probably easier to manage you memory with
new and delete than to tweak your architecture to reduce/avoid garbage
collections.

It seems like if you want to program a non trivial real time game, you are
loosing all the advantages of Java. Don't use Getters and Setters, Don't use
function calls. Avoid any Abstraction, etc. SERIOUSLY?

But back to your question: The performance advantage of NDK vs SDK can be
anything from 0-10000%. It all depends.


2010/4/6 MrChaz <mrchazmob...@googlemail.com>

>



Performance comparison NDK vs SDK

by MrChaz » Wed, 07 Apr 2010 05:08:33 GMT


 I was hoping that someone had tried a little test app with a simple
scene.  I think I've pretty much reached the limits in terms of get
sprites on the screen at an acceptable frame rate (at least on G1 type
hardware).
It seems, at least for what I'm doing, the limit is about 100 sprites
but for my next project I'd like a bit more.
Maybe I'll just stop making games for 'old' hardware and concentrate
on the Droid and N1.  I can't say I like the idea of ignoring half the
market :(



> >



Performance comparison NDK vs SDK

by Ralf Schneider » Wed, 07 Apr 2010 05:29:08 GMT


 If your performance problem is only related to putting sprites on the
screen, don't expect an improvement by witching to the NDK.

I don't know how you are currently doint it, but these are some general
remarks:

Use OpenGL ES to draw the sprites.
Limit your textures to 256x256. 512x512 seems to be slower on some devices.
Use texture atlases for smaller sprites -> To avoid state changes in OpenGL
Use VBOs
Avoid textures with alpha channels on slower devices.
Don't scale or rotate your sprites on slower devices. Slower devices often
have a fast path for simple blitt operations. => Check if "point sprites"
are available on the device. If yes, use them.
Use 16 Bit (565) textures.
Watch the video I have posted in the previous post. The speaker has some
valuable tips for performance improvements.

Anyway, 100 Sprites is not very much if you are already using OpenGL...
So may be you are right and the only solution is to target high end devices
for your next project.






2010/4/6 MrChaz <mrchazmob...@googlemail.com>


--



Performance comparison NDK vs SDK

by MrChaz » Wed, 07 Apr 2010 23:52:32 GMT


 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.




--



Performance comparison NDK vs SDK

by Ralf Schneider » Thu, 08 Apr 2010 00:26:18 GMT


 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 <mrchazmob...@googlemail.com>


--



Performance comparison NDK vs SDK

by Menion » Thu, 08 Apr 2010 13:47:58 GMT


 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.





--



Performance comparison NDK vs SDK

by Ralf Schneider » Thu, 08 Apr 2010 15:16:56 GMT


 ou 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 <menion.as...@gmail.com>

>



Performance comparison NDK vs SDK

by lixin China » Wed, 14 Apr 2010 02:45:35 GMT


 Hi Schneider:
As you said avoid scale the texture. Could you tell me the solution
how to render background texture(480x320 to full screen) without
scale.




--



Performance comparison NDK vs SDK

by Ralf Schneider » Mon, 19 Apr 2010 04:37:36 GMT


 Pre-scale the background image to match the device resolution.
Split the background image in texture tiles like 256x256, 128x128, ....
Blitt the tiles separately.


2010/4/8 lixin China <smallli...@gmail.com>


>



Performance comparison NDK vs SDK

by Lance Nanek » Thu, 22 Apr 2010 00:26:03 GMT


 >most sprites are rendered via the draw_texture extension

For very large numbers of sprites I've found that the standard draw
arrays/elements methods are much faster than the draw_texture
extension in cases where you can arrange to draw multiple sprites per
draw call. That's impossible with the draw_texture extension.





--