Re: performance measurement and caches

> I repeatedly time two exeutables, getting approximately
> repeatable times for each:
> ...
> real 10.5
> ...
> real 5.5
> ...
> So what's wrong? Slowtest and fasttest were bitwise identical executables!
>
> Based on conversations with Marvin Theimer and Tim Diebert, we even
> managed to come up with a likely explanation. (Corrections
> appreciated.) The machine in question was a SPARCstation 10, with an
> L2 cache. Apparently the L2 cache is physically indexed, and direct
> mapped. The executable files were read once and loaded into the file
> system cache. Thus their location in physical memory did not change
> across runs. (The performance did change when I repeated the test a
> day later.) Apparently slowtest was loaded in an unfortunate
> position, so that two very frequently accessed code sections collided
> in the cache.


I've seen this sort of phenonoma before too. This can be a
particularly nasty problem for us since we do hard real time. Our OS
goes through great lengths to do something that I think they call
"page coloring" to minimize the non-determinism. It does a fairly
good job.


We also have two-tiered memory. Although I may set my process to
prefer local memory. If that's gone, I might get some pages of the
slower global memory too, or worse, it some other processors local
memory. Performance critical stuff gets run restricted to local
memory (The 'run' command can set these sorts of parameters).


--
Jeffrey Glen Jackson
jgj@ssd.csd.harris.com
--

Return to the comp.compilers page.
Search the comp.compilers archives again.