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: Rich Felker <dalias at aerifal dot cx>
- To: Siddhesh Poyarekar <siddhesh at redhat dot com>
- Cc: David Miller <davem at davemloft dot net>, libc-alpha at sourceware dot org
- Date: Fri, 5 Apr 2013 11:58:14 -0400
- 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 Fri, Apr 05, 2013 at 10:08:01AM +0530, 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
Of course it will be impacted. If you have other processes competing
for resources, you're going to have a lot more cache misses, TLB
misses, and maybe even page faults (not sure if the latter count for
this clock though).
Rich