fast math?

Martin Wuerthner martin at mw-software.com
Tue Feb 4 06:28:54 PST 2003


In message <001e01c2cb82$44130780$0a00a8c0 at luigi>
          "Luigi Dalmazio" <daldel at libero.it> wrote:

> I am developing several programs (in C++ with GCC under Linux, Athlon
> processor) that make intense usage of sqrt(), sin(), atan() and other
> math functions. Under Linux there is a compiler flag (fast_math) which
> works greatly and (apparently) without loss of precision makes double
> precision math functions much faster then fixed point, low precision
> functions

The Athlon has a very fast double precision hardware floating point unit.
Of course, it will beat any low precision fixed point routines hands down,
no matter which compiler flag you specify.

This is not a gcc thing, it is a hardware thing.

> (Yes I know Artworks is fast, but it uses -I think- low precision 24.8
> fixed point math and graphic functions -- 

Not quite correct. ArtWorks uses 2.30, 16.16 and various types of 64 bit
maths, depending on context. I do not think 24.8 maths are used anywhere.

Perhaps you mix this up with the way Draw (and ArtWorks) coordinates are
defined: 256 Draw units are 1 OS unit, so Draw coordinates are a 24.8
representation of OS units. However, an OS unit is an arbitrarily chosen
unit anyway, so it does not mean anything to the maths being performed
inside the application.

> it cannot zoom more than 4000% because drawing would start to show
> inaccuracies and approximations).

The reason why ArtWorks can only zoom to 4000% is not in any way connected
with maths accuracy. It is simply a result of the coordinate range. In
fact, ArtWorks fails earlier than 4000% if the page size is big enough.
However, this is due to overflows, not due to maths inaccuracies.

> With 32bit floating-points numbers and an internal accuracy of 72000 dpi
> you can zoom up to 60000% without any visible inaccuracy 

I think you are mistaken here. Yes, you get the accuracy you quote but
only for pixels around the origin. Without specifying the coordinate range
you want to support, a statement like the one you made above is pointless.
Compare the values for 2 metres and 2 metres plus 1/72000 inch to find out
what accuracy really is. Hint: If you work this out you will find that you
already need 32 bits of mantissa to achieve the above accuracy for a 2
metres coordinate range.

So, if you want to support the above accuracy, you will find that 32-bit
floating point numbers are not adequate if you want a decent coordinate
range. In general, for graphics applications that want to support a given
coordinate range at a given constant accuracy across the range, fixed
point numbers are the method of choice. The reason why FP is used for such
applications on other platforms is mainly because there is hardware
support for it.

Still, it would be useful to have a good floating point library that could
be linked into programs to avoid the overhead of FPEmulator. However, such
a library will not be able to beat fixed point maths tailor suited to a
particular application in terms of performance.

By the way, there is a replacement FPEmulator that runs quite a bit faster
than the standard RISC OS version and offers even better IEEE compliance
(it is called FastFPE). Still, it is orders of magnitude slower than any
old Pentium, not to mention recent Athlons.

Martin
-- 
---------------------------------------------------------------------
Martin Wuerthner          MW Software          martin at mw-software.com
---------------------------------------------------------------------



More information about the gcc mailing list