gprof, -pg and rand() problem

[Andrew Bonello]

Hi

I have written a C++ program (Redhat Linux 7.2, gcc v2.96). The
program makes a sequence of calls to rand() after having seeded the
random number generator using srand( 0 ). Under normal circumstances,
for a given input state, the sequence of random numbers generated is
exactly reproduced each time the program is run. So, if I run the tool
3 times in succession, the path of execution is completely identical
each time as far as the sequence of random numbers is concerned.

I also want to profile the performance of this program, and so
recompiled and linked using the -pg option to allow gprof to be run
after execution.

However, I now find that the sequence of random numbers generated at
each subsequent run of the program is NOT reproducible. It looks like
linking with -pg is what caused the problem. Obviously, since the path
of execution is now different each time, the profiling results are
rather less meaningful.

Has anyone observed this behaviour? If so, can you recommend any ways
to get reproducible random number sequences WITH the -pg linking
option?

Thanks


Andrew.

 

[White Wolf]

Hi

I have written a C++ program (Redhat Linux 7.2, gcc v2.96). The

[SNIP]

Could you please post again the part of your question which was about the
Standard C++ programming language? I could not find it.

http://www.slack.net/~shiva/welcome.txt

http://www.slack.net/~shiva/offtopic.txt

 

[Jim Fischer]

Hi

I have written a C++ program (Redhat Linux 7.2, gcc v2.96). The
program makes a sequence of calls to rand() after having seeded the
random number generator using srand( 0 ). Under normal circumstances,
for a given input state, the sequence of random numbers generated is
exactly reproduced each time the program is run. So, if I run the tool
3 times in succession, the path of execution is completely identical
each time as far as the sequence of random numbers is concerned.

I also want to profile the performance of this program, and so
recompiled and linked using the -pg option to allow gprof to be run
after execution.

However, I now find that the sequence of random numbers generated at
each subsequent run of the program is NOT reproducible. It looks like
linking with -pg is what caused the problem. Obviously, since the path
of execution is now different each time, the profiling results are
rather less meaningful.

Has anyone observed this behaviour? If so, can you recommend any ways
to get reproducible random number sequences WITH the -pg linking
option?

Since this problem statement is specific to GNU G++ (and the GNU
profiling tools), the GNU G++ newsgroups / mailing lists are probably
the best/right places to ask for assistance. On Usenet, the GNU G++
"help" group is,

gnu.g++.help

For mailing list info, visit the GCC web site at

http://gcc.gnu.org

FWIW, you should also post a short, complete, compilable C++ program
sample that exactly demonstrates the problem you're describing. Without
some actual code to look at, the g++ folks can only make guesses as to
the "real" problem (e.g., compiler bug, code bug, linker bug, programmer
error ;-), etc.).

 

[Jim Fischer]

FWIW, you should also post a short, complete, compilable C++ program
sample that exactly demonstrates the problem you're describing. Without
some actual code to look at, the g++ folks can only make guesses as to
the "real" problem (e.g., compiler bug, code bug, linker bug, programmer
error ;-), etc.).

FWIW2, when I use a "stock" (non-redhat) GNU G++ 3.3.1 compiler to build
the following C++ code sample on a Red Hat 9 Linux box (with an Intel
Pentium-III/Celeron CPU), the program output is always the same - with
or without profiling support enabled:

// main.cpp

#include <cstdlib>
#include <iostream>
using namespace std;

int main()
{
srand( 0 );
for ( int i = 0; i < 10; ++i) {
cout << rand() << '\n';
}
}

$ g++ -Wall -Werror -O3 -pg -o try main.cpp


FWIW3: IIRC, the GCC 2.96.x releases are Red Hat specific beasts. So the
GNU G++ folks might redirect you to the Red Hat Linux groups / mailing
lists for help with this problem. IOW, the problem might be a "feature"
of Red Hat's GCC 2.96 builds...