Hmm, did you do that in release mode with optimizations turned on? That should be faster than a multiply as long as it only loads y from memory once. Memory transfers take a lot more time than actual computations, so that would explain why the multiply would be faster.

---

-Deku-chan

DK Art (my site, which has little programming-related stuff on it, but you should go anyway^_^)

Heya,

I learned from many tutorials that you can break a multiply
that cannot be shifted in one step into more shifts, like you showed us. This trick was told, because it should be faster than the origional multiply!! I think they won''t come up with that if it is actually slower, right?

Think DekuTree suggest the right problem of your test!

Gr,
BoRReL

Books on topics such as this are out-of-date before they finish printing them...

Maximum efficency on a P+ is an interleaved integer/floating/integer/floating combination, this keeps both the u & v pipes running (less stalls), or so I''ve been told. The integer units are still a little bit faster than the floating units, but to make the most of it everything has to be done in integer math then. As mentioned the conversions kill performance. And all the 3D API expect floats, so fixed math would only help on a custom 2D engine.