|
From: Michael E. L. <me...@co...> - 2004-05-07 16:03:49
|
Hi, I was wondering (before I dig into the source and fiddle about) if the si= ze of=20 Valgrind's instruction cache was adjustable -- nothing I see on the websi= te http://developer.kde.org/~sewardj/docs-2.0.0/coregrind_core.html#flags docs for cmd line flags seems to apply, but this text=20 "The translations are managed using a traditional LRU-based caching schem= e.=20 The translation cache has a default size of about 14MB." seems to imply that it *may* be adjustable (if that just means a compile = time=20 config or changing the src, that's cool). Cheers, Michael |
|
From: Nicholas N. <nj...@ca...> - 2004-05-07 16:37:46
|
On Fri, 7 May 2004, Michael E. Locasto wrote: > I was wondering (before I dig into the source and fiddle about) if the size of > Valgrind's instruction cache was adjustable I think it's a build-time constant, it may be governed by the VG_TT_SIZE constant in coregrind/vg_transtab.c. Why do you want to change this? N |
|
From: Nicholas N. <nj...@ca...> - 2004-05-07 17:12:07
|
On Fri, 7 May 2004, Michael E. Locasto wrote: > I was looking for a way to disable the translation table entirely; that is, > get VG to instrument just one instruction (or maybe just one basic block) at > a time and then forget about it. I'm trying to compare VG to a system that > translates one instruction at a time and then does not cache the translation. > > I could try to mimic this by forcing VG to flush frequently (via a low > VG_TT_LIMIT_PERCENT value) but that introduces the overhead of doing the > LRU into the measurements. And the flushing isn't cheap, IIRC, so that's going to skew things further. Also, whether it's a fair comparison depends on the details of the system you're comparing it to. Ie. Valgrind is a bit slower than other dynamic binary instrumentation frameworks because it is built to support more pervasive analysis code. There's a paper called "An Infrastructure for Adaptive Dynamic Optimization" by Bruening, Garnett and Amarasinghe (http://www.cag.lcs.mit.edu/commit/papers/03/RIO-adaptive-CGO03.pdf) about a dynamic binary instrumentation system called DynamoRIO that's similar to Valgrind. Table 1 in that paper shows how they sped their system up from pure emulation, which sounds like just what you want to know. N |
|
From: Michael E. L. <me...@co...> - 2004-05-07 17:25:48
|
On Friday 07 May 2004 01:12 pm, Nicholas Nethercote wrote: > On Fri, 7 May 2004, Michael E. Locasto wrote: > > There's a paper called "An Infrastructure for Adaptive Dynamic > Optimization" by Bruening, Garnett and Amarasinghe > (http://www.cag.lcs.mit.edu/commit/papers/03/RIO-adaptive-CGO03.pdf) ab= out > a dynamic binary instrumentation system called DynamoRIO that's similar= to > Valgrind. Table 1 in that paper shows how they sped their system up fr= om > pure emulation, which sounds like just what you want to know. Fantastic; this is very useful information..thanks much. Cheers, Michael btw: assertions start failing when I tinker with the table size, and if t= he=20 assertions are disabled, VG segfaults. I suppose that's to be expected. |
|
From: Nicholas N. <nj...@ca...> - 2004-05-07 17:26:59
|
On Fri, 7 May 2004, Michael E. Locasto wrote: > btw: assertions start failing when I tinker with the table size, and if the > assertions are disabled, VG segfaults. I suppose that's to be expected. That's not a bug, that's a feature :) N |