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
-------------------------------------------------------------------------
SF.Net email is sponsored by:
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services
for just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
_______________________________________________
Valgrind-developers mailing list
Valgrind-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-developers
