Thomas Munro <thomas.mu...@enterprisedb.com> writes: > On Tue, Dec 27, 2016 at 10:34 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: >> However, it seems that these impressive results date back only to >> June 2012, cf >> https://github.com/freebsd/freebsd/commit/13a9f42818f6b89a72b3e40923be809b490400d8 >> and at least as of that commit, only x86 and x86_64 had the fast >> clock_gettime code. Older FreeBSD, or FreeBSD on another architecture, >> is likely to be a lot worse. But I lack an installation to try.
> That commit is in every 'production' and 'legacy' release of > FreeBSD[1], meaning as far back as 9.3 (expected to be EoL in the next > few days), because it landed in 9.2 (EoL). I'm unclear on whether there's any significant number of people running out-of-support *BSD releases. If it's not something we have to worry about, fine. > That leaves the following architectures without > fast-path time functions: > macaque:freebsd munro$ git grep 'trivial-vdso_tc.c' > lib/libc/mips/sys/Makefile.inc:SRCS+= trivial-vdso_tc.c > lib/libc/powerpc/Makefile.inc:SRCS+= trivial-vdso_tc.c > lib/libc/powerpc64/Makefile.inc:SRCS+= trivial-vdso_tc.c > lib/libc/powerpcspe/Makefile.inc:SRCS+= trivial-vdso_tc.c > lib/libc/riscv/sys/Makefile.inc:SRCS+= trivial-vdso_tc.c > lib/libc/sparc64/Makefile.inc:SRCS+= trivial-vdso_tc.c Yeah, I just finished getting results from FreeBSD 10.3 on PPC (1.33GHz G4 laptop): gettimeofday takes about 1180 ns and clock_gettime about 1200 ns. That difference seems to be repeatable, but since it's only 2% I'm not too fussed about it. Interestingly, it's very easy to tell that it is entering the kernel, because time(1) shows a significant fraction of system time: $ time ./testclock 0 bogus readings 100000000 distinct readings 117.96 real 26.80 user 90.31 sys The same test on platforms with vDSO support shows zero system time. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers