AuroraMiddleware/glibc
1
0
Fork 0
mirror of https://sourceware.org/git/glibc.git synced 2024-12-23 19:30:10 +00:00
Code Issues Packages Projects Releases Wiki Activity
bbf6e8e4f4
glibc/benchtests/bench-skeleton.c

111 lines
2.8 KiB
C
Raw Normal View History

Framework for performance benchmarking of functions See benchtests/Makefile to know how to use it.
2013-03-15 07:00:03 +00:00
/* Skeleton for benchmark programs.
Copyright (C) 2013 Free Software Foundation, Inc.
This file is part of the GNU C Library.
The GNU C Library is free software; you can redistribute it and/or
modify it under the terms of the GNU Lesser General Public
License as published by the Free Software Foundation; either
version 2.1 of the License, or (at your option) any later version.
The GNU C Library is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
Lesser General Public License for more details.
You should have received a copy of the GNU Lesser General Public
License along with the GNU C Library; if not, see
<http://www.gnu.org/licenses/>. */
#include <string.h>
#include <stdint.h>
#include <stdio.h>
#include <time.h>
#include <inttypes.h>
Use HP_TIMING for benchmarks if available HP_TIMING uses native timestamping instructions if available, thus greatly reducing the overhead of recording start and end times for function calls. For architectures that don't have HP_TIMING available, we fall back to the clock_gettime bits. One may also override this by invoking the benchmark as follows: make USE_CLOCK_GETTIME=1 bench and get the benchmark results using clock_gettime. One has to do `make bench-clean` to ensure that the benchmark programs are rebuilt.
2013-05-13 08:14:32 +00:00
#include "bench-timing.h"
Framework for performance benchmarking of functions See benchtests/Makefile to know how to use it.
2013-03-15 07:00:03 +00:00
Preheat CPU in benchtests. A benchmark could be skewed by CPU initialy working on minimal frequency and speeding up later. We first run code in loop to partialy fix this issue.
2013-05-08 06:21:05 +00:00
volatile unsigned int dontoptimize = 0;
Fix coding style
2013-05-10 12:14:27 +00:00
void
startup (void)
Preheat CPU in benchtests. A benchmark could be skewed by CPU initialy working on minimal frequency and speeding up later. We first run code in loop to partialy fix this issue.
2013-05-08 06:21:05 +00:00
{
/* This loop should cause CPU to switch to maximal freqency.
This makes subsequent measurement more accurate. We need a side effect
to prevent the loop being deleted by compiler.
This should be enough to cause CPU to speed up and it is simpler than
running loop for constant time. This is used when user does not have root
access to set a constant freqency. */
Fix coding style
2013-05-10 12:14:27 +00:00
for (int k = 0; k < 10000000; k++)
Preheat CPU in benchtests. A benchmark could be skewed by CPU initialy working on minimal frequency and speeding up later. We first run code in loop to partialy fix this issue.
2013-05-08 06:21:05 +00:00
dontoptimize += 23 * dontoptimize + 2;
}
Maintain runtime of each benchmark at ~10 seconds The idea to run benchmarks for a constant number of iterations is problematic. While the benchmarks may run for 10 seconds on x86_64, they could run for about 30 seconds on powerpc and worse, over 3 minutes on arm. Besides that, adding a new benchmark is cumbersome since one needs to find out the number of iterations needed for a sufficient runtime. A better idea would be to run each benchmark for a specific amount of time. This patch does just that. The run time defaults to 10 seconds and it is configurable at command line: make BENCH_DURATION=5 bench
2013-04-30 08:40:20 +00:00
#define TIMESPEC_AFTER(a, b) \
(((a).tv_sec == (b).tv_sec) ? \
((a).tv_nsec > (b).tv_nsec) : \
Allow multiple input domains to be run in the same benchmark program Some math functions have distinct performance characteristics in specific domains of inputs, where some inputs return via a fast path while other inputs require multiple precision calculations, that too at different precision levels. The way to implement different domains was to have a separate source file and benchmark definition, resulting in separate programs. This clutters up the benchmark, so this change allows these domains to be consolidated into the same input file. To do this, the input file format is now enhanced to allow comments with a preceding # and directives with two # at the begining of a line. A directive that looks like: tells the benchmark generation script that what follows is a different domain of inputs. The value of the 'name' directive (in this case, foo) is used in the output. The two input domains are then executed sequentially and their results collated separately. with the above directive, there would be two lines in the result that look like: func(): .... func(foo): ...
2013-04-30 08:47:57 +00:00
((a).tv_sec > (b).tv_sec))
Framework for performance benchmarking of functions See benchtests/Makefile to know how to use it.
2013-03-15 07:00:03 +00:00
int
main (int argc, char **argv)
{
Maintain runtime of each benchmark at ~10 seconds The idea to run benchmarks for a constant number of iterations is problematic. While the benchmarks may run for 10 seconds on x86_64, they could run for about 30 seconds on powerpc and worse, over 3 minutes on arm. Besides that, adding a new benchmark is cumbersome since one needs to find out the number of iterations needed for a sufficient runtime. A better idea would be to run each benchmark for a specific amount of time. This patch does just that. The run time defaults to 10 seconds and it is configurable at command line: make BENCH_DURATION=5 bench
2013-04-30 08:40:20 +00:00
unsigned long i, k;
Use HP_TIMING for benchmarks if available HP_TIMING uses native timestamping instructions if available, thus greatly reducing the overhead of recording start and end times for function calls. For architectures that don't have HP_TIMING available, we fall back to the clock_gettime bits. One may also override this by invoking the benchmark as follows: make USE_CLOCK_GETTIME=1 bench and get the benchmark results using clock_gettime. One has to do `make bench-clean` to ensure that the benchmark programs are rebuilt.
2013-05-13 08:14:32 +00:00
struct timespec runtime;
timing_t start, end;
Framework for performance benchmarking of functions See benchtests/Makefile to know how to use it.
2013-03-15 07:00:03 +00:00
Preheat CPU in benchtests. A benchmark could be skewed by CPU initialy working on minimal frequency and speeding up later. We first run code in loop to partialy fix this issue.
2013-05-08 06:21:05 +00:00
startup();
Maintain runtime of each benchmark at ~10 seconds The idea to run benchmarks for a constant number of iterations is problematic. While the benchmarks may run for 10 seconds on x86_64, they could run for about 30 seconds on powerpc and worse, over 3 minutes on arm. Besides that, adding a new benchmark is cumbersome since one needs to find out the number of iterations needed for a sufficient runtime. A better idea would be to run each benchmark for a specific amount of time. This patch does just that. The run time defaults to 10 seconds and it is configurable at command line: make BENCH_DURATION=5 bench
2013-04-30 08:40:20 +00:00
memset (&runtime, 0, sizeof (runtime));
Framework for performance benchmarking of functions See benchtests/Makefile to know how to use it.
2013-03-15 07:00:03 +00:00
Use HP_TIMING for benchmarks if available HP_TIMING uses native timestamping instructions if available, thus greatly reducing the overhead of recording start and end times for function calls. For architectures that don't have HP_TIMING available, we fall back to the clock_gettime bits. One may also override this by invoking the benchmark as follows: make USE_CLOCK_GETTIME=1 bench and get the benchmark results using clock_gettime. One has to do `make bench-clean` to ensure that the benchmark programs are rebuilt.
2013-05-13 08:14:32 +00:00
unsigned long iters;
Framework for performance benchmarking of functions See benchtests/Makefile to know how to use it.
2013-03-15 07:00:03 +00:00
Use HP_TIMING for benchmarks if available HP_TIMING uses native timestamping instructions if available, thus greatly reducing the overhead of recording start and end times for function calls. For architectures that don't have HP_TIMING available, we fall back to the clock_gettime bits. One may also override this by invoking the benchmark as follows: make USE_CLOCK_GETTIME=1 bench and get the benchmark results using clock_gettime. One has to do `make bench-clean` to ensure that the benchmark programs are rebuilt.
2013-05-13 08:14:32 +00:00
TIMING_INIT (iters);
Framework for performance benchmarking of functions See benchtests/Makefile to know how to use it.
2013-03-15 07:00:03 +00:00
Allow multiple input domains to be run in the same benchmark program Some math functions have distinct performance characteristics in specific domains of inputs, where some inputs return via a fast path while other inputs require multiple precision calculations, that too at different precision levels. The way to implement different domains was to have a separate source file and benchmark definition, resulting in separate programs. This clutters up the benchmark, so this change allows these domains to be consolidated into the same input file. To do this, the input file format is now enhanced to allow comments with a preceding # and directives with two # at the begining of a line. A directive that looks like: tells the benchmark generation script that what follows is a different domain of inputs. The value of the 'name' directive (in this case, foo) is used in the output. The two input domains are then executed sequentially and their results collated separately. with the above directive, there would be two lines in the result that look like: func(): .... func(foo): ...
2013-04-30 08:47:57 +00:00
for (int v = 0; v < NUM_VARIANTS; v++)
Framework for performance benchmarking of functions See benchtests/Makefile to know how to use it.
2013-03-15 07:00:03 +00:00
{
Allow multiple input domains to be run in the same benchmark program Some math functions have distinct performance characteristics in specific domains of inputs, where some inputs return via a fast path while other inputs require multiple precision calculations, that too at different precision levels. The way to implement different domains was to have a separate source file and benchmark definition, resulting in separate programs. This clutters up the benchmark, so this change allows these domains to be consolidated into the same input file. To do this, the input file format is now enhanced to allow comments with a preceding # and directives with two # at the begining of a line. A directive that looks like: tells the benchmark generation script that what follows is a different domain of inputs. The value of the 'name' directive (in this case, foo) is used in the output. The two input domains are then executed sequentially and their results collated separately. with the above directive, there would be two lines in the result that look like: func(): .... func(foo): ...
2013-04-30 08:47:57 +00:00
/* Run for approximately DURATION seconds. */
clock_gettime (CLOCK_MONOTONIC_RAW, &runtime);
runtime.tv_sec += DURATION;
Framework for performance benchmarking of functions See benchtests/Makefile to know how to use it.
2013-03-15 07:00:03 +00:00
Allow multiple input domains to be run in the same benchmark program Some math functions have distinct performance characteristics in specific domains of inputs, where some inputs return via a fast path while other inputs require multiple precision calculations, that too at different precision levels. The way to implement different domains was to have a separate source file and benchmark definition, resulting in separate programs. This clutters up the benchmark, so this change allows these domains to be consolidated into the same input file. To do this, the input file format is now enhanced to allow comments with a preceding # and directives with two # at the begining of a line. A directive that looks like: tells the benchmark generation script that what follows is a different domain of inputs. The value of the 'name' directive (in this case, foo) is used in the output. The two input domains are then executed sequentially and their results collated separately. with the above directive, there would be two lines in the result that look like: func(): .... func(foo): ...
2013-04-30 08:47:57 +00:00
double d_total_i = 0;
Use HP_TIMING for benchmarks if available HP_TIMING uses native timestamping instructions if available, thus greatly reducing the overhead of recording start and end times for function calls. For architectures that don't have HP_TIMING available, we fall back to the clock_gettime bits. One may also override this by invoking the benchmark as follows: make USE_CLOCK_GETTIME=1 bench and get the benchmark results using clock_gettime. One has to do `make bench-clean` to ensure that the benchmark programs are rebuilt.
2013-05-13 08:14:32 +00:00
timing_t total = 0, max = 0, min = 0x7fffffffffffffff;
Allow multiple input domains to be run in the same benchmark program Some math functions have distinct performance characteristics in specific domains of inputs, where some inputs return via a fast path while other inputs require multiple precision calculations, that too at different precision levels. The way to implement different domains was to have a separate source file and benchmark definition, resulting in separate programs. This clutters up the benchmark, so this change allows these domains to be consolidated into the same input file. To do this, the input file format is now enhanced to allow comments with a preceding # and directives with two # at the begining of a line. A directive that looks like: tells the benchmark generation script that what follows is a different domain of inputs. The value of the 'name' directive (in this case, foo) is used in the output. The two input domains are then executed sequentially and their results collated separately. with the above directive, there would be two lines in the result that look like: func(): .... func(foo): ...
2013-04-30 08:47:57 +00:00
while (1)
{
for (i = 0; i < NUM_SAMPLES (v); i++)
{
Use HP_TIMING for benchmarks if available HP_TIMING uses native timestamping instructions if available, thus greatly reducing the overhead of recording start and end times for function calls. For architectures that don't have HP_TIMING available, we fall back to the clock_gettime bits. One may also override this by invoking the benchmark as follows: make USE_CLOCK_GETTIME=1 bench and get the benchmark results using clock_gettime. One has to do `make bench-clean` to ensure that the benchmark programs are rebuilt.
2013-05-13 08:14:32 +00:00
uint64_t cur;
TIMING_NOW (start);
Allow multiple input domains to be run in the same benchmark program Some math functions have distinct performance characteristics in specific domains of inputs, where some inputs return via a fast path while other inputs require multiple precision calculations, that too at different precision levels. The way to implement different domains was to have a separate source file and benchmark definition, resulting in separate programs. This clutters up the benchmark, so this change allows these domains to be consolidated into the same input file. To do this, the input file format is now enhanced to allow comments with a preceding # and directives with two # at the begining of a line. A directive that looks like: tells the benchmark generation script that what follows is a different domain of inputs. The value of the 'name' directive (in this case, foo) is used in the output. The two input domains are then executed sequentially and their results collated separately. with the above directive, there would be two lines in the result that look like: func(): .... func(foo): ...
2013-04-30 08:47:57 +00:00
for (k = 0; k < iters; k++)
BENCH_FUNC (v, i);
Use HP_TIMING for benchmarks if available HP_TIMING uses native timestamping instructions if available, thus greatly reducing the overhead of recording start and end times for function calls. For architectures that don't have HP_TIMING available, we fall back to the clock_gettime bits. One may also override this by invoking the benchmark as follows: make USE_CLOCK_GETTIME=1 bench and get the benchmark results using clock_gettime. One has to do `make bench-clean` to ensure that the benchmark programs are rebuilt.
2013-05-13 08:14:32 +00:00
TIMING_NOW (end);
Framework for performance benchmarking of functions See benchtests/Makefile to know how to use it.
2013-03-15 07:00:03 +00:00
Use HP_TIMING for benchmarks if available HP_TIMING uses native timestamping instructions if available, thus greatly reducing the overhead of recording start and end times for function calls. For architectures that don't have HP_TIMING available, we fall back to the clock_gettime bits. One may also override this by invoking the benchmark as follows: make USE_CLOCK_GETTIME=1 bench and get the benchmark results using clock_gettime. One has to do `make bench-clean` to ensure that the benchmark programs are rebuilt.
2013-05-13 08:14:32 +00:00
TIMING_DIFF (cur, start, end);
Framework for performance benchmarking of functions See benchtests/Makefile to know how to use it.
2013-03-15 07:00:03 +00:00
Allow multiple input domains to be run in the same benchmark program Some math functions have distinct performance characteristics in specific domains of inputs, where some inputs return via a fast path while other inputs require multiple precision calculations, that too at different precision levels. The way to implement different domains was to have a separate source file and benchmark definition, resulting in separate programs. This clutters up the benchmark, so this change allows these domains to be consolidated into the same input file. To do this, the input file format is now enhanced to allow comments with a preceding # and directives with two # at the begining of a line. A directive that looks like: tells the benchmark generation script that what follows is a different domain of inputs. The value of the 'name' directive (in this case, foo) is used in the output. The two input domains are then executed sequentially and their results collated separately. with the above directive, there would be two lines in the result that look like: func(): .... func(foo): ...
2013-04-30 08:47:57 +00:00
if (cur > max)
max = cur;
Framework for performance benchmarking of functions See benchtests/Makefile to know how to use it.
2013-03-15 07:00:03 +00:00
Allow multiple input domains to be run in the same benchmark program Some math functions have distinct performance characteristics in specific domains of inputs, where some inputs return via a fast path while other inputs require multiple precision calculations, that too at different precision levels. The way to implement different domains was to have a separate source file and benchmark definition, resulting in separate programs. This clutters up the benchmark, so this change allows these domains to be consolidated into the same input file. To do this, the input file format is now enhanced to allow comments with a preceding # and directives with two # at the begining of a line. A directive that looks like: tells the benchmark generation script that what follows is a different domain of inputs. The value of the 'name' directive (in this case, foo) is used in the output. The two input domains are then executed sequentially and their results collated separately. with the above directive, there would be two lines in the result that look like: func(): .... func(foo): ...
2013-04-30 08:47:57 +00:00
if (cur < min)
min = cur;
Maintain runtime of each benchmark at ~10 seconds The idea to run benchmarks for a constant number of iterations is problematic. While the benchmarks may run for 10 seconds on x86_64, they could run for about 30 seconds on powerpc and worse, over 3 minutes on arm. Besides that, adding a new benchmark is cumbersome since one needs to find out the number of iterations needed for a sufficient runtime. A better idea would be to run each benchmark for a specific amount of time. This patch does just that. The run time defaults to 10 seconds and it is configurable at command line: make BENCH_DURATION=5 bench
2013-04-30 08:40:20 +00:00
Use HP_TIMING for benchmarks if available HP_TIMING uses native timestamping instructions if available, thus greatly reducing the overhead of recording start and end times for function calls. For architectures that don't have HP_TIMING available, we fall back to the clock_gettime bits. One may also override this by invoking the benchmark as follows: make USE_CLOCK_GETTIME=1 bench and get the benchmark results using clock_gettime. One has to do `make bench-clean` to ensure that the benchmark programs are rebuilt.
2013-05-13 08:14:32 +00:00
TIMING_ACCUM (total, cur);
Maintain runtime of each benchmark at ~10 seconds The idea to run benchmarks for a constant number of iterations is problematic. While the benchmarks may run for 10 seconds on x86_64, they could run for about 30 seconds on powerpc and worse, over 3 minutes on arm. Besides that, adding a new benchmark is cumbersome since one needs to find out the number of iterations needed for a sufficient runtime. A better idea would be to run each benchmark for a specific amount of time. This patch does just that. The run time defaults to 10 seconds and it is configurable at command line: make BENCH_DURATION=5 bench
2013-04-30 08:40:20 +00:00
Allow multiple input domains to be run in the same benchmark program Some math functions have distinct performance characteristics in specific domains of inputs, where some inputs return via a fast path while other inputs require multiple precision calculations, that too at different precision levels. The way to implement different domains was to have a separate source file and benchmark definition, resulting in separate programs. This clutters up the benchmark, so this change allows these domains to be consolidated into the same input file. To do this, the input file format is now enhanced to allow comments with a preceding # and directives with two # at the begining of a line. A directive that looks like: tells the benchmark generation script that what follows is a different domain of inputs. The value of the 'name' directive (in this case, foo) is used in the output. The two input domains are then executed sequentially and their results collated separately. with the above directive, there would be two lines in the result that look like: func(): .... func(foo): ...
2013-04-30 08:47:57 +00:00
d_total_i += iters;
}
struct timespec curtime;
Maintain runtime of each benchmark at ~10 seconds The idea to run benchmarks for a constant number of iterations is problematic. While the benchmarks may run for 10 seconds on x86_64, they could run for about 30 seconds on powerpc and worse, over 3 minutes on arm. Besides that, adding a new benchmark is cumbersome since one needs to find out the number of iterations needed for a sufficient runtime. A better idea would be to run each benchmark for a specific amount of time. This patch does just that. The run time defaults to 10 seconds and it is configurable at command line: make BENCH_DURATION=5 bench
2013-04-30 08:40:20 +00:00
Allow multiple input domains to be run in the same benchmark program Some math functions have distinct performance characteristics in specific domains of inputs, where some inputs return via a fast path while other inputs require multiple precision calculations, that too at different precision levels. The way to implement different domains was to have a separate source file and benchmark definition, resulting in separate programs. This clutters up the benchmark, so this change allows these domains to be consolidated into the same input file. To do this, the input file format is now enhanced to allow comments with a preceding # and directives with two # at the begining of a line. A directive that looks like: tells the benchmark generation script that what follows is a different domain of inputs. The value of the 'name' directive (in this case, foo) is used in the output. The two input domains are then executed sequentially and their results collated separately. with the above directive, there would be two lines in the result that look like: func(): .... func(foo): ...
2013-04-30 08:47:57 +00:00
memset (&curtime, 0, sizeof (curtime));
clock_gettime (CLOCK_MONOTONIC_RAW, &curtime);
if (TIMESPEC_AFTER (curtime, runtime))
goto done;
}
Framework for performance benchmarking of functions See benchtests/Makefile to know how to use it.
2013-03-15 07:00:03 +00:00
Allow multiple input domains to be run in the same benchmark program Some math functions have distinct performance characteristics in specific domains of inputs, where some inputs return via a fast path while other inputs require multiple precision calculations, that too at different precision levels. The way to implement different domains was to have a separate source file and benchmark definition, resulting in separate programs. This clutters up the benchmark, so this change allows these domains to be consolidated into the same input file. To do this, the input file format is now enhanced to allow comments with a preceding # and directives with two # at the begining of a line. A directive that looks like: tells the benchmark generation script that what follows is a different domain of inputs. The value of the 'name' directive (in this case, foo) is used in the output. The two input domains are then executed sequentially and their results collated separately. with the above directive, there would be two lines in the result that look like: func(): .... func(foo): ...
2013-04-30 08:47:57 +00:00
double d_total_s;
double d_iters;
Maintain runtime of each benchmark at ~10 seconds The idea to run benchmarks for a constant number of iterations is problematic. While the benchmarks may run for 10 seconds on x86_64, they could run for about 30 seconds on powerpc and worse, over 3 minutes on arm. Besides that, adding a new benchmark is cumbersome since one needs to find out the number of iterations needed for a sufficient runtime. A better idea would be to run each benchmark for a specific amount of time. This patch does just that. The run time defaults to 10 seconds and it is configurable at command line: make BENCH_DURATION=5 bench
2013-04-30 08:40:20 +00:00
Allow multiple input domains to be run in the same benchmark program Some math functions have distinct performance characteristics in specific domains of inputs, where some inputs return via a fast path while other inputs require multiple precision calculations, that too at different precision levels. The way to implement different domains was to have a separate source file and benchmark definition, resulting in separate programs. This clutters up the benchmark, so this change allows these domains to be consolidated into the same input file. To do this, the input file format is now enhanced to allow comments with a preceding # and directives with two # at the begining of a line. A directive that looks like: tells the benchmark generation script that what follows is a different domain of inputs. The value of the 'name' directive (in this case, foo) is used in the output. The two input domains are then executed sequentially and their results collated separately. with the above directive, there would be two lines in the result that look like: func(): .... func(foo): ...
2013-04-30 08:47:57 +00:00
done:
Use HP_TIMING for benchmarks if available HP_TIMING uses native timestamping instructions if available, thus greatly reducing the overhead of recording start and end times for function calls. For architectures that don't have HP_TIMING available, we fall back to the clock_gettime bits. One may also override this by invoking the benchmark as follows: make USE_CLOCK_GETTIME=1 bench and get the benchmark results using clock_gettime. One has to do `make bench-clean` to ensure that the benchmark programs are rebuilt.
2013-05-13 08:14:32 +00:00
d_total_s = total;
Allow multiple input domains to be run in the same benchmark program Some math functions have distinct performance characteristics in specific domains of inputs, where some inputs return via a fast path while other inputs require multiple precision calculations, that too at different precision levels. The way to implement different domains was to have a separate source file and benchmark definition, resulting in separate programs. This clutters up the benchmark, so this change allows these domains to be consolidated into the same input file. To do this, the input file format is now enhanced to allow comments with a preceding # and directives with two # at the begining of a line. A directive that looks like: tells the benchmark generation script that what follows is a different domain of inputs. The value of the 'name' directive (in this case, foo) is used in the output. The two input domains are then executed sequentially and their results collated separately. with the above directive, there would be two lines in the result that look like: func(): .... func(foo): ...
2013-04-30 08:47:57 +00:00
d_iters = iters;
Maintain runtime of each benchmark at ~10 seconds The idea to run benchmarks for a constant number of iterations is problematic. While the benchmarks may run for 10 seconds on x86_64, they could run for about 30 seconds on powerpc and worse, over 3 minutes on arm. Besides that, adding a new benchmark is cumbersome since one needs to find out the number of iterations needed for a sufficient runtime. A better idea would be to run each benchmark for a specific amount of time. This patch does just that. The run time defaults to 10 seconds and it is configurable at command line: make BENCH_DURATION=5 bench
2013-04-30 08:40:20 +00:00
Use HP_TIMING for benchmarks if available HP_TIMING uses native timestamping instructions if available, thus greatly reducing the overhead of recording start and end times for function calls. For architectures that don't have HP_TIMING available, we fall back to the clock_gettime bits. One may also override this by invoking the benchmark as follows: make USE_CLOCK_GETTIME=1 bench and get the benchmark results using clock_gettime. One has to do `make bench-clean` to ensure that the benchmark programs are rebuilt.
2013-05-13 08:14:32 +00:00
TIMING_PRINT_STATS (VARIANT (v), d_total_s, d_iters, d_total_i, max,
min);
Allow multiple input domains to be run in the same benchmark program Some math functions have distinct performance characteristics in specific domains of inputs, where some inputs return via a fast path while other inputs require multiple precision calculations, that too at different precision levels. The way to implement different domains was to have a separate source file and benchmark definition, resulting in separate programs. This clutters up the benchmark, so this change allows these domains to be consolidated into the same input file. To do this, the input file format is now enhanced to allow comments with a preceding # and directives with two # at the begining of a line. A directive that looks like: tells the benchmark generation script that what follows is a different domain of inputs. The value of the 'name' directive (in this case, foo) is used in the output. The two input domains are then executed sequentially and their results collated separately. with the above directive, there would be two lines in the result that look like: func(): .... func(foo): ...
2013-04-30 08:47:57 +00:00
}
Framework for performance benchmarking of functions See benchtests/Makefile to know how to use it.
2013-03-15 07:00:03 +00:00
return 0;
}
Reference in New Issue Copy Permalink