Messages in this thread | | | Date | Tue, 27 Dec 2011 08:46:05 +0100 | From | Richard Cochran <> | Subject | Re: [PATCH 0/4] clock_gettime_ns and x86-64 optimizations |
| |
On Sun, Dec 25, 2011 at 08:50:59AM -0800, Andy Lutomirski wrote: > On x86-64, clock_gettime is so fast that the overhead converting to and > from nanoseconds is non-negligible. clock_gettime_ns is a different and > faster interface.
But your data contradict this statement. See below.
> Patch 1 adds the syscall and wires it up on x86-64. Patch 2 implements > the corresponding vdso entry on x86-64. Patch 3 optimizes the vdso > call, and patch 4 is a trivial change that speeds up the vdso > clock_gettime and clock_gettime_ns implementations. > > The vdso timings are (on an 800MHz Sandy Bridge mobile):
It would be more informative to describe how you made the measurements in more detail, for example, pseudo code, number of trials, min, max, mean, std. dev.
> Basic implementation: > > realtime 77.4ns > monotonic 79.2ns > realtime_coarse 18.1ns > monotonic_coarse 22.0ns
In order to better understand what you are reporting, I arranged your numbers into a table:
1. Basic implementation 2. Optimized implementation 3. Inlined (patch 4)
|---------------------+-------+-------+-------| | | 1. | 2. | 3. | |---------------------+-------+-------+-------| | realtime | 77.40 | 78.50 | 73.40 | | realtime_ns | 84.90 | 77.85 | 73.15 | |---------------------+-------+-------+-------| | monotonic | 79.20 | 77.40 | 72.10 | | monotonic_ns | 85.10 | 77.75 | 72.10 | |---------------------+-------+-------+-------| | realtime_coarse | 18.10 | 18.40 | 13.20 | | realtime_coarse_ns | 19.49 | 18.20 | 14.10 | |---------------------+-------+-------+-------| | monotonic_coarse | 22.00 | 19.40 | 15.80 | | monotonic_coarse_ns | 27.32 | 18.20 | 15.60 | |---------------------+-------+-------+-------|
Looking down column 3, it appears that the _ns calls are no faster than their plain counterparts.
So, while the inline patch does improve performance, the new _ns functions do not really seem worth the trouble.
Thanks, Richard
| |