This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: ping: [v2][PATCH] Framework for performance benchmarking of functions


On Thu, Jan 17, 2013 at 11:08 AM, Siddhesh Poyarekar
<siddhesh@redhat.com> wrote:
> On Thu, Jan 17, 2013 at 10:46:25AM -0600, Steven Munroe wrote:
>> On many platforms clock_gettime() still requires a system call, which is
>> swamp the measurement you are trying to make.
>>
>> You need to make sure there are enough iterations within the BENCH_FUCC
>> so that the clock_gettime(0 overhead is less then 1% of the total.
>>
>
> Oh yes, and that will make it difficult to measure fast paths in math
> functions (but do we need to measure them at all to begin with?).  The
> slow paths are currently slow enough that it's easy to have them
> running up to 30 seconds or so on a few million iterations.  That
> should cover the syscalls just fine.
>
> Siddhesh

Yes, the timestamp you fetch after every iteration of BENCH_FUNC, is
polluted with the time consumed in making the call to fetch the
timestamps.

In some cases this can be a different amount of time (depending on the
implementation of clock_gettime) per iteration (the first call perhaps
being more expensive, as in the case of using HP_TIMING on a platform
where the clock frequency has to be queried from the file system).

If you do a few thousand iterations between measurements and divide by
the number of iterations you'll amortize the cost of the timestamp
across all of the calls.

Ryan


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]