#1454 Use of getrusage() in Dune::Timer severely cripples performance of multi-threaded applications
Metadata
| Property | Value |
|---|---|
| Reported by | Steffen Persvold (sp@numascale.com) |
| Reported at | Apr 14, 2014 09:15 |
| Type | Bug Report |
| Version | 2.3 |
| Operating System | Linux |
| Last edited by | Markus Blatt (markus@dr-blatt.de) |
| Last edited at | May 22, 2014 08:19 |
| Closed by | Markus Blatt (markus@dr-blatt.de) |
| Closed at | May 22, 2014 08:19 |
| Closed in version | Unknown |
| Resolution | Fixed |
| Comment | Whith the supplied patch of Steffen. Thanks a lot. |
Description
When using the Dune::Timer class, it uses getrusage() on Unix platforms. getrusage() is a relatively "heavy" system call and includes a lot of kernel locking to get the necessary info (it reports a lot more than just time elapsed).
Hence using Dune::Timer in a multi-threaded OpenMP environment, especially with a large number of threads (32+) is really not feasible. dune-istl/paamg/fastamg.hh is an example of a user of Dune::Timer this could potentially be a "worker" in a multi-threaded application.
The attached patch changes Dune::Timer to use clock_gettime(CLOCK_MONOTONIC, ...) instead of getrusage(). Through defines it also allows for previous behaviour (TIMER_USE_GETRUSAGE).