urand graph generation test fails on Ubuntu 22 about gapbs HOT 4 CLOSED

This is an unfortunate situation that has been getting worse. Although C++ standards carefully specify how the random number generators should behave, they do not do the same for uniform_int_distribution (reddit post). With seeding, the generator will produce the same values, but the distribution will not. When this codebase was first constructed, gcc, clang, icc, and suncc used the same distribution algorithm. Recently, there has been some divergence. On a linux box, g++ 9.4 and clang++ 12 produce the same right answer. However, on my mac, Apple clang 14 and g++-12 produce different results.

Fortunately, for those concerned about running the exact same benchmark graphs, SuiteSparse captured the graphs a couple years ago (https://sparse.tamu.edu/GAP).

I'm going to leave this issue open, since the only solutions I can think of are unsatisfactory. I would be grateful if anyone has a better idea. So far, the options I can think of all have downsides:

1. Do nothing - Although randomly generated graphs will be subtly different, for most research purposes this is ok. The most worrisome part is a unit test not passing. For now, GitHub's CI is using a compiler that still has the same distribution function, so it is still passing.
2. Replace the distribution with % - This will be portable, however, modulus can add bias to the distribution. This is especially likely as the range gets close to the size of the random numbers, which someone might do with SCALE=29 or SCALE=30.
3. Write a portable distribution function - This might be the least bad but the most work. Doing it well involves both removing bias as well as being high-performance. Typically, I duplicate functionality from the standard library as a last result.
4. Make test case weaker - This might be an expedient solution, but then the test case may not be checking much.

from gapbs.

With CI failing, I checked to see the current state of which distribution each compiler is using.

In my lab, I had Linux boxes with gcc 9,10,11,13 and clang 12 and 14. Gcc 9 & 10 behaved like the original reference output. Gcc 11 onwards as well as the clang versions all behaved the same. With any luck, gcc & clang will continue to have the same implementation behavior.

Thus, going with a slightly modified version of option 1 (via commit 30197cf).

from gapbs.

Spoke too soon. Clang (14) on my Mac produces yet another answer.

Option 3 will probably be the best.

from gapbs.

I went with option 3 to further standardize this reference code.

from gapbs.