Re: compiler options for profiling machine instructions

[Paul Pluzhnikov]

Cindy Evelyn <cevlyn@gmail.com> writes:

> I'm looking for a tool or compiler options if any that can profile the
> machine instructions of a dynamic C/C++ program to see the behaviour of
> program given a parameter. Since the program is dynamic depending on

You are using the word 'dynamic' in a sense that is unfamiliar to me.

I think you mean that "the number of instructions and the path the
program takes depends on the program arguments". If so, that's true
for just about every non-trivial program in existence.

> the parameter given, i'd like to know the number of instructions
> (memory and non-memory) each in exact counts to know which
> instructions are executed the most.

Do you need to know 'which instructions are executed the most',
or do you need to know 'exact counts'?

The former is just regular profiling, which gprof or a
platform-specific profiler (e.g. tsprof (Linux/x86 www.bitwagon.com),
pixie (SGI Irix), Quantify (Solaris, HP-UX), etc.) are designed to
give you.

If the latter, and you are on Linux/x86, try 'valgrind --tool=cacheprof'.

> I have tried gprof, but gprof only counts the number of function
> calls. 

No, it doesn't "only count number of function calls". If it did,
it would be useless for profiling. It *also* measures how long each
function took, allowing you to zero-in on the execution slow spots.

> So, is there a way to profile during execution since the C/C++
> program is dynamic in order to get a complete profile of the machine
> instructions of the program?

It sounds to me that you are after simple "gprof" profile, but for
some reason decided that "gprof" didn't give you the right info,
when in fact it did. 

It is also possible that "gprof" in fact didn't give you the right
info, if your bottleneck is in a (shared) library that was not
compiled for profiling. But that is a fault with you, not with gprof.

Accurate application profiling is acutally quite difficult and is
a bit of a "black art". You should start by writing a couple of
trivial programs where you know what the slow spots are, and profile
them with "gprof". Once you understand how to correctly read
gprof output, you can then progress onto your real application.

Cheers,
-- 
In order to understand recursion you must first understand recursion.
Remove /-nsp/ for email.