[Gmp-commit] /home/hgfiles/gmp: Notes on linux timing

[mercurial at gmplib.org]

details:   /home/hgfiles/gmp/rev/630c72a64734
changeset: 13386:630c72a64734
user:      Niels M?ller <nisse at lysator.liu.se>
date:      Wed Jan 20 09:21:25 2010 +0100
description:
Notes on linux timing

diffstat:

 tune/README |  21 +++++++++++++++++++++
 1 files changed, 21 insertions(+), 0 deletions(-)

diffs (31 lines):

diff -r c7eba14828fd -r 630c72a64734 tune/README
--- a/tune/README	Wed Jan 20 00:23:08 2010 +0100
+++ b/tune/README	Wed Jan 20 09:21:25 2010 +0100
@@ -73,6 +73,27 @@
     running the speed program repeatedly then set a GMP_CPU_FREQUENCY
     environment variable (see TIME BASE section below).
 
+Timing on GNU/Linux
+
+    On Linux, timing currently uses the cycle counter. This is unreliable,
+    since the counter is not saved and restored at context switches (unlike
+    FreeBSD and Solaris where the cycle counter is "virtualized").
+
+    Using the clock_gettime method with CLOCK_PROCESS_CPUTIME_ID (posix) or
+    CLOCK_VIRTUAL (BSD) should be more reliable. To get clock_gettime
+    with glibc, one has to link with -lrt (which also drags in the pthreads
+    threading library). configure.in must be hacked to detect this and
+    arrange proper linking. Something like
+
+      old_LIBS="$LIBS"
+      AC_SEARCH_LIBS(clock_gettime, rt, [AC_DEFINE(HAVE_CLOCK_GETTIME)])
+      TUNE_LIBS="$LIBS"
+      LIBS="$old_LIBS"
+
+      AC_SUBST(TUNE_LIBS)
+    
+    might work.
+
 Low resolution timebase
 
     Parameter tuning can be very time consuming if the only timebase