public inbox for glibc-cvs@sourceware.org
help / color / mirror / Atom feed
From: Carlos O'Donell <carlos@sourceware.org>
To: glibc-cvs@sourceware.org
Subject: [glibc] benchtests/README update.
Date: Tue,  4 Aug 2020 23:53:25 +0000 (GMT)	[thread overview]
Message-ID: <20200804235325.5906C3858D37@sourceware.org> (raw)

https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=50a8dd367e305bb6c6146c564fd48c193cc94069

commit 50a8dd367e305bb6c6146c564fd48c193cc94069
Author: Paul Zimmermann <Paul.Zimmermann@inria.fr>
Date:   Tue Aug 4 13:27:39 2020 +0200

    benchtests/README update.
    
    Improve documentation of the 'name' directive and the 'workload' mechanism.
    
    Reviewed-by: Carlos O'Donell <carlos@redhat.com>

Diff:
---
 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:
 ==============


                 reply	other threads:[~2020-08-04 23:53 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200804235325.5906C3858D37@sourceware.org \
    --to=carlos@sourceware.org \
    --cc=glibc-cvs@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).