Related articles |
---|
[3 earlier articles] |
Re: performance measurement and caches romer@cs.washington.edu (1996-02-16) |
Re: performance measurement and caches jgj@ssd.hcsc.com (1996-02-16) |
Re: performance measurement and caches alms@pesqueira.di.ufpe.br (1996-02-16) |
Re: performance measurement and caches mff@research.att.com (Mary Fernandez) (1996-02-16) |
Re: performance measurement and caches grunwald@foobar.cs.colorado.edu (1996-02-17) |
Re: performance measurement and caches Terje.Mathisen@hda.hydro.com (Terje Mathisen) (1996-02-18) |
Re: performance measurement and caches cdg@nullstone.com (1996-02-19) |
Re: performance measurement and caches mschmit@ix.netcom.com (1996-02-21) |
From: | cdg@nullstone.com (Christopher Glaeser) |
Newsgroups: | comp.compilers |
Date: | 19 Feb 1996 23:40:46 -0500 |
Organization: | Compilers Central |
References: | 96-02-165 96-02-193 |
Keywords: | storage, hardware, performance |
Andre Santos <alms@pesqueira.di.ufpe.br> writes:
> The cache behaviour plays a big role in the timings, and
> it is affected by far too many reasons (machine load, locality of
> other running processes etc.). The only solutions I know of are the
> two obvious ones:
[first solution deleted]
> - Use a simulator to count clock cycles (?). ...
> ... This way, in one go, you have a repeatable result.
Of course, it depends on how you plan to use the results. In
particular, if you are searching for an optimal solution to a problem
that is independent of the cache, then using a simulator that does not
model the cache is reasonable. However, if the cache significantly
affects or dominates the problem you are trying to solve, then a
simulator that does not model the cache will produce incorrect
repeatable results.
Regards,
Christopher Glaeser cdg@nullstone.com
--
Return to the
comp.compilers page.
Search the
comp.compilers archives again.