Changes between Version 1 and Version 2 of Documentation/UserGuide/ProfileValgrind

Timestamp:

2019-09-19T11:01:33+02:00 (5 years ago)

Author:

mmcgrath

Comment:

--

Documentation/UserGuide/ProfileValgrind

@@ -1 @@
-Once you have a working model, it can be helpful to profile it to see where it's taking a lot of time.  It doesn't make sense to optimize parts of the code which only run for 0.001% of the time and leave something un-optimized which runs for 10% of the total runtime.  Here is an introduction of how to profile using valgrind, which is installed on obelix.
+Once you have a working model, it can be helpful to profile it to see where it's taking a lot of time.  It doesn't make sense to optimize parts of the code which only run for 0.001% of the time and leave something un-optimized which runs for 10% of the total runtime.  Here is an introduction of how to profile using valgrind, which is installed on both obelix and Irene (module load valgrind).
 
 The first step is to compile with the proper options.  It's good to compile a production executable, although use of some debug flags will automatically remove optimization.  Still, I compile with the following in modeles/ORCHIDEE/arch.fcm
@@ -15 +15 @@
 since it appears that IOIPSL uses this line to create the makefiles.  Then ins_make with the -prod option in config/ORCHIDEE_OL/AA_make.  Notice the -fno-inline-functions command.  If you inline functions, it makes your code faster, but you also lose line information.  Since we would like to see which lines are taking the most time, it's good to disable inlining.
 
-Once you have done this, you need to run ORCHIDEE without using libIGCM.  You can find that information elsewhere on the wiki.  I create a run.def for a single pixel but multiple years.  At the beginning of the run, there is a lot of overhead involved in doing other tasks, so we want to add as much computation as possible in sechiba and stomate and not so much in interpolating maps (unless that is what you are trying to profile, of course).
+Once you have done this, you need to run ORCHIDEE without using libIGCM.  You can find that information elsewhere on the wiki.  I create a run.def for a single pixel but multiple years.  At the beginning of the run, there is a lot of overhead involved in doing other tasks, so we want to add as much computation as possible in sechiba and stomate and not so much in interpolating maps (unless that is what you are trying to profile, of course).  I also turn off (or minimize) writing history files, since file I/O also takes a lot of time.
 
 This method is expensive.  Very expensive.  A good rule of thumb seems to be to multiply the expected optimized runtime by a factor of 100.  So if it takes 30 seconds to run your run.def normally, it will take an hour with valgrind.  This is because valgrind collects a lot of information instead of just doing random sampling like many profilers.  I use a submission file for obelix like the following: