1.. _Timing: 2 3Timing 4====== 5 6 7When measuring the performance of parallel programs, it is usually *wall 8clock* time, not CPU time, that matters. The reason is that better 9parallelization typically increases aggregate CPU time by employing more 10CPUs. The goal of parallelizing a program is usually to make it run 11*faster* in real time. 12 13 14The class ``tick_count`` in |full_name| 15provides a simple interface for measuring wall clock time. A 16``tick_count`` value obtained from the static method tick_count::now() 17represents the current absolute time. Subtracting two ``tick_count`` 18values yields a relative time in ``tick_count::interval_t``, which you 19can convert to seconds, as in the following example: 20 21 22:: 23 24 25 tick_count t0 = tick_count::now(); 26 ... do some work ... 27 tick_count t1 = tick_count::now(); 28 printf("work took %g seconds\n",(t1-t0).seconds()); 29 30 31 32 33Unlike some timing interfaces, ``tick_count`` is guaranteed to be safe 34to use across threads. It is valid to subtract ``tick_count`` values 35that were created by different threads. A ``tick_count`` difference can 36be converted to seconds. 37 38 39The resolution of ``tick_count`` corresponds to the highest resolution 40timing service on the platform that is valid across threads in the same 41process. Since the CPU timer registers are *not* valid across threads on 42some platforms, this means that the resolution of tick_count can not be 43guaranteed to be consistent across platforms. 44 45 46.. note:: 47 48 On Linux\* OS, you may need to add -lrt to the linker command when 49 you use oneapi::tbb::tick_count class. For more information, see 50 `http://fedoraproject.org/wiki/Features/ChangeInImplicitDSOLinking 51 <http://fedoraproject.org/wiki/Features/ChangeInImplicitDSOLinking>`_. 52 53