Related articles |
---|
performance measurement and caches boehm@parc.xerox.com (1996-02-14) |
Re: performance measurement and caches Terje.Mathisen@hda.hydro.com (Terje Mathisen) (1996-02-16) |
Re: performance measurement and caches chase@centerline.com (1996-02-16) |
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: | grunwald@foobar.cs.colorado.edu (Dirk Grunwald) |
Newsgroups: | comp.compilers,comp.arch |
Date: | 17 Feb 1996 22:49:09 -0500 |
Organization: | University of Colorado |
References: | 96-02-165 96-02-195 |
Keywords: | performance, architecture |
Mary Fernandez <mff@research.att.com> writes:
> programs. Personally, I want to measure and to read about real
> elapsed-times, not simulated results.
Each has their place. Elapsed performance measurements for some
optimizations simply tell you that something is "slower" or "faster";
they don't often tell you why, unless you use performance monitoring
packages.
For example, an optimization may cause memory layout to change enough
that TLB thrashing occurs. Only knowing that something runs slower
doesn't help deduce the influence of the TLB - a TLB simulation would.
--
Return to the
comp.compilers page.
Search the
comp.compilers archives again.