3
$\begingroup$

I'm a PhD working in the mechanical engineering community. I constantly use open-source FEM libraries to solve my problems. Up to now I didn't really care about the performance of my codes, mainly because I rely on external C++ libraries and I know/assume that the core features were highly optimised. Just to make a popular example, one of the libraries I use is deal.II.

I've seen (please correct me if I'm wrong) that people in FEM community are using Valgrind + Callgrind in order to visualise how much time the program spends in various places in the program (see also here for an example https://www.dealii.org/developer/doxygen/deal.II/step_22.html#Performanceoptimizations).

My problem is that I don't have a Linux machine, but a Mac (Monterey). The huge problem is that Valgrind is not natively supported for MacOS, and the brew version is not working on my machine. I've found and tried the "built-in" Instruments (https://en.wikipedia.org/wiki/Instruments_(software) and I easily got the same level of information shown in the picture of the first link with KCachegrind.

Does anybody know how people in scientific computing do profiling on a MacOS? Does anybody know if Instruments is really used, or there are better/standard alternatives?

Improve this question
$\endgroup$
2
  • 2
    $\begingroup$ Since you already found the discussion in step-22, I would also point to the TimerOutput class used in programs such as step-40 to get an overview of which components of a program take substantial amounts of time, and could use some optimization. $\endgroup$
    – Wolfgang Bangerth
    Commented Jan 4, 2023 at 18:58
  • $\begingroup$ One thing to consider is the same software on different OSes and different hardware can have quite different performance characteristics. I would suggest doing any profiling on as similar a system as possible to wherever you're going to run "in production" (e.g. if you're running on a cluster, see if you can profile on it). $\endgroup$
    – James Tocknell
    Commented Jan 13, 2023 at 8:46

1 Answer 1

Reset to default
5
$\begingroup$

One way to approach this would be to record the performance information on your machine (compile with -pg (gprof) compiler option), run your program like you normally would, and write that data to a file (progname.gmon). You may then inspect the recorded data on another machine. This is the approach one may use when profiling on a remote cluster anyway. There exists a number of programs that can read the .gprof profiling data even if you do not use the native GCC tool.

Another way is to think deep about which parts of your program will be relevant to performance analysis and do some benchmarking yourself in the form of recording runtimes of the routines. This is a lot more hands-on and some people here will call it unprofessional, but usually your bottleneck comes down to a region of code that spans only a couple of lines..

I would also advise to not fall in the trap of spending more time in code optimization than can be reasonably gained. Optimizing the runtime speed of a program has diminishing returns. One may easily spend a person-month on gaining another 20% runtime speed for a simulation that will be run 10 times.

Improve this answer
$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.