profiling with gprof

[joepistone]

Hi all. Here's my issue. I'm trying to profile a code I wrote, with gprof. The fact is that, in the flat profile, the most time expensive function is pow.L. Now I've no idea of what is this pow.L. Looking at the other functions reported in the flat profile, there are other functions that are not present in the code, like for exmple exp.L, sin.L, cos.N. What are this unexpected functions?
best regards.

[TimP]

Quoting - joepistone

Hi all. Here's my issue. I'm trying to profile a code I wrote, with gprof. The fact is that, in the flat profile, the most time expensive function is pow.L. Now I've no idea of what is this pow.L. Looking at the other functions reported in the flat profile, there are other functions that are not present in the code, like for exmple exp.L, sin.L, cos.N. What are this unexpected functions?
best regards.

Those functions are in the ifort math library. pow.L would implement exponentiation a**b. Presumably, you have scalar math functions in your source code or elsewhere.

[tracyx]

Quoting - joepistone

Hi all. Here's my issue. I'm trying to profile a code I wrote, with gprof. The fact is that, in the flat profile, the most time expensive function is pow.L. Now I've no idea of what is this pow.L. Looking at the other functions reported in the flat profile, there are other functions that are not present in the code, like for exmple exp.L, sin.L, cos.N. What are this unexpected functions?
best regards.

if you are calling these functions many times, it may be possible to structure your code so it can be vectorized and make use of SVML which may be a lot quicker.

[Alexis_R_]

Hi all,

I'm faced with same issue as the OP.
I wonder whether there's a neat trick to find out where the calls to pow.L are originating. I assume gprof is unable to do it because the ifort math library wasn't compiled with whatever gprof needs, but is there a way of quantifying where all the calls to pow.L come from in my code (other than staring at the code)?

Thanks

[rreis]

maybe

grep -n '\*\*' *f90 (it would identify lines with the construct ** )



you could also running it through valgrind, using the cachegrind tool (kcachegrind is a usefull visualizer for it's output)

[mriedman]

The trouble with gprof is that you can instrument your own code but you can't instrument the compiler libs. This is whyyou can't track the caller of such intrinsics.

You could try Oprofile instead of gprof. If you have a fairly recent version of Oprofile then you can generate a call graph that will show you wheremath intrinsics arecalled from.

In any case you may search for special exponents first and replace x**0.5 with sqrt(x) and x**1.5 with x*sqrt(x). The sqrt(x) is much faster than x**0.5

michael

[mriedman]

I gave it a try with Oprofile - no success. The call graph looks good for most parts of my test program. But for math intrinsics like pow(), exp(), log()itis unable tobacktrace the call stack to the caller.
While the caller calls symbol pow() thefinal destination symbolis pow.L() or pow.A() - obviouslythere is a jump in the assembly code somewhere and Oprofile can't associate the call with the real callee due to different symbol names and addresses.

[Ron_Green]

here's a real longshot but maybe worth a quick test. Try

-assume nounderscore

to compile everything. This removes the underscore decoration on Fortran symbols. This helps a lot of C-centrict tools work better with Fortran objects.

it's a longshot, but worth a try.

you could also try -nolib-inline to see if that makes any difference.

ron