Badlogic Games

A lot of myths surround the argument about fixed versus floating point arithmetic on Android devices. All currently available Android phones are missing an FPU so floating point arithmetic must be emulated in software and is therefor expected to be quiet slow compared to fixed point arithmetic which is solely based on integers.

Another choice one has to make when writting a game for Android is wheter to go Java or C for the performance intensive parts of the game (or even for the whole game). Legend has it that C will be up to 10 times faster than an equivalent Java implementation.

To finally get some insight on this two topics i wrote a micro benchmark. In my previous post on MD2 model rendering i talked about interpolating between two keyframes a little. Back then i used floats and Java for the interpolation code. For this benchmark i rewrote the interpolation code to use fixed point and also ported the fixed point and floating point code over to C. The Java interpolation routines use float arrays, the C equivalents use direct buffers for obvious reasons. Here’s the code for the Java methods:

public void interpolate( float[] src, float[] dst, float[] out, float alpha )
{
   for( int i = 0; i < src.length; i++ )
   {
      float s = src[i];
      out[i] = s + (dst[i] - s) * alpha;
   }
}
 
public void interpolateFP( int[] src, int[] dst, int[] out, int alpha )
{
   for( int i = 0; i < src.length; i++ )
   {
      int s = src[i];
      out[i] = s + ((dst[i] - s) * alpha) >> 16;
   }
}

The c equivalents look like this:

JNIEXPORT void JNICALL Java_com_badlogic_nativebenchmarks_Native_interpolate(JNIEnv *env, jobject obj, jobject sourceBuffer, jobject destBuffer, jobject targetBuffer, jfloat alpha, jint count )
{
   jfloat* src = (jfloat*)env->GetDirectBufferAddress(sourceBuffer);
   jfloat* dst = (jfloat*)env->GetDirectBufferAddress(destBuffer);
   jfloat* tgt = (jfloat*)env->GetDirectBufferAddress(targetBuffer);
 
   for( int i = 0; i < count; i++ )
      tgt[i] = src[i] + (dst[i] - src[i]) * alpha;
}
 
JNIEXPORT void JNICALL Java_com_badlogic_nativebenchmarks_Native_interpolateFixedPoint(JNIEnv *env, jobject obj, jobject sourceBuffer, jobject destBuffer, jobject targetBuffer, jint alpha, jint count)
{
   jint* src = (jint*)env->GetDirectBufferAddress(sourceBuffer);
   jint* dst = (jint*)env->GetDirectBufferAddress(destBuffer);
   jint* tgt = (jint*)env->GetDirectBufferAddress(targetBuffer);
 
   for( int i = 0; i < count; i++ )
      tgt[i] = src[i] + ((dst[i] - src[i]) * alpha) >> 16;
}

I benchmark each of the 4 methods serperately, calling them 100000 times on the same input. Each method call processes an array/buffer with 700 floats/ints. And here are the interesting results:

Java Float: 31.28 seconds
C Float: 8.78 seconds
Java Fixed Point: 18.93 seconds
C Fixed Point: 2.23 seconds

All measurements are averaged over 10 runs.

Interestingly enough, the C float method is only approx. 3 times faster than the equivalent Java version. The Java fixed point version is only 1/3 faster than the Java float version indicating that it’s probably not worth using fixed point in a pure Java implementation. The c fixed point method outperforms all other methods by a comfortable margin. It’s 10 times faster than the equivalent Java version and 15 times faster than the Java float version. It’s also 4 times faster than the C float version indicating that the software float emulation is quiet a bit slower.

The interesting question is why the Java fixed point version is not that much faster than its Java float pendant. I suspect that the shift is not optimal.

To summarize: use C with fixed point arithmetic for maximum performance. If you want to stay with Java use floats over fixed point for maintainability.

Get the full source here. To recompile the C code you have to add an app to your ndk.