bogus timing calculation in gcrypts benchmark
tobiasu at tmux.org
Sun Mar 7 00:14:49 CET 2010
I've had a look at the catastrophic results of gcrypt on BSD systems
It turns out that this is due to a number of bugs in benchmark.c.
It uses CLOCKS_PER_SEC, which on BSD systems is the actual tick rate,
but on "XSI conformant" systems, it's always 1000000. (Have a look into
bits/time.h on a glibc system, the definition violates ANSI C...).
The second bug is the "ms" unit, I guess it should haven been "us".
If we assume that the unit is microseconds, then there's a 0 too many in
the scaling factor.
So here's a patch that should be as portable as it gets, with a sane
millisecond resolution. Tested on OpenBSD and Linux
PS: please CC
--- tests/benchmark.c.orig Thu Apr 2 11:25:34 2009
+++ tests/benchmark.c Sat Mar 6 23:40:05 2010
@@ -27,6 +27,7 @@
@@ -332,8 +333,9 @@
t = (t2 - t1)/10000;
snprintf (buf, sizeof buf, "%5.0fms", (double)t );
+ long ticks = sysconf(_SC_CLK_TCK);
snprintf (buf, sizeof buf, "%5.0fms",
- (((double) (stopped_at - started_at))/CLOCKS_PER_SEC)*10000000);
+ (((double) (stopped_at - started_at))/ticks)*1000);
More information about the Gcrypt-devel