All of lore.kernel.org
 help / color / mirror / Atom feed
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

  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.