|
| 1 | +Profiling |
| 2 | +--------- |
| 3 | + |
| 4 | +You should obtain profiling information before attempting any optimization of |
| 5 | +the code. There are many ways of obtaining this information, but we have only |
| 6 | +experimented with the following: |
| 7 | + |
| 8 | +#. Using Linux ``perf`` and related `tools <http://www.brendangregg.com/perf.html>`_. |
| 9 | +#. Using ``gperftools``. |
| 10 | +#. Using Intel VTune. |
| 11 | + |
| 12 | +Profiling should be done using the standalone executable ``run_pcm`` and any of |
| 13 | +the input files gathered under the ``tests/benchmark`` directory. These files |
| 14 | +are copied to the build directory. If you are lazy, you can run the profiling |
| 15 | +from the build directory: |
| 16 | + |
| 17 | +.. code-block:: bash |
| 18 | +
|
| 19 | + >>> cd tests/benchmark |
| 20 | +
|
| 21 | + >>> env PYTHONPATH=<build_dir>/lib64/python:$PYTHONPATH |
| 22 | + python <build_dir>/bin/go_pcm.py --inp=standalone.pcm --exe=<build_dir>/bin |
| 23 | +
|
| 24 | +Using ``perf`` |
| 25 | +============== |
| 26 | + |
| 27 | +``perf`` is a tool available on Linux. Though part of the kernel tools, it is |
| 28 | +not usually preinstalled on most Linux distributions. For visualization |
| 29 | +purposes we also need `additional tools <https://github.com/brendangregg/perf-tools>`_, |
| 30 | +in particular the `flame graph generation scripts <https://github.com/brendangregg/FlameGraph>`_ |
| 31 | +Probably your distribution has them prepackaged already. |
| 32 | +``perf`` will trace all CPU events on your system, hence you might need to |
| 33 | +fiddle with some kernel set up files to get permissions to trace events. |
| 34 | + |
| 35 | +.. note:: |
| 36 | + ``perf`` **is NOT** available on ``stallo``. Even if it were, you would |
| 37 | + probably not have permissions to record kernel traces. |
| 38 | + |
| 39 | +These are the instructions I used: |
| 40 | + |
| 41 | +1. Trace execution. This will save CPU stack traces to a ``perf.data`` file. |
| 42 | + Successive runs do not overwrite this file. |
| 43 | + |
| 44 | + .. code-block:: bash |
| 45 | +
|
| 46 | + >>> cd tests/benchmark |
| 47 | +
|
| 48 | + >>> perf record -F 99 -g -- env PYTHONPATH=<build_dir>/lib64/python:$PYTHONPATH python |
| 49 | + <build_dir>/bin/go_pcm.py --inp=standalone.pcm --exe=<build_dir>/bin |
| 50 | +
|
| 51 | +2. Get reports. There are different ways of getting a report from the |
| 52 | + ``perf.data`` file. The following will generate a call tree. |
| 53 | + |
| 54 | + .. code-block:: bash |
| 55 | +
|
| 56 | + >>> perf report --stdio |
| 57 | +
|
| 58 | +3. Generate an interactive flame graph. |
| 59 | + |
| 60 | + .. code-block:: bash |
| 61 | +
|
| 62 | + >>> perf script | stackcollapse-perf.pl > out.perf-folded |
| 63 | +
|
| 64 | + >>> cat out.perf-folded | flamegraph.pl > perf-run_pcm.svg |
| 65 | +
|
| 66 | +Using ``gperftools`` |
| 67 | +==================== |
| 68 | + |
| 69 | +This set of tools was previously known as Google Performance Tools. The |
| 70 | +executable needs to be linked against the ``profiler``, ``tcmalloc`` |
| 71 | +and ``unwind`` libraries. |
| 72 | +CMake will attempt to find them. If this fails, you will have to install them, |
| 73 | +you should either check if they are available for your distribution or compile |
| 74 | +from source. |
| 75 | +In principle, one could use the ``LD_PRELOAD`` mechanism to skip the *ad hoc* |
| 76 | +compilation of the executable. |
| 77 | + |
| 78 | +.. note:: |
| 79 | + ``gperftools`` **is** available on ``stallo``, but it's an ancient version. |
| 80 | + |
| 81 | +1. Configure the code with the ``--gperf`` option enabled. CPU and heap |
| 82 | + profiling, together with heap-checking will be available. |
| 83 | + |
| 84 | +2. CPU profiling can be done with the following command: |
| 85 | + |
| 86 | + .. code-block:: bash |
| 87 | +
|
| 88 | + >>> env CPUPROFILE=run_pcm.cpu.prof PYTHONPATH=<build_dir>/lib64/python:$PYTHONPATH |
| 89 | + python <build_dir>/bin/go_pcm.py --inp=standalone.pcm --exe=<build_dir>/bin |
| 90 | +
|
| 91 | + This will save the data to the ``run_pcm.cpu.prof`` file. To analyze the gathered |
| 92 | + data we can use the ``pprof`` script: |
| 93 | + |
| 94 | + .. code-block:: bash |
| 95 | +
|
| 96 | + >>> pprof --text <build_dir>/bin/run_pcm run_pcm.cpu.prof |
| 97 | +
|
| 98 | + This will print a table. Any row will look like the following: |
| 99 | + |
| 100 | + .. code-block:: bash |
| 101 | +
|
| 102 | + 2228 7.2% 24.8% 28872 93.4% pcm::utils::splineInterpolation |
| 103 | +
|
| 104 | + where the columns respectively report: |
| 105 | + |
| 106 | + #. Number of profiling samples in this function. |
| 107 | + #. Percentage of profiling samples in this function. |
| 108 | + #. Percentage of profiling samples in the functions printed so far. |
| 109 | + #. Number of profiling samples in this function and its callees. |
| 110 | + #. Percentage of profiling samples in this function and its callees. |
| 111 | + #. Function name. |
| 112 | + |
| 113 | + For more details look `here <https://gperftools.github.io/gperftools/cpuprofile.html>`_ |
| 114 | + |
| 115 | +3. Heap profiling can be done with the following command: |
| 116 | + |
| 117 | + .. code-block:: bash |
| 118 | +
|
| 119 | + >>> env HEAPPROFILE=run_pcm.hprof PYTHONPATH=<build_dir>/lib64/python:$PYTHONPATH |
| 120 | + python <build_dir>/bin/go_pcm.py --inp=standalone.pcm --exe=<build_dir>/bin |
| 121 | +
|
| 122 | + This will output a series of datafiles ``run_pcm.hprof.0000.heap``, |
| 123 | + ``run_pcm.hprof.0001.heap`` and so forth. You will have to kill execution |
| 124 | + when enough samples have been collected. |
| 125 | + Analysis of the heap profiling data can be done using ``pprof``. `Read more |
| 126 | + here <https://gperftools.github.io/gperftools/heapprofile.html>`_ |
| 127 | + |
| 128 | + |
| 129 | +Using Intel VTune |
| 130 | +================= |
| 131 | + |
| 132 | +This is probably the easiest way to profile the code. |
| 133 | +`VTune <https://software.intel.com/en-us/intel-vtune-amplifier-xe>`_ is Intel software, it might be possible to get a personal, free license. |
| 134 | +The instructions will hold on any machine where VTune is installed and you can |
| 135 | +look for more details on the `online documentation <https://software.intel.com/en-us/vtune-amplifier-help>`_ |
| 136 | +You can, in principle, use the GUI. I haven't managed to do that though. |
| 137 | + |
| 138 | +On ``stallo``, start an interactive job and load the following modules: |
| 139 | + |
| 140 | +.. code-block:: bash |
| 141 | +
|
| 142 | + >>> module load intel/2018a |
| 143 | +
|
| 144 | + >>> module load CMake |
| 145 | +
|
| 146 | + >>> module load VTune |
| 147 | +
|
| 148 | + >>> export BOOST_INCLUDEDIR=/home/roberto/Software/boost/include |
| 149 | +
|
| 150 | + >>> export BOOST_LIBRARYDIR=/home/roberto/Software/boost/lib |
| 151 | +
|
| 152 | +You will need to compile with optimizations activated, *i.e.* release mode. |
| 153 | +It is better to first parse the input file and then call ``run_pcm``: |
| 154 | + |
| 155 | +.. code-block:: bash |
| 156 | +
|
| 157 | + >>> cd <build_dir>/tests/benchmark |
| 158 | +
|
| 159 | + >>> env PYTHONPATH=../../lib64/python:$PYTHONPATH |
| 160 | + python ../../bin/go_pcm.py --inp=standalone_bubble.pcm |
| 161 | +
|
| 162 | +To start collecting hotspots: |
| 163 | + |
| 164 | +.. code-block:: bash |
| 165 | +
|
| 166 | + >>> amplxe-cl -collect hotspots ../../bin/run_pcm @standalone_bubble.pcm |
| 167 | +
|
| 168 | +VTune will generate a folder ``r000hs`` with the collected results. A report |
| 169 | +for the hotspots can be generated with: |
| 170 | + |
| 171 | +.. code-block:: bash |
| 172 | +
|
| 173 | + >>> amplxe-cl -report hotspots -r r000hs > report |
0 commit comments