Skip to content

Conversation

@milthorpe
Copy link

The GFLOP/s calculation in printTimings() for the OpenMP implementation was reporting incorrect (negative) values for large inputs, due to overflow. Computing ops_per_wg using long (rather than 32-bit) ints fixes the problem.

To test, run e.g.

./bude --deck ../data/bm2

before this change, miniBUDE reported:

...
Running C/OpenMP
- Total time:     30353.730 ms
- Average time:   3794.216 ms
- Interactions/s: 123.319 billion
- GFLOP/s:        -61.996
- GFInst/s:       3082.980

after the change, it reports:

Running C/OpenMP
- Total time:     30727.736 ms
- Average time:   3840.967 ms
- Interactions/s: 121.818 billion
- GFLOP/s:        3660.127
- GFInst/s:       3045.456

The GFLOP/s calculation in printTimings() for the OpenMP implementation
was reporting incorrect (negative) values for large inputs, due to overflow.
Computing ops_per_wg using long (rather than 32-bit) ints fixes the problem.
@milthorpe milthorpe changed the title fix FLOP/s calculation for OpenMP openmp: fix FLOP/s calculation Nov 29, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant