|
From: Arndt M. <amu...@is...> - 2007-02-28 14:28:19
|
Nicholas Nethercote schrieb: > On Tue, 27 Feb 2007, Bart Van Assche wrote: > >>> There was a paper at the ASPLOS conference last year about a race >>> detector, >>> they compared it to Helgrind and found Helgrind was about that slow. >>> >>> Memcheck is 20--30x slower, but it is a lot more tuned than Helgrind. >> >> Are you referring to this paper: >> http://valgrind.org/docs/muehlenfeld2006.pdf ? > > No. The paper's called "AVIO: Detecting atomicity violations via > access interleaving invariants", by Lu, Tucek, Qin and Zhou. They > measured Helgrind on four programs and got an average slow-down of 694x. Unfortunately, the authors did neither say what parameters they used for the benchmarks nor how many cores (4?) they used. I tried fft, one of the SPLASH-2 kernel benchmarks and got the following results (3GHz P4, 1G memory): fft -m22 2.7s valgrind --tool=none fft -m22 28.2s (10.4x) valgrind --tool=helgrind fft -m22 221.5s (82.0x) I tried every value for -p (number of threads) less than 100 with no change. In the paper they claim that the overhead for fft is 1217x! The memory usage with Helgrind is doubled, 392M instead of 197M, therefore when I tried -m24, Helgrind used 1.5G instead of 768M which resulted in horrible swapping, probably giving a factor of 1000+, but I don't know exactly, because I interrupted the test after a couple of minutes. Other tests I did showed an overhead between 30x and 50x. I think the reported overhead of 694x is too high for applications that fit in memory. I will investigate tomorrow whether my results with the network server have the same reason: swapping due to increased memory usage. Arndt |