On Thursday 28 May 2009, Ivan Novick wrote: > A report that would be very help full for application developers would be > like this: > LINE OF CODE # of INSTANCES OF FALSE SHARING > DETECTED > array[x] = val; main.c:44 1,234,567 > b = y; main.c:124 134,233 > k = l; sum.c:233 44,123 > ...... etc > > To help app developers quickly find the biggest violators
Yes. Unfortunately, a detection of the false sharing events that really happened in a Valgrind run of a multithreaded code will be *far off* to any counts of events on a real machine because of Valgrinds thread serialization, which also significantly influences any dynamic load balancing decisions in the client code (e.g. OpenMP dynamic/guided loop or task scheduling). However, for larger code, it seems important to me to list instances of false sharing sorted by count estimations. IMHO it would be better to look at potentionally overlapping segments of code per thread (like done in DRD), and collect meta information to estimate an upper bound of false sharing events which could have happened between any two code segments of different threads (assuming all threads run on different cores). And these estimations should somehow be related to cycle estimations of the cache simulator to estimate the improvement one could achieve, ie. scaled by estimations of cache invalidation/refill times. Josef PS: Actually, I am looking into something like this... > > Regards, > Ivan Novick > > > On Wed, May 27, 2009 at 4:45 PM, Nicholas Nethercote <[email protected] > > wrote: > > > On Thu, May 28, 2009 at 9:12 AM, Ivan Novick <[email protected]> wrote: > > > Hi, > > > I would like to detect cases of false sharing in my program. > > > By this I mean cases where multiple threads are both trying to write data > > to > > > different memory locations but those locations are closest enough in > > memory > > > that they are on the on the same cache line. > > > The result would be delays on threads even though there are enough CPU's > > to > > > do the work. > > > Are there any tools in valgrind to do this? > > > > No, but it wouldn't be too hard to write a new one that did this. For > > each cache-line-sized chunk of memory, you'd record which thread last > > wrote to it and when, and then if another thread wrote to a chunk > > sufficiently soon after a previous thread you'd give a warning. You > > could record thread numbers and addresses and stack traces and the > > like, there'd be trade-offs in how much overhead you'd have vs. how > > much info you'd get in each report. > > > > Nick > > > ------------------------------------------------------------------------------ Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT is a gathering of tech-side developers & brand creativity professionals. Meet the minds behind Google Creative Lab, Visual Complexity, Processing, & iPhoneDevCamp as they present alongside digital heavyweights like Barbarian Group, R/GA, & Big Spaceship. http://p.sf.net/sfu/creativitycat-com _______________________________________________ Valgrind-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/valgrind-users
