Give each worker thread its own RNG seed, deterministically - #224
Open
pangwangshu wants to merge 1 commit into
Open
pangwangshu wants to merge 1 commit into
pangwangshu wants to merge 1 commit into
Conversation
Addresses correctness finding mimno#1 from mimno#219: ParallelTopicModel.estimate() constructed each thread's Randoms with the same --random-seed, so with a fixed seed all workers drew an identical stream of uniforms. Scope note: the report originally framed this as also improving model quality (paired t-test across 6 seeds, p < 0.05). mimno pushed back, asking whether workers seeing different questions made the shared stream harmless, and whether this change preserves run-to-run determinism. The follow-up analysis on the issue thread confirmed the coupling is real and measurable (worker decisions correlate: shared-seed phi = +0.29 to +0.35 vs independent-seed phi ~0.001-0.002 over 6M aligned draws), but the quality claim did not survive a corrected, unpaired significance test (12 seeds each, p ~= 0.066 -- not significant, 0/12 independent runs beat the best shared-seed run). So this is hygiene, not a quality fix: it removes a real, reproducible loss of independence between workers, not a correctness bug -- each draw was already a valid sample from its own conditional either way. To answer mimno's determinism question directly: each thread now gets a seed derived from (randomSeed, thread) via deriveWorkerSeeds(), a new small static method extracted specifically to be testable in isolation. It uses SplittableRandom purely as a seed generator (not as the sampler's RNG) because a plain randomSeed + thread risks correlated short streams -- java.util.Random's LCG has weak low-order bits and doesn't reliably decorrelate seeds that are close together, while SplittableRandom exists specifically to mint well-mixed sub-seeds from one seed. deriveWorkerSeeds is a pure function of (randomSeed, numThreads), so a fixed --random-seed and --num-threads still reproduce byte-identically. The single-thread code path (numThreads == 1) is untouched -- this only changes the numThreads > 1 branch -- so single-threaded output remains byte-identical, which TestParallelTopicModelRegression's existing pinned fingerprint (unmodified by this change) continues to confirm. Added TestParallelTopicModelWorkerSeeds: deriveWorkerSeeds is deterministic and produces distinct seeds per thread, and (the property mimno actually asked about) training the same 4-thread, fixed-seed configuration twice produces identical log likelihood and type-topic counts. No test in this codebase previously covered multi-threaded determinism at all -- the existing regression test pins numThreads=1 only. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
This branch has not been deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Part of #219 — correctness finding #1, "every worker thread gets the same RNG seed".
ParallelTopicModel.estimate()constructs each thread'sRandomsinside the per-thread loop withnew Randoms(randomSeed)— the same seed for every worker, so with--random-seedset all workers drew an identical stream of uniforms.@mimno's question on the issue was specifically: "I don't think it actually matters that the workers have the same random sequence... but it does seem a little cleaner. Is the run still deterministic over multiple workers with this change?" The follow-up discussion on the thread confirmed the coupling is real (correlated bucket decisions between workers, φ ≈ +0.29–0.35 vs ≈0.001–0.002 independent, over 6M aligned draws), but that the original claim of an LL improvement didn't hold up under a corrected significance test — so this is worth keeping as hygiene rather than a quality fix.
To answer the determinism question directly: each thread now gets a seed derived from
(randomSeed, thread)via a newderiveWorkerSeeds()static method, usingSplittableRandompurely as a seed generator (not the sampler's RNG, since a plainrandomSeed + threadrisks correlated seeds underjava.util.Random's LCG).deriveWorkerSeedsis a pure function of(randomSeed, numThreads), so a fixed--random-seedand--num-threadsstill reproduce byte-identically. The single-thread path is untouched.Added
TestParallelTopicModelWorkerSeeds:deriveWorkerSeedsis deterministic and produces distinct seeds per thread, and — the property actually asked about — training the same 4-thread, fixed-seed configuration twice produces identical log likelihood and type-topic counts. No test in this codebase previously covered multi-threaded determinism; the existing regression test pinsnumThreads=1only.