SUMMARY One of the limitations on DHAT is that it always summarizes the access counts under either acc-ratio or the "Aggregated access counts by offset" table. I might have the question "how many times was an allocator accessed" as a very general question. "What is the read count of any width at any offset across all of blocks." As it stands, I must carefully look at the "Aggregated access counts by offset" tables to determine how large each field in a struct is and carefully add up the numbers. If the "Aggregated access counts by offset" table isn't available, then I can guess the size of elements in a list, then calculate acc-ratio*average-block-size/guessed-width. OBSERVED RESULT ==48857== -------------------- 4 of 100000 -------------------- ==48857== max-live: 2,097,152 in 1 blocks ==48857== tot-alloc: 4,194,302 in 21 blocks (avg size 199728.66) ==48857== deaths: 21, at avg age 23,607,512 (0.00% of prog lifetime) ==48857== acc-ratios: 0.49 rd, 0.00 wr (2,097,130 b-read, 0 b-written) ==48857== at 0x4C2DE45: calloc (in /usr/lib/valgrind/vgpreload_exp-dhat-amd64-linux.so) ==48857== by 0x4040FA: quantum_gate1 (gates.c:361) ==48857== by 0x407BD7: quantum_hadamard (gates.c:665) ==48857== by 0x41460A: main (shor.c:96) EXPECTED RESULT ==48857== -------------------- 4 of 100000 -------------------- ==48857== max-live: 2,097,152 in 1 blocks ==48857== tot-alloc: 4,194,302 in 21 blocks (avg size 199728.66) ==48857== deaths: 21, at avg age 23,607,512 (0.00% of prog lifetime) ==48857== acc-ratios: 0.49 rd, 0.00 wr (2,097,130 b-read in 65,535 rd, 0 b-written in 0 wr) ==48857== at 0x4C2DE45: calloc (in /usr/lib/valgrind/vgpreload_exp-dhat-amd64-linux.so) ==48857== by 0x4040FA: quantum_gate1 (gates.c:361) ==48857== by 0x407BD7: quantum_hadamard (gates.c:665) ==48857== by 0x41460A: main (shor.c:96) SOFTWARE/OS VERSIONS Linux: Ubuntu 16.04.2 LTS (Xenial Xerus) GNU/Linux 4.4.0-138-generic Valgrind: valgrind-3.11.0
Valgrind 3.15 just came out and it completely overhauled DHAT. The new version is much better. The output is now in a tree. The root node of the tree covers the entire program, and looks like this: > AP 1/1 (25 children) { > Total: 1,355,253,987 bytes (100%, 67,454.81/Minstr) in 5,943,417 blocks (100%, 295.82/Minstr), avg size 228.03 bytes, avg lifetime 3,134,692,250.67 instrs (15.6% of program duration) > At t-gmax: 423,930,307 bytes (100%) in 1,575,682 blocks (100%), avg size 269.05 bytes > At t-end: 258,002 bytes (100%) in 2,129 blocks (100%), avg size 121.18 bytes > Reads: 5,478,606,988 bytes (100%, 272,685.7/Minstr), 4.04/byte > Writes: 2,040,294,800 bytes (100%, 101,551.22/Minstr), 1.51/byte > Allocated at { > #0: [root] > } > } I'm not sure I understand exactly what you're asking for, but: - "how many times was an allocator accessed" might be the "5,943,417 blocks" part - "What is the read count of any width at any offset across all of blocks" might be the "Reads: 5,478,606,988 bytes" part, though that's a byte count rather than a read count. Does that help?
(In reply to Nick Nethercote from comment #1) > Valgrind 3.15 just came out and it completely overhauled DHAT. The new > version is much better. > > The output is now in a tree. The root node of the tree covers the entire > program, and looks like this: > > > AP 1/1 (25 children) { > > Total: 1,355,253,987 bytes (100%, 67,454.81/Minstr) in 5,943,417 blocks (100%, 295.82/Minstr), avg size 228.03 bytes, avg lifetime 3,134,692,250.67 instrs (15.6% of program duration) > > At t-gmax: 423,930,307 bytes (100%) in 1,575,682 blocks (100%), avg size 269.05 bytes > > At t-end: 258,002 bytes (100%) in 2,129 blocks (100%), avg size 121.18 bytes > > Reads: 5,478,606,988 bytes (100%, 272,685.7/Minstr), 4.04/byte > > Writes: 2,040,294,800 bytes (100%, 101,551.22/Minstr), 1.51/byte > > Allocated at { > > #0: [root] > > } > > } > > I'm not sure I understand exactly what you're asking for, but: > - "how many times was an allocator accessed" might be the "5,943,417 blocks" > part > - "What is the read count of any width at any offset across all of blocks" > might be the "Reads: 5,478,606,988 bytes" part, though that's a byte > count rather than a read count. > > Does that help? Thanks! I glanced at the changelog for DHAT yesterday and noticed all the overhauls. I will upgrade ahead of cannocial's repos at my earliest convenience. Perhaps I was being confusing by describing what I want in two different ways. The "5,478,606,988 bytes" part is very close to what I want to know, though as you point out it's a byte count rather than a read count. I am currently designing a tool that puts wrappers around every read and write, so the access count is more important to me than the number of bytes accessed. I know the development team historically has been looking for feedback on what people want to use DHAT for, so I figured I would open this feature request if only for informational purposes.