Re: [FFmpeg-devel] [PATCH 4/7] checkasm: use pointers for start/stop functions - Rémi Denis-Courmont

From: "Rémi Denis-Courmont" <remi@remlab.net>
To: FFmpeg development discussions and patches <ffmpeg-devel@ffmpeg.org>
Subject: Re: [FFmpeg-devel] [PATCH 4/7] checkasm: use pointers for start/stop functions
Date: Sat, 15 Jul 2023 11:25:53 +0300
Message-ID: <4497357.LvFx2qVVIh@basile.remlab.net> (raw)
In-Reply-To: <N_N_Pj5--3-9@lynne.ee>

Le lauantaina 15. heinäkuuta 2023, 11.05.51 EEST Lynne a écrit :
> Jul 14, 2023, 20:29 by remi@remlab.net:
> > This makes all calls to the bench start and stop functions via
> > function pointers. While the primary goal is to support run-time
> > selection of the performance measurement back-end in later commits,
> > this has the side benefit of containing platform dependencies in to
> > checkasm.c and out of checkasm.h.
> > ---
> > 
> >  tests/checkasm/checkasm.c | 33 ++++++++++++++++++++++++++++-----
> >  tests/checkasm/checkasm.h | 31 ++++---------------------------
> >  2 files changed, 32 insertions(+), 32 deletions(-)
> 
> Not sure I agree with this commit, the overhead can be detectable,
> and we have a lot of small functions with runtime a few times that
> of a null function call.

I don't think the function call is ever null. The pointers are left NULL only 
if none of the backend initialise. But then, checkasm will bail out and exit 
before we try to benchmark anything anyway.

As for the real functions, they always do *something*. None of them "just 
return 0".

> Can you store the function pointers out of the loop to reduce
> the derefs needed?

Taking just the two loads is out of the loop should be feasible but it seems a 
rather vain. You will still have the overhead of the indirect function call, 
the function, and most importantly in the case of Linux perf and MacOS kperf, 
the system calls.

The only way to avoid the indirect function calls are to use IFUNC (tricky and 
not portable), or to make horrible macros to spawn one bench loop for each 
backend.

In the end, I think we should rather aim for as constant time as possible, 
rather than as fast as possible, so that the nop loop can estimate the 
benchmarking overhead as well as possible. In this respect, I think it is 
actually marginally better *not* to cache the function pointers in local 
variables, which could end up spilled on the stack, or not, depending on local 
compiler optimisations for any given test case.

-- 
雷米‧德尼-库尔蒙
http://www.remlab.net/

_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".