|
From: Vince W. <vi...@cs...> - 2007-03-28 02:55:55
|
Hello I was reading the PLDI paper and just wanted to say it's great work. I wish all this info were available last year when I first started writing some valgrind tools. One thing, in the paper it is mentioned that galgel wouldn't compile with gfortran. The secret to getting it to compile is the "-ffixed-form" option. Also, in previous e-mails when I was complaining about code quality in the spec2k benchmarks, I was of course excepting bzip2 in that analysis ;) Vince |
|
From: Nicholas N. <nj...@cs...> - 2007-03-28 03:46:34
|
On Tue, 27 Mar 2007, Vince Weaver wrote: > I was reading the PLDI paper and just wanted to say it's great work. I > wish all this info were available last year when I first started writing > some valgrind tools. Thanks! I see your tools at http://www.csl.cornell.edu/~vince/software.html, are they publically available? > One thing, in the paper it is mentioned that galgel wouldn't compile with > gfortran. The secret to getting it to compile is the > "-ffixed-form" > option. Ah, of course :/ Good to know for the future, thanks. > Also, in previous e-mails when I was complaining about code quality in the > spec2k benchmarks, I was of course excepting bzip2 in that analysis ;) I too have never had any problems with bzip2, unlike many of the others. Nick |
|
From: Vince W. <vi...@cs...> - 2007-03-28 19:56:17
|
> Thanks! I see your tools at > http://www.csl.cornell.edu/~vince/software.html, are they publically > available? I've just released the simpoint tool: http://www.csl.cornell.edu/~vince/projects/valsim/ I'm working right now on writing up all the results of the validation effort. I will release the other two tools eventually; unfortunately I am a bit swamped for time right now, trying to hit some paper deadlines. The valsim tool generates an x86 instruction stream for TAXI which is an x86 simulator that can't decode instructions itself. This is of limited use because I think the TAXI developer has taken the sources for it off of his website. The cache tool was part of a project I helped an MEng student do for their research project. It just dumps raw memory and instruction access traces to a pipe, and we had a cache-simuator read from the pipe in a different process and did some cache analysis. Vince |
|
From: Nicholas N. <nj...@cs...> - 2007-03-28 22:04:49
|
On Wed, 28 Mar 2007, Vince Weaver wrote: > I've just released the simpoint tool: > > http://www.csl.cornell.edu/~vince/projects/valsim/ > I'm working right now on writing up all the results of the validation > effort. Nice. I'd be interested to see the paper when it's done. You do things at the superblock level rather than the basic block level because Valgrind uses superblocks. I think if you use --vex-guest-chase-thresh=0 it will not chase across branches and thus will effectively do things at a basic block level. At least, that's what the comments for VexControl in VEX/pub/libvex.h seem to indicate -- Julian, is that right? (You could write another paper comparing accuracy of BBs vs SBs in SimPoint tools ;) You might then want to increase --vex-guest-max-insns to allow BBs to be as big as possible (at least bigger than 50, which is the default maximum). Nick |
|
From: Ashley P. <as...@qu...> - 2007-04-04 15:26:32
|
Vince Weaver wrote: > The cache tool was part of a project I helped an MEng student do > for their research project. It just dumps raw memory and > instruction access traces to a pipe, and we had a cache-simuator > read from the pipe in a different process and did some cache > analysis. This is something I'd be interested in, if ever I get time to write a tool I'd like to be able to look at allocated blocks (as returned by malloc) and view the read/write ratio for each one, kind of like massif but adding a "usage rate" weighting to the graph. I'd need a tool which dumped allocations (along with calling stack), deallocations and memory accesses, this could then be piped to a external process which would report: 1) Memory that is never written to or read from. 2) Memory that is written to but never read from. 3) Memory that is only used soon after creation and never again. 4) Invalid reads. 5) Reads from uninitialised memory. 4 & 5 are what effectively done by memcheck does anyway but would need to be handled by this tool The end result of this would be twofold, to help identify what may not technically be memory leaks but where memory usage increases over time and secondly to help developers reduce memory usage of applications by highlighting less frequently used memory regions. Ashley, |
|
From: Nicholas N. <nj...@cs...> - 2007-04-04 22:08:37
|
On Wed, 4 Apr 2007, Ashley Pittman wrote: > I'd need a tool which dumped allocations (along with calling stack), > deallocations and memory accesses, this could then be piped to a > external process which would report: > > 1) Memory that is never written to or read from. > 2) Memory that is written to but never read from. > 3) Memory that is only used soon after creation and never again. > 4) Invalid reads. > 5) Reads from uninitialised memory. I wrote a tool ages ago that tried to do 1, 2, and 3. IIRC I got bazillions of warnings out of it from code out of my control, and I quickly gave up. But I didn't spend very long on it, and my understanding of all this stuff was much less back then, so don't let me discourage you from trying it :) Nick |
|
From: Vince W. <vi...@cs...> - 2007-04-05 03:45:26
|
> This is something I'd be interested in, if ever I get time to write a > tool I'd like to be able to look at allocated blocks (as returned by > malloc) and view the read/write ratio for each one, kind of like massif > but adding a "usage rate" weighting to the graph. I've posted the code for my other two valgrind plugins (all three can be found here http://www.csl.cornell.edu/~vince/software.html feel free to link to them from the valgrind pages) My cachetool plugin writes out a memory trace that has in it info for ever load/store (for data cache simulation), every basic block entered (for instruction cache simulation), and every memory allocation/free (because we were tracking heap object usage). It passes along extra info in the traces, such as PC for loads and stores. It also passes along the call-trace info for the allocs/stores because we were trying to uniquely identify malloc() call sites. All of this was intended to be used for doing Cache Conscious Data Placement. Unfortunately this project has been side tracked for now. I've posted the code to the aforementioned website if you want to look at it. I haven't tested it for a while. The trace files generated can be quite large, so usually I'd write the output to a named pipe (mkfifo) and then have the analysis tool run at the same time reading from it. Vince |
|
From: Ashley P. <as...@qu...> - 2007-04-05 10:08:42
|
On Wed, 2007-04-04 at 23:45 -0400, Vince Weaver wrote: > > This is something I'd be interested in, if ever I get time to write a > > tool I'd like to be able to look at allocated blocks (as returned by > > malloc) and view the read/write ratio for each one, kind of like massif > > but adding a "usage rate" weighting to the graph. > > I've posted the code for my other two valgrind plugins > (all three can be found here > http://www.csl.cornell.edu/~vince/software.html > feel free to link to them from the valgrind pages) > > My cachetool plugin writes out a memory trace that has in it > info for ever load/store (for data cache simulation), every > basic block entered (for instruction cache simulation), > and every memory allocation/free (because we were tracking heap > object usage). This sounds very promising, I wouldn't want all the data it can provide but it would seem it does everything I want. > I've posted the code to the aforementioned website if you want to look at > it. I haven't tested it for a while. The trace files generated can be > quite large, so usually I'd write the output to a named pipe (mkfifo) and > then have the analysis tool run at the same time reading from it. I'd anticipated it being quite large, I'll pipe in directly into a external process. Ashley, |