09-16-2008 08:01 AM
The root executable will exec(1) other executables which will then call into the shared library.
Do I need to build EACH executable main program with +Oprofile=collect or does building just the root executable with profile collection enabled cause all subsequent callers of the shared library to collect profiling information within the shared library?
Solved! Go to Solution.
09-16-2008 11:20 AM
And then you use +Oprofile=use to recompile after collection your flow.data file(s).
09-16-2008 11:27 AM
When it finished, there were a bunch of flow.data.
Attempting to compile the shared library with +Oprofile=use and that flow.data file resulted in aCC errors complaining that flow.data was locked.
And, I am only trying to optimize the heavily travelled execution paths in my shared library, so I don't care if I don't have profiling information from EVERY executable that uses the shared library.
09-16-2008 11:48 AM
>When it finished, there were a bunch of flow.data.
What's in those flow.data.
>that flow.data file resulted in aCC errors complaining that flow.data was locked.
If the application is finished, you can remove the .lock files.
>I am only trying to optimize the heavily traveled execution paths in my shared library, so I don't care if I don't have profiling information from EVERY executable
Ok, that should work.
09-16-2008 11:55 AM
We definitely fork our executables. This is a parallel processing application. The flow.data.
Should I delete the temp files, append them to the flow.data file or what?
09-16-2008 07:38 PM
Then these probably have useful data in them.
I think you can remove these.
>There's also a flow.data.log file; it's full of complaints about ffw not being able to write to the flow.data file because it's locked.
Oh boy. Perhaps the log will tell you which are valid? And for which executable.
>Should I delete the temp files, append them to the flow.data file or what?
You probably need to merge them with the flow.data file, see fdm(1).
You probably want to create a new combined file:
fdm -o flow.data_BIG flow.data flow.data.
And use flow.data_BIG when recompiling:
09-17-2008 12:33 AM
The first thing that you can do to make your life easier is to take advantage of a feature that we call flow path qualifiers. When a +Oprofile=collect application finishes execution, it looks at the setting of the environment variable FLOW_DATA. If this "FLOW_DATA" set to a file name or path name, the +Oprofile=collect runtime will try to write the accumulated data to that file or path. You can also tack on the following additional qualifiers to your FLOW_DATA setting:
,per-process qualifies flow files with executable name
,unique qualifies flow files with process ID
Here is an example that should illustrate:
% /opt/ansic/bin/cc himom.c +Oprofile=collect -o first.exe
% cp first.exe second.exe
% setenv FLOW_DATA "myflow,per-process"
% ls -ltr myflow*
-rw-rw-r-- 1 me 0 May 13 13:48 myflow,per-process.err
-rw-rw-r-- 1 me 1700 May 13 13:48 myflow.first.exe
-rw-rw-r-- 1 me 1924 May 13 13:48 myflow.first.exe.log
-rw-rw-r-- 1 me 1700 May 13 13:48 myflow.second.exe
-rw-rw-r-- 1 me 2396 May 13 13:48 myflow.log
-rw-rw-r-- 1 me 1931 May 13 13:48 myflow.second.exe.log
% setenv FLOW_DATA "anotherflow,per-process,unique"
-rw-rw-r-- 1 me 0 May 13 13:50 anotherflow,per-process,unique.err
-rw-rw-r-- 1 me 1700 May 13 13:50 anotherflow.first.exe-22030
-rw-rw-r-- 1 me 1946 May 13 13:50 anotherflow.first.exe-22030.log
-rw-rw-r-- 1 me 1700 May 13 13:50 anotherflow.first.exe-22036
-rw-rw-r-- 1 me 1946 May 13 13:50 anotherflow.first.exe-22036.log
-rw-rw-r-- 1 me 3594 May 13 13:50 anotherflow.log
-rw-rw-r-- 1 me 1700 May 13 13:50 anotherflow.second.exe-22042
-rw-rw-r-- 1 me 1953 May 13 13:50 anotherflow.second.exe-22042.log
As Dennis suggests, you can merge the resulting flow files together after the fact, picking and choosing the things you are interested in. For example, if I know that "first.exe" is performance-critical and "second.exe" non-performance-critical, then I can select only the "first.exe" flow files for merging into my final destination.
With regard to locked flow files: the tools that create flow files will never intentionally leave a flow file locked; if you wind up with flow.data.lock files after the run is complete, then it means that something went wrong somewhere along the line (some process somewhere got interrupted or encountered an error during a flow.data update).
Let me know if this helps. There are other more arcane things you can try if this doesn't do the trick.
09-18-2008 07:44 AM
09-18-2008 02:55 PM
Have you looked into -ipo?
>It would be a good thing to extend the documentation in the user's guide to cover profiling shared libraries.
Which document was this?
aC++ Online Help:
Optimizing Itanium-based applications:
Linker: Profile-Based Optimization
09-19-2008 06:03 AM
As for the documentation, I was using the a.06.15 online users guide. I can't find ANY mention of unique or per-process in there, or of fdm, for that matter.
The 22% improvement exceeds my goal of 20%, so I'm satisfied at this point.