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

Reply via email to