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: Siddhesh Poyarekar <siddhesh at redhat dot com>
- To: David Miller <davem at davemloft dot net>
- Cc: libc-alpha at sourceware dot org
- Date: Fri, 5 Apr 2013 10:08:01 +0530
- 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>
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