[Insight-developers] numerics code optimization issue
Miller, James V (Research)
millerjv at crd.ge.com
Fri Aug 12 08:19:23 EDT 2005
Simon,
Problems in netlib with respect to optimization has been a long standing
issue. I tracked down one of these issues a while back and turned
off optimization for the Microsoft compiler in slamch.c with a pragma
#if defined(_MSC_VER)
# pragma optimize("", off)
#endif
I did not do this is dlamch.c (probably an oversight on my part on what the
the netlib naming conventions are). This probably points to a bigger issue of a
lack of tests.
Which intel compiler were you using? Linux of Windows?
I think CMake may have the capability to specify compile flags on a per
file basis. I think the vxl guys wanted such a capability. I would lean to
putting in pragmas to turn off optimization for the offending compilers in
those files if possible.
To do it in CMake, it looks like we would need to do something like:
IF(CMAKE_COMPILER_IS_GNUCC)
SET_SOURCE_FILES_PROPERTIES(gpfa5f.c PROPERTIES COMPILE_FLAGS -O0)
SET_SOURCE_FILES_PROPERTIES(dgpfa5f.c PROPERTIES COMPILE_FLAGS -O0)
SET_SOURCE_FILES_PROPERTIES(zlarfx.c PROPERTIES COMPILE_FLAGS -Os)
SET(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -w")
ENDIF(CMAKE_COMPILER_IS_GNUCC)
So we'd need to switch on each compiler and specify the COMPILE_FLAGS for each
suspect file. Not sure this is any easier than using pragmas. But it may be
necessary if we cannot turn off optimization from within the source file.
Are slamch.c and dlamch.c the only ones that need to be compiled non-optimized?
Or does slarfg.c also need it?
Jim
-----Original Message-----
From: insight-developers-bounces+millerjv=crd.ge.com at itk.org
[mailto:insight-developers-bounces+millerjv=crd.ge.com at itk.org]On Behalf
Of Simon Warfield
Sent: Thursday, August 11, 2005 11:28 PM
To: Insight-developers (E-mail)
Subject: [Insight-developers] numerics code optimization issue
It turns out that some of the calculations of numerical limits such as
machine precision in
Insight/Utilities/vxl/v3p/netlib/slamch.c and dlamch.c
are susceptible to failing when compiled with optimization on, as
would occur if you compile all of ITK in 'Release' mode.
The symptom I observed when I did this was test_qsvd entering an
infinite loop due to the calculation in
Insight/Utilities/vxl/v3p/netlib/slarfg.c around line 86-106 going bad.
The do { } while loop was not exiting due to the numerical issues.
I observed this issue when using the intel compiler, but other compilers
could also trigger it.
This issue is apparently well known as a google search turns up several
references e.g. http://web.mit.edu/lapack/www/faq.html 1.14 says:
> *NOTE:* Be careful. Many PC compilers often perform optimization by
> default at compile time! Thus, for routines such as
> LAPACK/SRC/slamch.f and LAPACK/SRC/dlamch.f, you will need to
> explicitly set a compile flag to turn OFF optimization.
I was wondering if it would be possible to have some kind of cmake rule
that would ensure that those special files are compiled not with the
flags for release mode but with regular flags.
Otherwise people would need to recognize the issue, go in and compile
those files specially without optimization, or else turn off high end
optimization for the rest of ITK.
--
Simon
_______________________________________________
Insight-developers mailing list
Insight-developers at itk.org
http://www.itk.org/mailman/listinfo/insight-developers
More information about the Insight-developers
mailing list