From: Rob Landley <landley@trommello.org>
To: Alexei Podtelezhnikov <apodtele@mccammon.ucsd.edu>,
<linux-kernel@vger.kernel.org>
Subject: Re: VM: 2.4.10 vs. 2.4.10-ac2 and qsort()
Date: Thu, 4 Oct 2001 18:02:15 -0400 [thread overview]
Message-ID: <01100418021503.02393@localhost.localdomain> (raw)
In-Reply-To: <Pine.LNX.4.33.0110041618450.2582-100000@chemcca18.ucsd.edu>
In-Reply-To: <Pine.LNX.4.33.0110041618450.2582-100000@chemcca18.ucsd.edu>
On Thursday 04 October 2001 20:03, Alexei Podtelezhnikov wrote:
> Hi guys,
>
> I've already expressed my concern about using srand(1) in private e-mails.
> I think it's unscientific to use one particular random sequence. Since
> no one checked if that matters, I changed srand(1) to srand(time(NULL))
> and I'm posting my results. I don't do testing of Alan or Linus's kernels,
> but use recent Red Hat kernel. I think I've shown that it does matter.
One advantage of srand(1) is that it has a chance of being repeatable. You
don't WANT a truly random sequence, you want a sequence that simulates a
reproducable work load. That's why it makes sense to initialize the random
number generator with a known seed, so we can do it again after applying a
patch and see what kind of difference it made.
If you vary the initialization of the random number generator, your work load
isn't reproducible. It's the same TYPE of load, but not the same actual load
from one run to the next. If we're talking a 2% improvement expected out of
a particular tweak, you want to reduce random variation in the test case as
much as possible that might swamp your change. (We get enough variation
already from scheduling and random interrupts flushing cache state and
such...)
There's nothing wrong with using different seed values for srand, but testing
different VMs with different seed values has the possibility of being apples
to oranges.
If you want to run your test in a loop for a while to invoke statistics to
counter the randomness of your tests, you could do that too. But that's a
different kind of test. And one that's not nearly as convenient to run from
tweak to tweak...
Rob
next prev parent reply other threads:[~2001-10-05 2:02 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-10-05 0:03 VM: 2.4.10 vs. 2.4.10-ac2 and qsort() Alexei Podtelezhnikov
2001-10-04 22:02 ` Rob Landley [this message]
2001-10-05 3:55 ` Alexei Podtelezhnikov
[not found] <Pine.LNX.4.33.0110041618450.2582-100000@chemcca18.ucsd.edu >
2001-10-05 15:31 ` Lorenzo Allegrucci
[not found] <Pine.LNX.4.33L.0110011604310.4835-100000@imladris.rielhome .conectiva>
2001-10-01 18:33 ` Lorenzo Allegrucci
2001-10-01 19:23 ` Rik van Riel
2001-10-01 19:42 ` Alan Cox
2001-10-01 19:44 ` Rik van Riel
2001-10-01 20:35 ` Matthias Andree
2001-10-01 21:31 ` Daniel Phillips
2001-10-01 21:50 ` Lorenzo Allegrucci
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=01100418021503.02393@localhost.localdomain \
--to=landley@trommello.org \
--cc=apodtele@mccammon.ucsd.edu \
--cc=linux-kernel@vger.kernel.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 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.