[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