[lug] Re: q: multithreading on smp weirdness
D. Stimits
stimits at comcast.net
Fri Dec 10 15:48:54 MST 2004
...
> well, as you know, there were 2 sets of profile data
> attached.
> the first set profiles the test app doing only 1 thread
> sync... it still runs on 2 threads, but only syncs once.
> it's also the one that multithreads properly (elapse time
> of 6 secs).
> but when i ran it with the profiler, it went really bad.
> (elapse time of 17 secs).
> the 2nd set profiles the test app doing 6000 thread syncs.
> it still runs on 2 threads, but syncs 6000 times.
> it's the one that didn't multithread properly (elapse time
> of 11+++ secs).
> but when i ran it with the profiler, it's elapse time
> wasn't too bad (elapse time of 12+ secs).
> strange.
It isn't unusual for adding debug symbols or profile data to cause a
failing app to work or act differently. I think most of the time it is
an indicator of some form of stack overflow condition, where the
rearrangement of code from the different configurations alter this. One
of the first things to try when this happens is to compile and test the
application at different compiler optimization levels. Try removing the
debug and profile data, and then compiling and running the same app on
the failing machine using various no-optimize through -O6 optimize (or
whatever your compiler calls max). Since the profiled code is not
behaving the same as the non-profiled failing code, there might not be
much you can get from it. It's always suspicious if the profile data is
far different than real life case, although you can expect some
non-reality from any profiled program just from rearrangement changes.
Were the working and non-working machines compiling and linking to all
the same lib versions? E.G., run ldd on each app on each machine and see
if the libs they point at are the same. Assuming compiler versions
differ among machines, consider testing by compiling on individual
machines, or distributing the binary from a working machine to a failing
machine and testing that.
...
D. Stimits, stimits AT comcast DOT net
More information about the LUG
mailing list