This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PING] [PATCH] Preheat CPU in benchtests
- From: "Carlos O'Donell" <carlos at redhat dot com>
- To: OndÅej BÃlka <neleai at seznam dot cz>
- Cc: libc-alpha at sourceware dot org
- Date: Thu, 02 May 2013 21:34:04 -0400
- Subject: Re: [PING] [PATCH] Preheat CPU in benchtests
- References: <20130423061028 dot GA6257 at domone dot kolej dot mff dot cuni dot cz> <20130501192347 dot GA19748 at domone dot kolej dot mff dot cuni dot cz>
On 05/01/2013 03:23 PM, OndÅej BÃlka wrote:
>
> Ping,
>
> I need something like this for following patches. This is better than
> nothing until environment setting utility is implemented.
>
> OK to commit?
>
> On Tue, Apr 23, 2013 at 08:10:28AM +0200, OndÅej BÃlka wrote:
>> Hi,
>>
>> Benchmarks now are affected by cpu scaling when initialy run at low
>> frequency.
>>
>> Following benchmark runs nonsensial loop first to ensure that benchmark
>> are measured at maximal frequency. This greatly cuts time needed to
>> get accurate results.
>>
>
> ---
> benchtests/bench-skeleton.c | 9 +++++++++
> 1 files changed, 9 insertions(+), 0 deletions(-)
>
> diff --git a/benchtests/bench-skeleton.c b/benchtests/bench-skeleton.c
> index 7359184..2c728bf 100644
> --- a/benchtests/bench-skeleton.c
> +++ b/benchtests/bench-skeleton.c
> @@ -22,6 +22,8 @@
> #include <time.h>
> #include <inttypes.h>
>
> +volatile double dontoptimize = 0.0;
> +
> #define TIMESPEC_AFTER(a, b) \
> (((a).tv_sec == (b).tv_sec) ? \
> ((a).tv_nsec > (b).tv_nsec) : \
> @@ -32,6 +34,13 @@ main (int argc, char **argv)
> unsigned long i, k;
> struct timespec start, end, runtime;
>
Needs a comment explaining why we don't disable requency
scaling e.g. needs root (Andi Kleen's comment).
Needs a comment explaining future work around CPU_CLK_UNHALTED.
Needs a comment explaining why we run for a fixed number
of cycles instead of a fixed amount of time (Petr Baudis' comment).
> + /* This loop should cause CPU switch to maximal freqency. This makes
> + subsequent measurement more accurate. We need side effect to avoid loop
> + being deleted by compiler. */
> + for(k = 0; k < 1000000; k++)
> + dontoptimize += 23.0 * dontoptimize + 2.1;
> +
> +
Make it a function.
Can we avoid using the fpu here and avoid possible
double overflow? Does a volatile unsigned int work just
as well? If we need to heat the CPU and FPU
> memset (&runtime, 0, sizeof (runtime));
> memset (&start, 0, sizeof (start));
> memset (&end, 0, sizeof (end));
>
Cheers,
Carlos.