>
>
> Improved accuracy can only be a good thing. Is MSMProp1 accurate
> enough that you can find bugs in your real applications, without
> getting to many false errors now?
Yes!
(I still see many false reports due to custom synchronization and that needs
code annotations, but that's another story...)
>
>
> > but noticeably slower
> > (mostly because it has to check happens-before in all states).
>
> Maybe some better caching of the happens-before queries would
> help? The current inplementation (hbefore__cache et al) uses a
> 64-entry fully associative cache, in effect. Maybe it would be
> better to have a larger, set-associative cache, eg 256 lines of
> 4 entries each, for example.
I don't see many cache misses here.
But MSMProp1 has a loop where MSMHelgrind did not have it.
Anyway, this needs more experiment...
>
> For sure a lower miss rate on the cache is possible. Also, the
> miss path -- function cmpGEQ_VTS -- is naively coded, we could
> do a lot better there. Maybe it is possible to change the
> representation of VTSs so that comparison using vector operations
> (SSE insns, etc) is possible. Or at least so that the complex
> alignment logic can be avoided.
Right now I use the graph machinery, not vts.
In order to support barrier I have to create a fake segment which does not
belong to any thread.
I did not figure out what VTS to put in that fake segment (well, I did not
try hard :))
--kcc
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Valgrind-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/valgrind-developers
