From: Dan Kegel <dank@kegel.com>
To: Larry McVoy <lm@bitmover.com>
Cc: staelin@hpl.hp.com, linux-kernel@vger.kernel.org
Subject: Re: LMbench as gcc performance regression test?
Date: Sun, 31 Aug 2003 15:53:23 -0700 [thread overview]
Message-ID: <3F527C63.7090805@kegel.com> (raw)
In-Reply-To: <20030831145956.GE23783@work.bitmover.com>
Larry McVoy wrote:
> Here is some background, pick a benchmark and play with it and see if
> you can convince yourself of anything. The basic idea is to run the
> benchmark TRIES times for $ENOUGH milliseconds. TRIES is set to an odd
> number in bench.h because we sort the results and take the midpoint and
> print that as the result.
It seems lat_pipe never does any median smoothing; it always sets TRIES to 1.
However, at least on the fairly quiet embedded system I'm testing on,
smoothing samples taken within a single run wouldn't make
a huge difference. Any smoothing you get with that would be swamped by
the fact that lat_pipe's result has a bimodal distribution only one of whose
peaks shows up in any one run.
This sure sounds like the kind of thing page coloring is
supposed to solve; has anyone observed page coloring improving
the repeatability of the lat_pipe benchmark?
(There's no median smoothing in lat_pipe.c, I think, because it passes
a value >= 1000000 as the 2nd arg of BENCH:
BENCH(doit(p2[0], p1[1]), SHORT);
BENCH computes the number of samples to take the median of as
__N = (get_enough(1000000) <= 100000) ? TRIES : 1;
get_enough() will always return at least what it is passed,
thus __N will always be 1. It sure was whenever I printed it out, too.
This seems to be the case for the following tests:
bw_pipe bw_tcp bw_unix
lat_fcntl lat_fifo lat_pipe lat_rpc lat_tcp lat_udp lat_unix)
- Dan
--
Dan Kegel
http://www.kegel.com
http://counter.li.org/cgi-bin/runscript/display-person.cgi?user=78045
next prev parent reply other threads:[~2003-08-31 22:34 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-08-31 7:21 LMbench as gcc performance regression test? Dan Kegel
2003-08-31 14:00 ` Larry McVoy
2003-08-31 14:28 ` Dan Kegel
[not found] ` <3F520773.1070907@kegel.com>
[not found] ` <20030831145956.GE23783@work.bitmover.com>
2003-08-31 22:53 ` Dan Kegel [this message]
2003-08-31 15:24 ` Daniel Jacobowitz
2003-08-31 15:59 ` Dan Kegel
2003-08-31 16:18 ` Larry McVoy
2003-08-31 17:03 ` Martin J. Bligh
-- strict thread matches above, loose matches on Subject: below --
2003-08-31 16:57 rwhron
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=3F527C63.7090805@kegel.com \
--to=dank@kegel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=lm@bitmover.com \
--cc=staelin@hpl.hp.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.