Live data from Hacker News

Twenty years of Valgrind

nnethercote.github.io

11–20 of 118 posts

Re: Twenty years of Valgrind

#12
There are times when LeakSanitizer (in gcc-8.2) would not give me the full backtrace of a leak, while valgrind would, so to me it's still an indispensable tool for debugging leaks. One caveat is that it's magnitudes slower than valgrind. Now, if only I know how to make valgrind run as fast as LeakSanitizer... (command line options?)

Re: Twenty years of Valgrind

#14

It's unfortunate that so many of these great tools (like `perf` and I believe `valgrind`) are basically not available locally on the Mac. And running in a container is not really a solution for most of these.

Sanitizers and electric fence are ultra portable, they're definitely available on macos. The feature set from valgrind is a bit richer but not by much.

Re: Twenty years of Valgrind

#15

It's unfortunate that so many of these great tools (like `perf` and I believe `valgrind`) are basically not available locally on the Mac. And running in a container is not really a solution for most of these.

Sanitizers and electric fence are ultra portable, they're definitely available on macos. The feature set from valgrind is a bit richer but not by much.

I am not familiar with electric fence but I remember from my experience that there are definitely important things that I got from `perf` and `valgrind` that the alternative sanitizers did not provide. Can't recall what now of course.

Re: Twenty years of Valgrind

#16
post #12

There are times when LeakSanitizer (in gcc-8.2) would not give me the full backtrace of a leak, while valgrind would, so to me it's still an indispensable tool for debugging leaks. One caveat is that it's magnitudes slower than valgrind. Now, if only I know how to make valgrind run as fast as LeakSanitizer... (command line options?)

You might need to add -fno-omit-frame-pointer to help ASAN unwind the stack.

Re: Twenty years of Valgrind

#17
post #3

> I still use Cachegrind, Callgrind, and DHAT all the time. I’m amazed that I’m still using Cachegrind today, given that it has hardly changed in twenty years. (I only use it for instruction counts, though. I wouldn’t trust the icache/dcache results at all given that they come from a best-guess simulation of an AMD Athlon circa 2002.) I'm pretty sure I've seen people using the icache/dcache miss counts from valgrind…

https://sqlite.org/cpu.html#microopt -

Cachegrind is used to measure performance because it gives answers that are repeatable to 7 or more significant digits. In comparison, actual (wall-clock) run times are scarcely repeatable beyond one significant digit [...] The high repeatability of cachegrind allows the SQLite developers to implement and measure "microoptimizations".

There's a bunch of ways for caches to behave differently but have they changed much over the past 20 years? i.e. is the difference between [2022 AMD cache, 2002 AMD cache] significantly greater than the difference between [2002 PowerPC G4 cache, 2002 AMD cache, 2002 Intel cache] ?

Re: Twenty years of Valgrind

#20
post #2

I wish I hadn't read this article because now I know that I've been mispronouncing Valgrind for nearly 20 years but I'm not going to stop. (Kidding. Thanks for Valgrind! I still use it for assessing memory corruption vulnerabilities along with ASan.)

I learned of the tool from a native German speaker who pronounced it wall-grinned, which is apparently half-right. Like latex, I can't keep the pronunciation straight from one sentence to the next.
Post reply on HN