- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
best regards.
Link Copied
7 Replies
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
best regards.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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)
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
-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
Reply
Topic Options
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page