Floating Point Behavior

The EnableFloatingPointExceptions service was removed from CMSSW in 2017. Here are the comments from that pull request:

"This was discussed and decided at the Core meeting on 30 May 2017. We do not want to use resources maintaining this service for several reasons. First of all, as far as we know no one uses or has used this service and it has been around for more than 10 years. Its unit test is broken. It does not work properly in the new multithreaded environment and would be difficult to fix, the precision control parts of it are obsolete with modern processors, and it does not work properly with some architectures."

The documentation below is no obsolete, possibly of historical interest so I didn't delete it.

Complete: 3

Goal of this page

The service named EnableFloatingPointExceptions allows one to control the behavior of floating point (FP) calculations in two ways. This page describes the two methods and also explains how to control the floating point behaviour in CMSSW.

Note: Starting with release 1_3_0_pre1, this service is automatically included in all cmsRun jobs as a default service.

Floating Point Exceptions

Currently, the default is that floating point exceptions are not enabled, which means that they will not be trapped and not cause crashes. This is also what will occur in jobs that run without the service (prior to release 1_3_0_pre1 or non-cmsRun jobs).

As of CMSSW 1_5_0, the user can set the floating point exception control word bits on a per-module basis thereby enabling floating point exceptions in particular code modules.

That is accomplished through the configuration file as in the following example:

      service = EnableFloatingPointExceptions 
          untracked bool reportSettings = false

          untracked vstring moduleNames = {  "default" 
                                            ,"sendMessages2"  }

          untracked PSet default = {
                            untracked bool enableDivByZeroEx = false
                            untracked bool enableInvalidEx = false
                            untracked bool enableOverFlowEx = false
                            untracked bool enableUnderFlowEx = false

         untracked PSet sendMessages1 = {
                           untracked bool enableDivByZeroEx = true
                           untracked bool enableInvalidEx = false
                           untracked bool enableOverFlowEx = false
                           untracked bool enableUnderFlowEx = false

        untracked PSet sendMessages2 = {
                           untracked bool enableDivByZeroEx = false
                           untracked bool enableInvalidEx = true
                           untracked bool enableOverFlowEx = false
                           untracked bool enableUnderFlowEx = false

  path p = { sendMessages1, sendMessages2, sendMessages3  }

  module sendMessages1 = makeSignals1 { }
  module sendMessages2 = makeSignals2 { }
  module sendMessages3 = makeSignals3 { }

This example supposed that events are processed by being passed through the three modules named sendMessages1, sendMessages2 and sendMessages3. We want DivideByZero exceptions enabled for the module labelled sendMessages1, Invalid exceptions enabled for the module labelled sendMessages2 and all floating point exceptions disabled outside of these two modules. To do that, we need to provide a list of module labels in the field moduleNames together with a "catch-all" label default which acts as a proxy for all other modules. For each item in the moduleNames list, an associated PSet then specified the state of the exception word to use for that module.

The long term goal is to use the values of the parameters shown above in the associated module. This will result in an DivideByZero exception being trapped and a crash when an Inf occurs in a floating point calculation in the module labelled sendMessages1 and an Invalid exception being trapped and a crash whenever a NaN is generated in a module labelled sendMessages2. Note that a module labelled sendMessages3 is included in the processing path but that it is not in the moduleNames list. For that module, the PSet for the default module is used.

By contrast, the job-wide parameter 'reportSettings' causes the code to report whenever any of the potential exceptions changes state from enabled to disabled or vice versa. Those reports are all issued via the MessageLogger LogVerbatim call and the user is responsible for configuring the MessageLogger appropriately. Use this option with care as it can easily bury you in messages.

Enabling exceptions is very useful if one is trying to track down where a floating point value of NaN or Inf is being generated and is even better if the goal is to eliminate them. We hope to enable these exceptions some day in the future after CMS code has been improved to the point that these exceptions occur very rarely. Currently, they occur disturbingly often.

Precision Control

One can also control the precision of floating point operations in x87 FP processors.

      service = EnableFloatingPointExceptions 
          untracked bool setPrecisionDouble = true

If set true (the default if the service is used), the floating point precision in the x87 math processor will be set to round results of addition, subtraction, multiplication, division, and square root to 64 bits after each operation instead of the x87 default, which is 80 bits for values in registers (this is the default you get if this service is not used at all and also the only possible behavior prior to 1_3_0_pre1).

The precision control only affects Intel and AMD 32 bit CPUs under LINUX. This has not been tested on 64 bit Intel and AMD CPUs. This is something that will need to be studied in the future. For other operating systems and CPUs, compiler flags are set so that the service will compile, link and run, but does nothing. One gets the default behavior of the CPU and operating system. In many cases when not using a 32 bit Intel or AMD CPU, one gets 64 bit precision and there is no way to modify the behavior of the floating point processor to get anything different.

Review Status

Reviewer/Editor and Date (copy from screen) Comments
Main.wdd - 18 Dec 2006 page created
JennyWilliams - 31 Jan 2007 editing to include in SWGuide
Main.Marraffino - 30 May 2007 updated for per-module usage
ChrisDJones - 2016-07-29 force myself to be last reviewer for accounting purposes

Responsible: Main.wdd
Last reviewed by: Reviewer

Edit | Attach | Watch | Print version | History: r9 < r8 < r7 < r6 < r5 | Backlinks | Raw View | WYSIWYG | More topic actions
Topic revision: r9 - 2019-10-11 - DavidDagenhart

    • Cern Search Icon Cern Search
    • TWiki Search Icon TWiki Search
    • Google Search Icon Google Search

    CMSPublic All webs login

This site is powered by the TWiki collaboration platform Powered by PerlCopyright & 2008-2019 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback