tkonolige commented on a change in pull request #8817:
URL: https://github.com/apache/tvm/pull/8817#discussion_r695030314
##########
File path: src/tir/schedule/concrete_schedule.cc
##########
@@ -208,6 +211,25 @@ Schedule ConcreteScheduleNode::Copy() const {
}
/******** Schedule: Schedule: Sampling ********/
+
+void ConcreteScheduleNode::Seed(support::LinearCongruentialEngine::TRandState
seed) {
+ support::LinearCongruentialEngine(&rand_state_).Seed(seed == -1 ?
std::random_device()() : seed);
+}
+support::LinearCongruentialEngine::TRandState ConcreteScheduleNode::ForkSeed()
{
+ // In order for reproducibility, we computer the new seed using RNG's random
state and a different
+ // set of parameters. Note that both 32767 and 1999999973 are prime numbers.
+ return (support::LinearCongruentialEngine(&rand_state_)() * 32767) %
1999999973;
+}
Review comment:
@tqchen @junrushao1994 You both lay out a lot of interesting points
here, but I'm not sure I have the expertise to evaluate them. The PRNGS
themselves might appear simple, but analysis of their randomness is complicated
and non-intuitive. Looking at the paper I linked above, you can get subtle bugs
if the PRNG is used incorrectly. I've tested the LCG implemented in TVM with
some PRNG test suites (you can try it yourself here:
https://github.com/tkonolige/prng-tests), and it fails all of them. This result
is unsurprising because LCGs aren't particularly good random number generators,
but it just adds a little to my concern.
Given that we want to avoid any potential issues, why don't we just do
things the right way and use a splittable PRNG? This page
(https://www.pcg-random.org/posts/some-prng-implementations.html) lists some
implementations of PRNGs including SplitMix which is splittable. (pcg-random
appears to be a reputable source, it is run by the create of the PCG family of
PRNGS). It seems like there is basically no overhead to just dropping this
SplitMix implementation into the codebase. And then we won't have to worry
about any bugs due to bad randomness.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
