From: Paul Zimmermann <Paul.Zimmermann@inria.fr>
To: libc-alpha@sourceware.org
Subject: improve documentation of the 'name' directive and the 'workload' mechanism
Date: Tue, 04 Aug 2020 13:31:34 +0200 [thread overview]
Message-ID: <mw4kpihckp.fsf@tomate.loria.fr> (raw)
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(-)
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:
==============
--
2.27.0
next reply other threads:[~2020-08-04 11:31 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-08-04 11:31 Paul Zimmermann [this message]
2020-08-04 16:49 ` Carlos O'Donell
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=mw4kpihckp.fsf@tomate.loria.fr \
--to=paul.zimmermann@inria.fr \
--cc=libc-alpha@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).