From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Hannu Krosing <hannuk(at)google(dot)com> |
Cc: | Peter Eisentraut <peter(at)eisentraut(dot)org>, "Andrey M(dot) Borodin" <x4mmm(at)yandex-team(dot)ru>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: What is a typical precision of gettimeofday()? |
Date: | 2024-07-02 17:20:14 |
Message-ID: | 3112460.1719940814@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
BTW, getting back to the original point of the thread: I duplicated
Hannu's result showing that on Apple M1 the clock tick seems to be
about 40ns. But look at what I got with the v2 patch on my main
workstation (full output attached):
$ ./pg_test_timing
...
Per loop time including overhead: 16.60 ns
...
Timing durations less than 128 ns:
ns % of total running % count
15 3.2738 3.2738 5914914
16 49.0772 52.3510 88668783
17 36.4662 88.8172 65884173
18 9.5639 98.3810 17279249
19 1.5746 99.9556 2844873
20 0.0416 99.9972 75125
21 0.0004 99.9976 757
...
It sure looks like this is exact-to-the-nanosecond results,
since the modal values match the overall per-loop timing,
and there are no zero measurements.
This is a Dell tower from 2021, running RHEL8 on an Intel Xeon W-2245.
Not exactly top-of-the-line stuff.
regards, tom lane
Attachment | Content-Type | Size |
---|---|---|
pg_test_timing.results.txt | text/plain | 4.3 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2024-07-02 17:24:44 | Re: On disable_cost |
Previous Message | Heikki Linnakangas | 2024-07-02 17:16:19 | Re: Set appropriate processing mode for auxiliary processes. |