Re: any performance profiling tools ??

steve@blighty.com (Steve Atkins)
1 Oct 1997 23:45:45 -0400

          From comp.compilers

Related articles
any performance profiling tools ?? chunghsu@george.rutgers.edu (1997-09-23)
Re: any performance profiling tools ?? dccoote@werple.mira.net.au (1997-09-28)
Re: any performance profiling tools ?? everhart@gce.com (Glenn Everhart) (1997-09-30)
Re: any performance profiling tools ?? cfc@world.std.com (1997-10-01)
Re: any performance profiling tools ?? steve@blighty.com (1997-10-01)
Re: any performance profiling tools ?? ok@cs.rmit.edu.au (1997-10-02)
(fwd) Re: any performance profiling tools ?? koopman@cmu.edu (Philip Koopman) (1997-10-02)
Re: any performance profiling tools ?? sanjay@src.dec.com (1997-10-02)
Re: any performance profiling tools ?? jason@reflections.com.au (Jason Patterson) (1997-10-03)
| List of all articles for this month |

From: steve@blighty.com (Steve Atkins)
Newsgroups: comp.compilers,comp.arch,comp.benchmarks
Date: 1 Oct 1997 23:45:45 -0400
Organization: None
References: 97-09-084 97-09-119 97-09-126
Keywords: performance, testing

On 30 Sep 1997 16:29:13 -0400, Glenn Everhart <everhart@gce.com>
wrote:


>David Coote wrote:
>> [ re profiling tools ]


>My understanding of ATOM is that it works at the executable or object
>layer...not sure which offhand...so should work for basically anything
>that the loader understands. What ATOM does is global optimization and
>I believe some customization for particular alpha chip. I've heard of
>20% gains in execution speed through the thing, though YMMV as usual...


As I understand it ATOM is a general purpose code munger - it
lets you manipulate the final executable, allowing global
optimisation, profiling, instrumentation, most things. The global
optimisation phase of the Digital compiler is just one of the things
it's used for.


>[Do any of these address the original question about profiling at a low
>enough level to count cache misses and the like? -John]


Not directly, but it's possible to use atom to instrument an
executable, integrating it with a traditional simulator. This lets
you write cycle accurate architectural simulators that burn
through a lot of simulated cycles per second.


Nothing at all to do with SPARC though, which I think is where
this started. Anyone from Sun out there?


Cheers,
    Steve
--
-- Steve Atkins -- steve@blighty.com
--


Post a followup to this message

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