|
From: Ben L. <li...@cs...> - 2006-12-15 03:03:51
|
Nick Nethercote wrote: > I'm surprised what you're trying doesn't make Valgrind explode. > [...] I have no idea why the code would not be genuinely discarded. Heh. :-D I'm a bit surprised too. My best guess is that the VALGRIND_DISCARD_TRANSLATIONS call is behaving as a no-op just like any other client call would when executed in non-Valgrind-translated code. I'm invoking VALGRIND_DISCARD_TRANSLATIONS from an external function, and presumably Valgrind leaves these alone. > First question: do you really need this optimisation? Does it make a > big difference? I'd be interested to know what the tool does. I do not know how big a difference it makes, since it's not actually working yet. I was hoping to measure that experimentally. Actually, perhaps I can do a better job of estimating the maximum possible benefit of the optimization. It will never be faster than running the code with no instrumentation inserted at all, ever. So I can profile that; profile instrumentation without self-removal; and see if there's a big difference. If the difference is insignificant, it's not worth pursuing this idea any further. > If so, I'd probably use the support for conditional dirty calls Ah, I hadn't noticed that before. OK, I may give this a try. It's likely that this will be slower than doing things unconditionally, though. The actual instrumentation work is pretty fast, and can even be "inlined" using just a handful of UCode instructions instead of a dirty call if I'm not trying to do crazy things like call VALGRIND_DISCARD_TRANSLATIONS. Thanks for the feedback and ideas, Nick! -- Ben |