On Thu, 4 Oct 2001, Rob Landley wrote:
> 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.
I agree with this. All I was trying to show is that srand(1) makes it ONE
VERY PARTICULAR LOAD. Optimizing for this load doesn't make sense at all
because it is so particular. Optimizing for lower average make more sense.
That is what you would call TYPE of load. And the average is reproducible
statistically.
> 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.
>
Again, the averages and deviations are reproducible for each particular VM
algorithm, and provide a good comparison on this type of load. They are
the fruits.
Speaking of deviations, I was very surprised to see such a significant
deviation. I think we want it to be smaller. That is what we would call
predictability of a VM scheme. We need this quality, e.g. for predicting
the imminent OOM when possible. It would be interesting to compare these
too for Rik's and Andrea's schemes.
Lastly, I think this sort of simple tests can be adjusted to mimic some
certain interesting loads by cooking non-random sequences. This is
different from srand(1), because those sequences can make sense. That's
were the test becomes deterministic rather than statistical, and qsort()
becomes irrelevant too.
Alexei
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sun Oct 07 2001 - 21:00:35 EST