Hi Denis,
float operations are pretty fast and they are usually done in a separate
part of the processor so the compiler can schedule a lot of bookkeeping
instructions to run in parallel with waiting for the results of the FP
instruction. In the end, they often end up being "free" if there are
enough bookkeeping instructions (branches, fetching data, etc.) in
amongst the data.
Given how many alternate instructions you are pointing out for the fixed
point code it would be very likely that this would be a "win".
The main reason that Pisces is implemented heavily in fixed point is
that it was originally written for the mobile platform where there are
no FP instructions. We don't have to worry about that on the desktop
(any more).
I strongly support you converting things to fp if you want to do it...
...jim
On 7/12/2010 8:05 AM, Denis Lila wrote:
Hello.
Is it ok if I do this? I already started working on it on Friday.
I think I should be done by tomorrow.
But yes, I agree that we should convert to floating point. As for
performance, there's also the fact that right now we're trading
one double multiplication for 2 casts to long, 1 long multiplication,
1 bit shift of a long, and 1 cast back to an int. I don't know much
about how these are done in hardware, but it doesn't seem like they'd
be faster than the double multiplication.
As for large coordinates, there's a bug report about it (one not
reported by me :) ) here: https://bugzilla.redhat.com/show_bug.cgi?id=597227
I submitted a matching bug report on bugs.sun.com (ID 6967436), but I
can't find it when I search for it.
Denis.
----- "Jim Graham"<james.gra...@oracle.com> wrote:
Sigh...
Pisces could really stand to upgrade to floats/doubles everywhere, for
several reasons:
- FPU ops are likely as fast if not faster on modern hardware due to
parallel execution of FP instructions alongside regular instructions.
- Don't have to worry about getting coordinates larger than 32K (I
don't
think this is well tested, but I imagine that Pisces will not deal
with
it very gracefully).
- Lots of code is greatly simplified not having to deal with the
semantics of how to do fixed point multiplies, divides, and
conversions.
I meant to do this during the original integration, but I wanted to
get
the task done as quickly as possible so that we could have an open
source alternative to the closed Ductus code so I left that task for a
later update. But, now that a lot of work is being done on the code
to
fix it up, it might be better to do the float conversion now so that
the
maintenance is easier and before we end up creating a lot of new fixed
point code.
My plate is full right now, but hopefully I can interest someone else
in
doing a cleanup cycle? (Donning my Tom Sawyer hat... ;-)
...jim
