|
From: Bart V. A. <bar...@gm...> - 2007-02-27 13:51:57
|
A new drd version is available at the following location: http://home.euphonynet.be/bvassche/valgrind/valgrind-6618-drd-2007-02-27.patch.gz Changes compared to version 2007-02-22: - Eliminated AMD64 false positives -- drd now behaves consistently on X86 and AMD64. - Started optimizing the bitmap implementation in drd -- drd now works several times faster for clients with 10 threads or more. More work has to be done in this area however. (Only bm_clear() and bm_has_access() have been optimized. According to cachegrind, VG_(OSet_Next)() is now the function that consumes most CPU cycles.) - The soft link in .in_place/drd/default.supp is now created automatically -- drd's default suppression file is not yet automatically installed in the installation directory. - Specifying Valgrind's option -v no longer triggers a crash in drd. - Defined new pthread_pre_create tracking function. - New command-line option: --trace-suppression. Most important known bugs: - drd is soon killed by the OOM handler when started with bigger clients. - drd/default.supp has to be installed manually in the installation dir. An example of how the patch can be applied and the regression tests can be run: svn co svn://svn.valgrind.org/valgrind/trunk valgrind cd valgrind gzip -cd ../valgrind-6618-drd-2007-02-27.patch.gz | patch -p0 - ./autogen.sh ./configure --prefix=$PWD/inst make -s make -s check chmod a+x drd/tests/filter_stderr perl tests/vg_regtest drd -- Regards, Bart Van Assche. |
|
From: Nicholas N. <nj...@cs...> - 2007-02-27 22:25:23
|
On Tue, 27 Feb 2007, Bart Van Assche wrote: > A new drd version is available at the following location: > http://home.euphonynet.be/bvassche/valgrind/valgrind-6618-drd-2007-02-27.patch.gz Good work :) > - Started optimizing the bitmap implementation in drd -- drd now works > several times faster for clients with 10 threads or more. More work > has to be done in this area however. (Only bm_clear() and > bm_has_access() have been optimized. According to cachegrind, > VG_(OSet_Next)() is now the function that consumes most CPU cycles.) Cachegrind doesn't tell you cycles, only instructions and cache misses. Often they correlate to cycles pretty well but not always. If OSet is too slow, you could try using VgHashTable (see pub_tool_hashtable.h). It has a similar interface and so you might be able to switch over easily. It's faster in some cases, especially for iteration. Or, you could try to reduce the number of times you iterate over the data structure :) Nick |
|
From: Bart V. A. <bar...@gm...> - 2007-03-01 18:58:51
|
On 2/27/07, Nicholas Nethercote <nj...@cs...> wrote: > On Tue, 27 Feb 2007, Bart Van Assche wrote: > > > - Started optimizing the bitmap implementation in drd -- drd now works > > several times faster for clients with 10 threads or more. More work > > has to be done in this area however. (Only bm_clear() and > > bm_has_access() have been optimized. According to cachegrind, > > VG_(OSet_Next)() is now the function that consumes most CPU cycles.) > > Cachegrind doesn't tell you cycles, only instructions and cache misses. > Often they correlate to cycles pretty well but not always. > > If OSet is too slow, you could try using VgHashTable (see > pub_tool_hashtable.h). It has a similar interface and so you might be able > to switch over easily. It's faster in some cases, especially for iteration. > Or, you could try to reduce the number of times you iterate over the data > structure :) Good suggestion. But I'm not sure which hash size to choose ? There are a lot of bitmaps allocated during program run, some small, some large. I'll consider this anyway as an option when I continue optimizing. Bart. |