|
From: Rodrigo D. <ro...@ho...> - 2008-09-16 20:45:11
|
Hi valgrind-developers, Is someone working on modifying valgrind to run multithreaded programs concurrently (without using the serializing semaphore)? This would allow valgrind to behave more similarly to the way the native application behaves. If not, would this be an interesting project for contribution? Thank you, Rodrigo Dominguez |
|
From: Nicholas N. <nj...@cs...> - 2008-09-17 05:13:19
|
On Tue, 16 Sep 2008, Rodrigo Dominguez wrote: > Is someone working on modifying valgrind to run multithreaded programs > concurrently (without using the serializing semaphore)? Not that I know of. > This would allow valgrind to behave more similarly to the way the native > application behaves. If not, would this be an interesting project for > contribution? Yes, but I think it's really difficult. You might find http://csl.stanford.edu/%7Echristos/publications/2008.safedbt.hpca.pdf interesting, it describes an approach for this that uses transactional memory. How well it works depends greatly on how inherently parallel the Valgrind tool's actions are. Nick |
|
From: Josef W. <Jos...@gm...> - 2008-09-22 13:52:46
|
On Tuesday 16 September 2008, Rodrigo Dominguez wrote: > Is someone working on modifying valgrind to run multithreaded programs > concurrently (without using the serializing semaphore)? Same as Nick: Not that I know of. > This would allow > valgrind to behave more similarly to the way the native application behaves. > If not, would this be an interesting project for contribution? You can approximate simultaneous execution better by choosing shorter scheduling time slices for the thread-serialization, perhaps even dynamic. But every thread switch has some overhead... Probably off-topic: to just get faster Valgrind runs, it is much better to not touch the core, but to parallize a tools tasks. Even this may prove difficult if there are many data dependencies among the needed tools actions for different threads. I suppose that (hardware) transactional memory would be very beneficial here, too. Josef > > > Thank you, > > > Rodrigo Dominguez > > |
|
From: Danny R. <dr...@cs...> - 2008-09-23 01:23:34
|
Josef Weidendorfer wrote: > On Tuesday 16 September 2008, Rodrigo Dominguez wrote: >> Is someone working on modifying valgrind to run multithreaded programs >> concurrently (without using the serializing semaphore)? > > Same as Nick: Not that I know of. This is some interesting timing! In the last few months I've been hacking away at Valgrind based code, looking at building performance analysis tools. As part of this we have a modified Valgrind/VEX which allows threads to run in parallel. This is mainly Valgrind core, as: * Some of the tools are a little difficult to parallelise (as has been pointed out in the Valgrind documentation) * We are developing our own tools The main areas we looked at were code caching mechanisms and atomic instruction implementations. We got a reasonable speedup until around 8 CPUs. If people are interested in more details I can give more specifics or can be contacted off list. I can forward code or more implementation details. As it stands, the modifications work right now, but there is still a reasonable amount of experiment code present. If this sounds like an appealing addition to Valgrind proper then I can clean up the code into a more sane series of patches. - Danny Robson |
|
From: Nicholas N. <nj...@cs...> - 2008-09-24 21:57:12
|
On Tue, 23 Sep 2008, Danny Robson wrote: > This is some interesting timing! In the last few months I've been > hacking away at Valgrind based code, looking at building performance > analysis tools. > > As part of this we have a modified Valgrind/VEX which allows threads to > run in parallel. This is mainly Valgrind core, as: > * Some of the tools are a little difficult to parallelise (as has been > pointed out in the Valgrind documentation) > * We are developing our own tools > > The main areas we looked at were code caching mechanisms and atomic > instruction implementations. We got a reasonable speedup until around 8 > CPUs. > > If people are interested in more details I can give more specifics or > can be contacted off list. I can forward code or more implementation > details. As it stands, the modifications work right now, but there is > still a reasonable amount of experiment code present. > > If this sounds like an appealing addition to Valgrind proper then I can > clean up the code into a more sane series of patches. I'm interested in hearing about it. Section 3.14 of http://valgrind.org/docs/valgrind2007.pdf discusses the difficulties of multithreading when tools use shadow memory. Do you have a solution for that, or do you just not worry about it because your tools don't use shadow memory? Nick |