Practical limits of bit reproducibility #1620
Replies: 2 comments 2 replies
-
|
@marshallward Besides the ⬆️ above 2 items ( Specifically, if a PR approver, does not get same answers for ALL the platform(s) for their choice, is the PR going to be held up? Is this even a criteria? |
Beta Was this translation helpful? Give feedback.
-
|
At the moment, every partner has a veto before merging to But that doesn't mean that development has been held up. Each partner can merge in the commits of the others at any time. There is no reason why NCAR or NASA-GEOS could not take NOAA-GFDL's content today. This is why we have all agreed to preserve the history of our Obviously we don't want to encourage those "side-merges" too much. The safest choice is to get that content from I think a discussion like this might help each group to decide how a realistic bit reproducibility criteria ought to look. |
Beta Was this translation helpful? Give feedback.
-
|
After the MOM6 community discussion of this issue on 2/26/2024, I have been examining the question of how many actual instances are there where is seems possible or probable that enabling Fused-Multiply-Adds (FMAs) would break the rotational symmetry of the MOM6 answers when FMAs are enabled. With the current version of the MOM6 code on dev/gfdl (exclusive of the ice-sheet code), I think that there are 591 lines where we would need to add parentheses to preserve symmetry with FMAs. I think that there are about 100 lines where dealing with this issue might actually make the code faster or where there are clearly no regrets (e.g., rewriting Given that something of order 50% of the 220,000 lines of code in MOM6 actually do any calculations, my guess is that about 0.5% of the lines of calculations would need to be modified with added parentheses to preserve symmetry with FMAs. Based on this list of 591 lines that might need to be changed, I suspect that it would practical to set up a trial branch of MOM6 that we could use to evaluate the impact on the speed of MOM6 from the changes we would need to preserve rotational symmetry with FMAs. If anyone is interested, I can send you the text file with my list of the potentially problematic lines, but at over 600 lines (including the ice-sheet code and some notes) this file is probably too large to post here. |
Beta Was this translation helpful? Give feedback.
-
|
@Hallberg-NOAA Thank you! If you would either post it in a new repo (preferred) Or email, would be great. |
Beta Was this translation helpful? Give feedback.
-
Review of #1616 has prompted some discussion around what we should expect and/or require of partners with respect to bit reproducibility.
For some context: although we generally allow each partner to define its own reproducibility requirements, there can still be problems or disagreements when a particular PR seems incapable of meeting those requirements.
For the sake of discussion, here are some of the specific topics which came up, or just immediately come to mind:
What compiler settings and/or flags do we support? Which do we explicitly not support?
FMAs are emerging as a very sensitive topic.
What exactly are these Intel
-fp-modelflags doing? How do they modify our arithmetic, if at all?What are the cross-platform expectations? Are all chips equal?
Any limits to addition/subtraction/multiplications accuracy?
IEEE-754 prescribes "exact" division and square-root, does this hold?
Are FMAs always more accurate across platforms? In the same way?
Some of these topics have already been discussed (and perhaps even resolved).
The MOM6 style guide discusses some topics, like intrinsics, order of operations, and role of parentheses.
I have raised some of the more fundamental issues at the J3-Fortran proposals board.
j3-fortran/fortran_proposals#314
A discussion of some of the questions around FMAs.
j3-fortran/fortran_proposals#310
Beta Was this translation helpful? Give feedback.
All reactions