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: Adhemerval Zanella <azanella at linux dot vnet dot ibm dot com>
- To: libc-alpha at sourceware dot org
- Date: Fri, 05 Apr 2013 16:44:13 -0300
- Subject: Re: [RFC] Porting string performance tests into benchtests
- References: <20130403101130 dot GE20842 at spoyarek dot pnq dot redhat dot com> <20130403 dot 123522 dot 1616212976811705615 dot davem at davemloft dot net> <20130404033719 dot GA14860 at spoyarek dot pnq dot redhat dot com> <20130403 dot 234042 dot 1776194180184022553 dot davem at davemloft dot net> <20130405043801 dot GR14860 at spoyarek dot pnq dot redhat dot com>
On 04/05/2013 01:38 AM, Siddhesh Poyarekar wrote:
> On Wed, Apr 03, 2013 at 11:40:42PM -0400, David Miller wrote:
>> I really want to see on the cpu cycle level whether the changes I make
>> to the pre-loop and post-loop code make any difference.
>>
>> 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.
> I realized that my understanding of CLOCK_PROCESS_CPUTIME_ID was
> flawed. While it is described as 'cpu time consumed by the process',
> it seems to still be sufficiently impacted by system load. Maybe the
> cost of switching gets added as well, I'm not sure. What I'll do now
> is see if HP_TIMING gives reasonably consistent results in the same
> conditions as CLOCK_PROCESS_CPUTIME_ID does and if it does, I'll
> modify the benchmark code to use it if available. If not, we fall
> back to CLOCK_PROCESS_CPUTIME_ID.
>
> Does that sound like a good plan?
>
> Siddhesh
>
For PowerPC I would prefer to use HP_TIMING, since it uses the timebase mechanism
and it have a higher resolution, does not require a a syscall or even a vDSO
access, and it is not susceptible to CPU scaling.
I'm not sure if it is worth, but maybe it would be useful to add a configurable
timestamp calculation. And related either timestamp way will be impacted by the
system lead at the time: os jitter should be controlled or minimized by the
tester to get good measurements.