Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Twenty years of Valgrind

nnethercote.github.io

Post reply on HN
Print view View original

21–30 of 118 posts

Re: Twenty years of Valgrind

#21

Post by dwroberts »

wyldfire wrote: post #14
whimsicalism wrote: post #11

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.

Valgrind does a lot of low level trickery so it hasn’t always supported the latest macOS releases straight away (or sometimes would support them with serious gotchas/limitations)

Re: Twenty years of Valgrind

#22

Post by compiler-guy »

I sort of owe callgrind a big chunk of my career.

I was working at a company full of PhDs and well seasoned veterans, who looked at me as a new kid, kind of underqualified to be working in their tools group. I had been at the firm for a while, and they were nice enough, but didn't really have me down as someone who was going to contribute as anything other than a very junior engineer.

We had a severe problem with a program's performance, and no one really had any idea why. And as it was clearly not a sophisticated project, I got assigned to figure something out.

I used the then very new callgrind and the accompanying flamegraph, and discovered that we were passing very large bit arrays for register allocation by value. Very, very large. They had started small enough to fit in registers, but over time had grown so large that a function call to manipulate them effectively flushed the cache, and the rest of the code assumed these operations were cheap.

Profiling tools at the time were quite primitive, and the application was a morass of shared libraries, weird dynamic allocations and JIT, and a bunch of other crap.

Valgrind was able to get the profiles after failing with everything else I could try.

The presentation I made on that discovery, and my proposed fixes (which eventually sped everything up greatly), finally earned the respect of my colleagues, and no phd wasn't a big deal after that. Later on, those colleagues who had left the company invited me to my next gig. And the one after that.

So thanks!

Re: Twenty years of Valgrind

#24

Post by tux3 »

andrewf wrote: post #17
vlmutolo wrote: 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…

I don't know how sophisticates the streaming/prefetch/access pattern prediction the 2002 cpus did was.

I'm speculating, but if that's not modeled, cachegrind may pessimize some less simple predictable patterns and report a lot of expected misses when the cpu would have been able to prefetch it

Re: Twenty years of Valgrind

#25

Post by azurezyq »

compiler-guy wrote: post #22

I sort of owe callgrind a big chunk of my career. I was working at a company full of PhDs and well seasoned veterans, who looked at me as a new kid, kind of underqualified to be working in their tools group. I had been at the firm for a while, and they were nice enough, but didn't really have me down as someone who was going to contribute as anything other than a very junior engineer. We had a severe problem with a p…

I have a very similar experience, but with a different profiling tool. When I first graduated from school and joined a big internet company, I'm not that "different". The serving stack was all in C++. My colleagues were really capable but not that into "tools", they'd rather depend on themselves (guess, tune, measure).

But I, as a fresh member in the team, learned and introduced Google perftools to the team and did a presentation of the breakdown of the running time of the big binary. I have to say that presentation was a life-changing moment in my career.

So together with you, I really want to thank those who devoted heavily into building these tools. When I was doing the presentation, I really felt standing on the shoulders of giants and those giants were helping me.

And over years, I used more and more tools like valgrind, pahole, asan, tsan.

Much appreciated!

Re: Twenty years of Valgrind

#26

Post by [deleted] »

Jason_Gibson wrote: post #8
galangalalgol wrote: post #7

Earlier quoted context omitted.

Our pipelines have asan ( and cpp check clang tidy coverity and coverage stuff) but no valgrind, is there something it is good at that we are missing?

ASAN on its own doesn't detect uninitialized memory. MSAN can, though. Valgrind is also more than just the memcheck sub-tool - there are others, like Cachegrind, which is a cache and branch-prediction profiler. https://github.com/google/sanitizers/wiki/AddressSanitizerCo... https://github.com/google/sanitizers/wiki/MemorySanitizer https://valgrind.org/docs/manual/manual.html

[deleted]

Re: Twenty years of Valgrind

#27

Post by andrewf »

tux3 wrote: post #24
andrewf wrote: post #17

Earlier quoted context omitted.

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…

I don't know how sophisticates the streaming/prefetch/access pattern prediction the 2002 cpus did was. I'm speculating, but if that's not modeled, cachegrind may pessimize some less simple predictable patterns and report a lot of expected misses when the cpu would have been able to prefetch it

Agreed, I suspect it'd be most accurate to say the SQLite folks are minimizing their working set.

I picked a couple of random performance commits out of their code repo, and they look like they might keep 1 or 2 lines out of i-cache: https://sqlite.org/src/info/f48bd8f85d86fd93 https://sqlite.org/src/info/390717e68800af9b

Re: Twenty years of Valgrind

#28

Post by koolba »

cjbprime wrote: 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.)

What other ways are there to (mis)pronounce it?

Re: Twenty years of Valgrind

#29

Post by nyanpasu64 »

whimsicalism wrote: post #15
wyldfire wrote: post #14

Earlier quoted context omitted.

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.

asan/ubsan do not detect uninitialized memory reads (though ubsan can detect when bools take on invalid bit patterns from uninitialized memory), and msan requires rebuilding the standard library or something, so I've never used msan. Valgrind is slow, but detects uninitialized memory reads properly, and doesn't require rebuilding the app (which is useful when running a complex or prebuilt app for short periods of time).

On the topic of profiling, callgrind can count exact function calls and generate accurate call graphs, which I find useful for not only profiling, but tracing the execution of unfamiliary code. I just wish rr had similarly fast tooling (pernosco is close enough to be useful, but I think there's value in exploring different workflows than what they picked).

Post reply on HN