[tor-relays] FreeBSD 13.1: clock_gettime(CLOCK_MONOTONIC_FAST) ~ 50 % performance gain

[Andreas Kempe]

On Tue, Jun 21, 2022 at 07:05:35PM +0200, Andreas Kempe wrote:
> With this being the case, this solves itself for FreeBSD 13.1. The
> system I was patching Tor on was a 13.0 system, I was convinced I had
> upgraded my VMs and never actually checked the version. 13.0 does not
> have the optimisation commit I dug out, but FAST was still 20x faster.
> I don't know if this is 13.0 specific, but since 13.0 is EoL soon, it
> might not matter that much.
> 
> On other systems I benchmarked 12.3 did not show any noticeable
> difference between the two, I could only see it for 13.1, but since
> they do not have identical hardware, I don't if that could come into
> play somehow.
> 
> > I suppose Tor could add #if !defined(CLOCK_MONOTONIC_COARSE) &&
> > defined(CLOCK_MONOTONIC_FAST) #define CLOCK_MONOTONIC_COARSE
> > CLOCK_MONOTONIC_FAST, but I'm not sure how useful that would be.
> > OpenBSD and NetBSD don't seem to define either. Perhaps something
> > like that would be appropriate for a FreeBSD ports patch.
> > 
> 
> I was contemplating a solution similar to this one, but thought it
> was ugly redefining a define so I used sed for my PoC to get a proper
> overview of where the actual changes ended up in the code.
> 
> I unfortunately don't have any other BSD flavours running where I
> could bench performance. If users of other BSD flavours have time to
> run the benchmark, it would be interesting to see the results for
> sure.
> 
> 

For completeness sake, I upgraded my VM to 13.1 and ran my benchmark
again. The slowdown of CLOCK_MONOTONIC compared to
CLOCK_MONOTONIC_FAST is now only about 3 times. 

Compiling Tor unpatched now also works right out of the box and I'm
not seeing a storm of system calls leading me to wonder whether this
was some weird VDSO issue.

Cordially,
Andreas Kempe