|
From: Vince W. <vi...@cs...> - 2007-12-20 03:06:30
|
Hello I've updated my Simpoint Basic Block Vector generating plugin to work with Valgrind 3.3.0 http://www.csl.cornell.edu/~vince/projects/valsim/ I was wondering what the criteria are for becoming an official experimental plugin that is included in the main valgrind tree. I'd be willing to maintain this plugin if it was determined to be useful enough. When updating the tool for 3.3.0, I converted it from using hash tables to using the ordered set code. I mainly did this because I use the cachegrind code as a reference, not for any CS reason. In the end my plugin seems to run maybe 25% slower than the 3.2.3 version. Is this expected? The plugin inserts the address of every basic block encountered into the data structure, and does a lookup on every instruction executed. Now that I think about it, maybe I should go back to using hash tables. Vince |
|
From: Nicholas N. <nj...@cs...> - 2007-12-20 08:17:20
|
On Wed, 19 Dec 2007, Vince Weaver wrote: > I've updated my Simpoint Basic Block Vector generating plugin to work with > Valgrind 3.3.0 > http://www.csl.cornell.edu/~vince/projects/valsim/ > > I was wondering what the criteria are for becoming an official > experimental plugin that is included in the main valgrind tree. I'd be > willing to maintain this plugin if it was determined to be useful enough. We don't really have official guidelines for adding experimental tools, other than someone must be willing to maintain it. I think it could be useful to multiple people using Simpoints, so I think it could be a suitable addition. I see it's a fairly simple tool (bbv_main.c isn't very long), so that's a plus. > When updating the tool for 3.3.0, I converted it from using hash tables to > using the ordered set code. I mainly did this because I use the > cachegrind code as a reference, not for any CS reason. Your CHANGES file says this: + Major change is to use Ordered Set instead of hash table. I only really did this because cachegrind made the change. Potentially a performance slowdown? This is for the instr_info_table. I have to go back to Cachegrind from the 3.0.X line to see it was a VgHashTable rather than an OSet. > In the end my plugin seems to run maybe 25% slower than the 3.2.3 version. > Is this expected? The plugin inserts the address of every basic block > encountered into the data structure, and does a lookup on every > instruction executed. Now that I think about it, maybe I should go back to > using hash tables. OSet uses an AVL tree. It's more general than VgHashTable, but not as fast. VgHashTable recently got improved to auto-resize when it gets too full, so it doesn't have the scaling issues it used to. If you're looking up the OSet for every instruction then I can believe that would cause a big slow-down. I think you can instead do the look-up at instrumentation-time rather than run-time. Every time you execute an instruction, you look-up using the start address of its basic block as the key. You could do that look-up in bbv_instrument() instead of updateBBV(), and pass to updateBBV() the address of the found instr_info_table node, and it should make a huge difference. (And the difference between the OSet and VgHashTable will become much less important.) This is what Cachegrind does. Nick |
|
From: Vince W. <vi...@cs...> - 2008-01-09 04:16:33
|
Hello > > http://www.csl.cornell.edu/~vince/projects/valsim/ > > > We don't really have official guidelines for adding experimental tools, > other than someone must be willing to maintain it. I think it could be > useful to multiple people using Simpoints, so I think it could be a suitable > addition. I see it's a fairly simple tool (bbv_main.c isn't very long), so > that's a plus. Yes, it's a relatively straightforward tool. It would be nice to have a completely open-source bbv generating tool available to the general public. I must admit some of my reasons for wanting it merged are a bit selfish; I mainly hate messting around with automake and configure files whenever I want to build the tool on a new machine. I really need to get some test cases too. Trying to get things in shape for merging with a public tree is a good incentive for getting around to lots of testing and code cleanup. > If you're looking up the OSet for every instruction then I can believe that > would cause a big slow-down. I think you can instead do the look-up at > instrumentation-time rather than run-time. You're right, I hadn't thought about that! I've made this change, and now my tool runs at least twice as fast as it used to. Thanks Vince |