improve documentation of the 'name' directive and the 'workload' mechanism

Message ID mw4kpihckp.fsf@tomate.loria.fr
State New
Headers show
Series
  • improve documentation of the 'name' directive and the 'workload' mechanism
Related show

Commit Message

Paul Zimmermann Aug. 4, 2020, 11:31 a.m.
Hi,

here is a patch improving the 'name' directive and the 'workload' mechanism
(for "make bench"). Feedback is welcome. I will submit separately later on
some new workload traces for sin, exp, pow, sinf128, expf128, powf128.

Paul Zimmermann

From b8ff91bf0bfb26114d1b4e5d30f210f41a4ff58d Mon Sep 17 00:00:00 2001
From: Paul Zimmermann <Paul.Zimmermann@inria.fr>

Date: Tue, 4 Aug 2020 13:27:39 +0200
Subject: [PATCH] improve documentation of the 'name' directive and the
 'workload' mechanism

---
 benchtests/README | 20 ++++++++++++++------
 1 file changed, 14 insertions(+), 6 deletions(-)

-- 
2.27.0

Comments

Vitaly Buka via Libc-alpha Aug. 4, 2020, 4:49 p.m. | #1
On 8/4/20 7:31 AM, Paul Zimmermann wrote:
>        Hi,

> 

> here is a patch improving the 'name' directive and the 'workload' mechanism

> (for "make bench"). Feedback is welcome. I will submit separately later on

> some new workload traces for sin, exp, pow, sinf128, expf128, powf128.

> 

> Paul Zimmermann


Paul,

This looks good and I've pushed this for glibc 2.32. Thanks.

Reviewed-by: Carlos O'Donell <carlos@redhat.com>


> From b8ff91bf0bfb26114d1b4e5d30f210f41a4ff58d Mon Sep 17 00:00:00 2001

> From: Paul Zimmermann <Paul.Zimmermann@inria.fr>

> Date: Tue, 4 Aug 2020 13:27:39 +0200

> Subject: [PATCH] improve documentation of the 'name' directive and the

>  'workload' mechanism

> 

> ---

>  benchtests/README | 20 ++++++++++++++------

>  1 file changed, 14 insertions(+), 6 deletions(-)

> 

> diff --git a/benchtests/README b/benchtests/README

> index f440f3295a..44736d7e63 100644

> --- a/benchtests/README

> +++ b/benchtests/README

> @@ -125,17 +125,25 @@ math functions perform computations at different levels of precision (64-bit vs

>  performance of these functions.  One could separate inputs for these domains in

>  the same file by using the `name' directive that looks something like this:

>  

> -  ##name: 240bit

> +  ##name: 240bits

>  

> -See the pow-inputs file for an example of what such a partitioned input file

> -would look like.

> +All inputs after the ##name: 240bits directive and until the next `name'

> +directive (or the end of file) are part of the "240bits" benchmark and

> +will be output separately in benchtests/bench.out.  See the pow-inputs file

> +for an example of what such a partitioned input file would look like.

>  

> -It is also possible to measure throughput of a (partial) trace extracted from

> -a real workload.  In this case the whole trace is iterated over multiple times

> -rather than repeating every input multiple times.  This can be done via:

> +It is also possible to measure latency and reciprocal throughput of a

> +(partial) trace extracted from a real workload.  In this case the whole trace

> +is iterated over multiple times rather than repeating every input multiple

> +times.  This can be done via:

>  

>    ##name: workload-<name>

>  

> +where <name> is simply used to distinguish between different traces in the

> +same file.  To create such a trace, you can simply extract using printf()

> +values uses for a specific application, or generate random values in some

> +interval.  See the expf-inputs file for an example of this workload mechanism.

> +

>  Benchmark Sets:

>  ==============

>  

> 



-- 
Cheers,
Carlos.

Patch

diff --git a/benchtests/README b/benchtests/README
index f440f3295a..44736d7e63 100644
--- a/benchtests/README
+++ b/benchtests/README
@@ -125,17 +125,25 @@  math functions perform computations at different levels of precision (64-bit vs
 performance of these functions.  One could separate inputs for these domains in
 the same file by using the `name' directive that looks something like this:
 
-  ##name: 240bit
+  ##name: 240bits
 
-See the pow-inputs file for an example of what such a partitioned input file
-would look like.
+All inputs after the ##name: 240bits directive and until the next `name'
+directive (or the end of file) are part of the "240bits" benchmark and
+will be output separately in benchtests/bench.out.  See the pow-inputs file
+for an example of what such a partitioned input file would look like.
 
-It is also possible to measure throughput of a (partial) trace extracted from
-a real workload.  In this case the whole trace is iterated over multiple times
-rather than repeating every input multiple times.  This can be done via:
+It is also possible to measure latency and reciprocal throughput of a
+(partial) trace extracted from a real workload.  In this case the whole trace
+is iterated over multiple times rather than repeating every input multiple
+times.  This can be done via:
 
   ##name: workload-<name>
 
+where <name> is simply used to distinguish between different traces in the
+same file.  To create such a trace, you can simply extract using printf()
+values uses for a specific application, or generate random values in some
+interval.  See the expf-inputs file for an example of this workload mechanism.
+
 Benchmark Sets:
 ==============