This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [RFC] Porting string performance tests into benchtests
- From: David Miller <davem at davemloft dot net>
- To: roland at hack dot frob dot com
- Cc: siddhesh at redhat dot com, libc-alpha at sourceware dot org
- Date: Thu, 11 Apr 2013 17:41:15 -0400 (EDT)
- Subject: Re: [RFC] Porting string performance tests into benchtests
- References: <20130404033719 dot GA14860 at spoyarek dot pnq dot redhat dot com> <20130403 dot 234042 dot 1776194180184022553 dot davem at davemloft dot net> <20130411205335 dot 32E3D2C091 at topped-with-meat dot com>
From: Roland McGrath <roland@hack.frob.com>
Date: Thu, 11 Apr 2013 13:53:35 -0700 (PDT)
>> And on sparc chips I don't have the issues that can make the cpu cycle
>> counter inaccurate or less usable as a timing mechanism.
>
> On every machine it's a global counter and so it's subject to false
> accounting due to process scheduling. That's what CLOCK_THREAD_CPUTIME_ID
> avoids.
That's why you take many samples and weed out the outliers.
If you use CLOCK_THREAD_CPUTIME_ID, the cost of the measurement
exceeds the cost of the thing that you're measuring.
It is not appropriate for cycle level analysis of performance
critical assembler code.