Intel 5.0 compilation of Pooma benchmarks: spurious asserts in optimized builds

[Allan Stokes]

Hi everyone,

I re-installed my Cygwin environment with the DOS line discipline and now
I'm able to use the Visual Studio workspaces.  I'm compiling with the Intel
5.0 compiler, which I'm hoping is much improved over 4.5.  The space
efficiency of the compiler during optimized builds has indeed improved
substantially (down from 550MB VM peak to 350MB VM peak).

This test machine is a dual PIII 750.  Most of these benchmarks run on 60%
of one CPU, 40% of the other.  It must be the timing calls that allow the
process to wobble around.  Typically CPU bound threads will stick to a
single CPU.

Under the Release configuration I encountered three errors:

ABCTest      wrong correctness value PoomaII CompBrickUMP Implementation,
N=100
GKPoisson    assert failure in PoomaII MP Implementation, N=10
Krylov       assert failure in PoomaII MP Implementation, N=10

Some additional testing shows that all of these run correctly under the
Debug build.  The results in all cases are exactly the same on a second w2k
test machine (single processor Athlon).

Here are the details of the Release runs which failed:

<<<
d:\work\pooma\r2\ide\VisualC++\benchmarks\ABCTest\Release\ABCTest.exe
Benchmark
----------------------------------------------------------------------------
---
Running sample #1 for C Implementation:
  N = 100...
    Correctness test value for N = 100 is 1.00103.
Running sample #1 for CppTran Brick Implementation:
  N = 100...
    Correctness test value for N = 100 is 1.00103.
Running sample #1 for PoomaII Brick Implementation:
  N = 100...
    Correctness test value for N = 100 is 1.00103.
Running sample #1 for PoomaII CompBrick Implementation:
  N = 100...
    Correctness test value for N = 100 is 1.00103.
Running sample #1 for PoomaII BrickUMP Implementation:
  N = 100...
    Correctness test value for N = 100 is 1.00103.
Running sample #1 for PoomaII CompBrickUMP Implementation:
  N = 100...
    Correctness test value for N = 100 is 6.1409e-318.
                         CppTran       PoomaII       PoomaII       PoomaII
PoomaII
N             C           Brick         Brick       CompBrick      BrickUMP
CompBrickUMP
100        250.00         36.70         36.70        250.00          9.83
36.70
>>>


Running in pooma/r2/ide/VisualC++/benchmarks/GKPoisson/Release
<<<
Running sample #1 for PoomaII MP Implementation:
  N = 10...
### POOMA Assertion Failure ###
### contains(domain_m, v.first)
### File ..\..\..\..\SRC\Domain/DomainMap.h; Line 185.
Pooma::pAbort called.
In default abort handler.
>>>

This comes from within DomainMapNode<Dom,T>::insert(const Value_t &v)


Running in pooma/r2/ide/VisualC++/benchmarks/Solvers/Krylov/Release
<<<
Running sample #1 for PoomaII MP Implementation:
  N = 10...
### POOMA Assertion Failure ###
### node_m != 0
### File ..\..\..\..\..\SRC\Domain/DomainMap.h; Line 507.
Pooma::pAbort called.
In default abort handler.
>>>

This comes from within Value_t& DomainMapTouchIterator<Dom,T>::operator*()


It appears that the problems are due to compiler optimizations.  The ABCTest
could be an issue with numeric stability.      Changing the optimizations to
"custom" (+all -assume_no_aliasing -favor_small_code) lead to this failure:

<<<
.\ABCTest Benchmark
-------------------
Running sample #1 for C Implementation:
  N = 100...
    Correctness test value for N = 100 is 1.00103.
Running sample #1 for CppTran Brick Implementation:
  N = 100...
    Correctness test value for N = 100 is 1.00103.
Running sample #1 for PoomaII Brick Implementation:
  N = 100...
    Correctness test value for N = 100 is 1.00103.
Running sample #1 for PoomaII CompBrick Implementation:
  N = 100...
### POOMA Assertion Failure ###
### locked_m
### File ..\..\..\..\SRC\Threads/PoomaMutex.h; Line 138.
Pooma::pAbort called.
In default abort handler.
>>>

-assume_aliasing_across_function_calls  (this should make the optimization
more aggressive)

Runs to completion, N=100 correctness value 2.122e-313

-all +favor_fast_code  (/Ot)

Runs to completion, N=100 correctness value 2.122e-313

-all +full_optimization +favor_fast_code  (/Ox /Ot /Oy-)

Runs to completion, N=100 correctness value 2.122e-313

-all +full_optimization +global_optimizations +favor_fast_code  (/Ox /Ot
/Oy-)

Runs to completion, N=100 correctness value 2.122e-313

last +assume_aliasing_across_function_calls

<<<
### POOMA Assertion Failure ###
### locked_m
### File ..\..\..\..\SRC\Threads/PoomaMutex.h; Line 138.
Pooma::pAbort called.
In default abort handler.
>>>

It's behaving as if the sense of this option is reversed from the
description.

I still only have the Debug build producing a correct value for N=100.

Setting optimizations = minimum space (/O1) produces a correct run.

-all +favor_fast_code +improve_floating_point_consistency

This still gives the incorrect result for N=100.  I'm ready to conclude that
the Intel 5.0 optimizer is not to be trusted.  I doubt any of these problems
are Pooma code errors.

Allan