
Boost : 
Subject: Re: [boost] Fixed point integer proposal
From: Christian Schladetsch (christian.schladetsch_at_[hidden])
Date: 20090625 18:41:43
Hello,
In fact, fixed point is not faster on many architectures than floating
point. One assumes that it is mainly PSP, DS and Gamecube guys that want
fixedpoint just for speed these days (I'm looking at you, Kenny ;).
It was the case years ago that fixedpoint was faster than floatingpoint,
but it is less commonly true now than conversely. Modern systems typically
have at least one if not many dedicated FPU's which can work in parallel
with the main ALU(s).
Similarly, it is often faster to use floatingpoint trig than fixedpoint
trig. FPU trig is heavily optimised in microcode and, perhaps surprisingly,
it is often faster to do trig on an FPU than break the cache with the table
lookup that is often used in fixedpoint. And lastly, converting to and from
fixed and floatingpoint is generally very slow.
Of course, I am referring mainly to embedded hardware systems like game
consoles, but I think in general the idea that fixedpoint is faster is not
as true as it once was.
The reason for this preamble is to make the case that the main reason for
fixedpoint these days is accuracy and not speed. As has been noted in this
thread, fixed point is accurate and does not drift. This is not entirely
accurate (no pun intended), as there is drift in both fixed and
floatingpoint, but fixedpoint is generally more stable for things like
physics simulators.
Given that, I would vote for a fixedpoint system that favored accuracy and
resolution over speed. Indeed, there is a case to be made for a socalled
"floatingfixedpoint" system; I wrote one of these some time ago and it
helped a great deal with accuracy.
The basic idea is to use an N.M fixedpoint format for numbers, and the
result of operations changed to a minimal N2.M2 format in order to preserve
accuracy.
Has anyone put forward a generalised arithmetic system that used
arbitrarilysized "floatingfixedpoint" values to allow for an arbitrarily
large (or arbitrarily small) number system? This would seem to me to be of
more value than a "fixedfixedpoint" system designed primarily for speed,
which has a dubious premise and has all the associated issues of accuracy
and operation result types.
Regards,
Christian.
On Fri, Jun 26, 2009 at 4:38 AM, Soren Holstebroe <holstebroe_at_[hidden]>wrote:
> > > Some years ago I wrote a fixed point template for transparent fixed
> point
> > > integer arithmetics and conversion.
> >
> > To me, "fixed point" => !"integer".
>
> Obviously fixed point is not an integer in mathematical sense. What I
> meant was that a fixed point represented by an integer shares some of
> the same computational properties:
> Arithmetic is faster than floats on most architectures.
> Adding (and accumulating) fixed points or multiplying by an integer is
> exact.
> Conversion to integer is fast.
>
> > particular, saturating or otherwise detecting overflows seemed to be
> > required.
>
> Saturation and overflow detection can be specified as a policy.
> For me there are two important design criteria:
> 1st priority is that computational performance matches integer performance.
> 2nd priority is that it is possible to make a seamless float type and
> the fixed point type exchange.
>
> Adding saturation handling and overflow checks, that are not natively
> supported by the underlying integer is of lower priority for me.
> In my fixed point class I implemented overflow check as an optional
> policy. That way you can add all the overhead checks you want in your
> debug configuration and strip it in your release build.
> As of saturation (I assume it's computer graphics people that want
> that feature) it should be straight forward to implement that as a
> policy too in the same way as the overflow check.
> In my option I see little practical use of a saturation policy.
> Saturation code would kill performance and people would be better off
> using MMS registers for native saturation.
>
> > recall that someone was actually working on that. It was also
> > suggested that I ought to provide all of the features that <cmath>
> > provides for floating point.
>
> It makes sense to support rounding, abs and mod.
> I don't see a practical need to natively support trigonometry
> functions. A conversion to float and back has to be fine.
>
> Soren
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost
>
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk