I just found this thread after implementing 16.16 fixed point for some
small physics code. Conclusion: It won't be efficient enough from
Java, so stick with floating point.
I wanted to confirm the same results as stated previously on this
thread. I spent a while optimizing my 16.16 implementation, and
cutting corners where I could. In the end I think it's pretty close
to as fast as it can ever be from dalvik. That is unfortunately still
slower than soft-FPU. If you do mostly add and subtract, than fixed
point could be a win (since these are just equivalent integer add and
subtracts). Once you need to multiply and divide, that overhead won't
be worth it.
I wondered why, so I dug a bit deeper, and here is my rough idea.
Dalvik is an interpreted VM, so the more operations, the more
bytecodes, the more dispatch overhead, etc. But I think that is only
part of the cost. Generally when you implement 16.16 fixed point
multiplication you do a 32-bit by 32-bit -> 64 bit multiplication.
This is supported by the ARM instruction set as SMULL, for example.
However, if you look through the Dalvik source, there is no SMULL
instruction used. Looking at how you would write it in java:
int mul(int a, int b) {
return (int)(((long)a * (long)b) >> 16);
}
Here, what we really want is a 32-bit x 32-bit -> 64 bit. However,
this isn't possible from Java, we are instead doing two 32-bit to 64-
bit extensions, and then a 64-bit x 64-bit -> 64-bit. That means
instead of doing a SMULL, we'll hit this code:
http://google.com/codesearch/p?hl=en#atE6BTe41-M/vm/mterp/armv5te/OP_MUL_LONG.S
We are also going to hit a more complicated long shift right, which
could be implemented much more efficiently in ARM assembly:
http://google.com/codesearch/p?hl=en#atE6BTe41-M/vm/mterp/armv5te/OP_SHR_LONG.S
Basically we're working at too high of a level to efficiently
implement 16.16 fixed point. It is faster to execute a single Dalvik
bytecode (like OP_MUL_FLOAT), than to execute the 5+ it takes for the
fixed point (OP_INT_TO_LONG, OP_INT_TO_LONG, OP_MUL_LONG, OP_SHR_LONG,
OP_LONG_TO_INT).
Please forgive my bad gnuplot skills, but the follow is a graph with
some measurements. Frame number runs along X, and Y is the number of
milliseconds to compute a frame. Red is floating point, and blue is
16.16 fixed point. You can see they are pretty close, but soft-FPU
still wins. Having to complicate the code by inline fixed point
arithmetic everywhere for a performance loss obviously isn't worth
while. (Ignore the the spikes, those are GC caused by the performance
logging code.)
http://bayimg.com/image/caagiaacc.jpg
On May 19, 6:36 pm, Dianne Hackborn <[email protected]> wrote:
> If you have performance critical code like this, you may want to consider
> using the NDK as discussed in android-ndk.
>
>
>
> On Tue, May 19, 2009 at 8:44 AM, jeanguy <[email protected]> wrote:
>
> > Since you're targeting the G1, I will dispute this. In my tests fixed
> > point was negligibly faster than softfp. This is because there is no
> > JIT nor JNI support, and hence no support for hardware int math.
> > Softint is not all that faster than softfp. See the last post in this
> > thread:
>
> >http://groups.google.com/group/android-developers/browse_thread/threa...
>
> > After doing the necessary extra calculations to perform fixed point
> > math (all the bit shifts, etc.) I found not much of an advantage of
> > fixed point over softfp.
>
> > Not good news, I realize, but hopefully I can save you some time.
>
> > On May 18, 10:18 pm, Dianne Hackborn <[email protected]> wrote:
> > > Yes fixed point is highly recommended.
>
> > > On Mon, May 18, 2009 at 9:26 PM, Robert Green <[email protected]>
> > wrote:
>
> > > > I guess I'm thinking about all of the floating point vector and matrix
> > > > math I had dealt with in the last FPS game I worked on. It did seem
> > > > like the game itself, for the physics, collision detection, fx and
> > > > scene rendering used almost all floats (Torque game engine in 2005).
> > > > I suppose it would be possible to do that all with fixed point, which
> > > > is what I'm planning on doing for my upcoming 3D Android game.
>
> > > > Is that what you recommend doing?
>
> > > > On May 18, 6:32 pm, Dianne Hackborn <[email protected]> wrote:
> > > > > On Mon, May 18, 2009 at 3:18 PM, Robert Green <[email protected]>
> > > > wrote:
> > > > > > Understood. I was more speaking to the G1 specifically, not
> > Android.
> > > > > > The 8 megatexel GPU with no floating point on the CPU to be able to
> > > > > > support it confuses me.
>
> > > > > You don't need floating point to make good use of the GPU.
>
> > > > > --
> > > > > Dianne Hackborn
> > > > > Android framework engineer
> > > > > [email protected]
>
> > > > > Note: please don't send private questions to me, as I don't have time
> > to
> > > > > provide private support, and so won't reply to such e-mails. All
> > such
> > > > > questions should be posted on public forums, where I and others can
> > see
> > > > and
> > > > > answer them.
>
> > > --
> > > Dianne Hackborn
> > > Android framework engineer
> > > [email protected]
>
> > > Note: please don't send private questions to me, as I don't have time to
> > > provide private support, and so won't reply to such e-mails. All such
> > > questions should be posted on public forums, where I and others can see
> > and
> > > answer them.
>
> --
> Dianne Hackborn
> Android framework engineer
> [email protected]
>
> Note: please don't send private questions to me, as I don't have time to
> provide private support, and so won't reply to such e-mails. All such
> questions should be posted on public forums, where I and others can see and
> answer them.
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
