G'Day Alex, What a coincidence! :-)
Recently I've been playing with the libcpc info and needed a tool to walk memory with different patterns to create sustained D-Cache and E-Cache load. After writing such a tool I realised that the timing could be used to determine L1 and L2 access times, and memory access times. Fantastic! However I dissassembled my binary to see how many instructions per memory read it did, and found it was about 10 - as it included loop instructions. I unwound the loop somewhat so that copies were usually 2 instructions (no, didn't use a Duff's device :), a load and a store. Then used bvi to turn those stores into loads, so I could target D-Cache reads... I've had a quick peek at a memtest.c dissassembly, and it seems to do around 70 instructions per memory read. This is probably effecting the results. Perhaps it would improve memtest.c to also unroll the loop a little? I do like the options provided my memtest.c - such as -d, -c and -n. Good stuff. :-) thanks, Brendan [Sydney, Australia] On Fri, 19 Aug 2005, Alexander Kolbasov wrote: > I placed a tiny microbenchmark called "memtest" at > http://www.opensolaris.org/os/community/performance/numa/observability. It > basically walks a big memory chunk several times and measures the time it > takes > to do the walk. Although very simple this microbenchmark is quite configurable > and allows you to easily measure the effect of cache sizes, hardware prefetch > policies and memory locality. Try it out. It is especially interesting to play > with the "distance" (-d) options which specifies the distance in bytes between > subsequent reads. > > It would be really great to integrate it to libmicro. If Phil or Bart wouldn't > do it soon I'll try to integrate it with libmicro myself, but in the meantime, > feel free to play with it. > > - Alex > _______________________________________________ > perf-discuss mailing list > perf-discuss@opensolaris.org > > _______________________________________________ perf-discuss mailing list perf-discuss@opensolaris.org