Re: performance measurement and caches

cdg@nullstone.com (Christopher Glaeser)
19 Feb 1996 23:40:46 -0500

          From comp.compilers

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)
| List of all articles for this month |

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
--


Post a followup to this message

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