| Trolltech Home | Qt-interest Home | Recent Threads | All Threads | Author | Date | |
| All threads index page 4 | |
Greetings, I am working on a QT app that performs multiplications/divisions on 2D arrays of floating point numbers. Sometimes I noticed a severe slowdown during the mult/div. I suspect that the mult/div operations (depending on the data) generate NAN's that have to be handled by some procedure internal call (hence the slowdown). My question, if there some compiler option to disable this 'handling' and simply return bogus values? Thanks, Thomas Wharton Software Engineer Raytheon Co.
On April 14, 2004 12:39 pm, Thomas Wharton wrote: > Greetings, > > I am working on a QT app that performs multiplications/divisions on 2D > arrays of floating point numbers. Sometimes I noticed a severe slowdown > during the mult/div. I suspect that the mult/div operations (depending on > the data) generate NAN's that have to be handled by some procedure internal > call (hence the slowdown). My question, if there some compiler option to > disable this 'handling' and simply return bogus values? Are you using QVariant variables or directly using floats? If the former, switch to the latter for a big change. Next, have you tried switching from floats to doubles or to long doubles? Many processors are actually fastest with 80-bit floating points due to math coprocessors now built on to the CPU. Some compilers give you 128 bit long doubles and you have to force them to generate 80-bit instead. If you are using gcc, try the following compiler flags: -ffast-math (this can help quite a lot) -mfpmath=sse (use the SSE instructions for floating point, if you have them) -mmmx - enable mmx -msse - enable sse if you have it -msse2 - enable sse2 if you have that -mcpu=pentium4 -march=pentium4 (or as appropriate) For floating-point heavy apps, it is well worth playing around with these settings. Other compilers (e.g. Visual C++) have similar settings. Note that some of these trade off accuracy vs. speed. -- [ signature omitted ]
Hello, Thanks to all for their input. I will have to look over those compiler options. And I am sorry for not being more specific about what I system/compiler I am using: Red Hat 9.0 Linux on Compaq Evo W8000 gcc 3.2.2 Oh, and right now I am using 'float'. I may consider upgrading to 'double' if I can still meet the project constraints (the 2D arrays the project uses are passed across network and inter-process, so the goal was to keep them small!) Thanks Again, Thom Wharton -----Original Message----- From: owner-qt-interest@trolltech.com [mailto:owner-qt-interest@trolltech.com]On Behalf Of Chris Thompson Sent: Wednesday, April 14, 2004 3:03 PM To: qt-interest@trolltech.com Subject: Re: OT: Floating point problems... On April 14, 2004 12:39 pm, Thomas Wharton wrote: > Greetings, > > I am working on a QT app that performs multiplications/divisions on 2D > arrays of floating point numbers. Sometimes I noticed a severe slowdown > during the mult/div. I suspect that the mult/div operations (depending on > the data) generate NAN's that have to be handled by some procedure internal > call (hence the slowdown). My question, if there some compiler option to > disable this 'handling' and simply return bogus values? Are you using QVariant variables or directly using floats? If the former, switch to the latter for a big change. Next, have you tried switching from floats to doubles or to long doubles? Many processors are actually fastest with 80-bit floating points due to math coprocessors now built on to the CPU. Some compilers give you 128 bit long doubles and you have to force them to generate 80-bit instead. If you are using gcc, try the following compiler flags: -ffast-math (this can help quite a lot) -mfpmath=sse (use the SSE instructions for floating point, if you have them) -mmmx - enable mmx -msse - enable sse if you have it -msse2 - enable sse2 if you have that -mcpu=pentium4 -march=pentium4 (or as appropriate) For floating-point heavy apps, it is well worth playing around with these settings. Other compilers (e.g. Visual C++) have similar settings. Note that some of these trade off accuracy vs. speed. -- [ signature omitted ]
Hi, I noticed your questions re FP issues. We (the Scribus team) found a large speed improvement by using doubles instead of floats. We recently came across issues with gcc compilation in one area though where the precision was causing errors and the only way was to use -Os, or -O0 instead of -O2 or -O3. The FP compilation options may not necessarily be portable across platforms and some cause out of register storage. In one issue recently we had to work around an error caused by too high precision that gcc was causing. Compiling the same code on MSVC on Windows didnt get the problem. (GCC people on IRC said either use the switches (which uses out of register math) or work around it) Craig On Thu, 2004-04-15 at 13:07, Thomas Wharton wrote: > Hello, > > Thanks to all for their input. I will have to look over those compiler > options. And I am sorry for not being more specific about what I > system/compiler I am using: > > Red Hat 9.0 Linux on Compaq Evo W8000 > gcc 3.2.2 > > Oh, and right now I am using 'float'. I may consider upgrading to 'double' > if I can still meet the project constraints (the 2D arrays the project uses > are passed across network and inter-process, so the goal was to keep them > small!) > > Thanks Again, > Thom Wharton > > > -----Original Message----- > From: owner-qt-interest@trolltech.com > [mailto:owner-qt-interest@trolltech.com]On Behalf Of Chris Thompson > Sent: Wednesday, April 14, 2004 3:03 PM > To: qt-interest@trolltech.com > Subject: Re: OT: Floating point problems... > > > On April 14, 2004 12:39 pm, Thomas Wharton wrote: > > Greetings, > > > > I am working on a QT app that performs multiplications/divisions on 2D > > arrays of floating point numbers. Sometimes I noticed a severe slowdown > > during the mult/div. I suspect that the mult/div operations (depending on > > the data) generate NAN's that have to be handled by some procedure > internal > > call (hence the slowdown). My question, if there some compiler option to > > disable this 'handling' and simply return bogus values? > > Are you using QVariant variables or directly using floats? If the former, > switch to the latter for a big change. Next, have you tried switching from > floats to doubles or to long doubles? Many processors are actually fastest > with 80-bit floating points due to math coprocessors now built on to the > CPU. > Some compilers give you 128 bit long doubles and you have to force them to > generate 80-bit instead. > > If you are using gcc, try the following compiler flags: > -ffast-math (this can help quite a lot) > -mfpmath=sse (use the SSE instructions for floating point, if you have them) > -mmmx - enable mmx > -msse - enable sse if you have it > -msse2 - enable sse2 if you have that > -mcpu=pentium4 -march=pentium4 (or as appropriate) > > For floating-point heavy apps, it is well worth playing around with these > settings. Other compilers (e.g. Visual C++) have similar settings. Note > that some of these trade off accuracy vs. speed. > > -- > chris@centralsewing.com, chris@hypocrite.org > > -- > List archive and information: http://lists.trolltech.com/qt-interest/ > > -- > List archive and information: http://lists.trolltech.com/qt-interest/ >
Attachment:
signature.asc
Description: This is a digitally signed message part
What compiler? Also, you might want to post to comp.lang.c++ or the compiler specific group. My guess is that there is not an option because NaN are part of the (POSIX or C?) standard. - Phil Greetings, I am working on a QT app that performs multiplications/divisions on 2D arrays of floating point numbers. Sometimes I noticed a severe slowdown during the mult/div. I suspect that the mult/div operations (depending on the data) generate NAN's that have to be handled by some procedure internal call (hence the slowdown). My question, if there some compiler option to disable this 'handling' and simply return bogus values? Thanks, Thomas Wharton Software Engineer Raytheon Co. -- [ signature omitted ]
On Wed, 14 Apr 2004, Philip Dicke wrote: > What compiler? Also, you might want to post to comp.lang.c++ or the > compiler specific group. My guess is that there is not an option because > NaN are part of the (POSIX or C?) standard. Depending on the platform you may still deactivate some of those features, though. See e.g. gcc's -mno-ieee-fp and the -mfp-* switches for the Alpha. Harri.