[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