Deterministic construction

[RagnarGrootKoerkamp]

Currently the master seed is random, which maybe is not ideal?

[ilgrad]

Would use this. I looked at where the nondeterminism comes from, and it doesn't seem to be the master seed: that one is already fixed (ChaCha8Rng::seed_from_u64(31415) in compute_pilots, so retries also follow the same sequence). The only unseeded spot I found is fastrand::Rng::new() in build_part (build.rs:128), which picks the starting pilot when evicting.

Checked on 1.1.0: 50,000 dictionary words, default_compact, four builds — no two are byte-identical, even with one thread. Replacing that line with fastrand::Rng::with_seed(self.seed ^ (part as u64).wrapping_mul(0x9E3779B97F4A7C15)) made all builds byte-identical, also between 1 and 8 threads and across processes. The same line is on master.

If that approach works for you, I can send a one-line PR.

[RagnarGrootKoerkamp]

@ilgrad Looks like you already vendored ptrhash, or rather some mix of that and a bunch of other schemes we've been working on with the group? So I guess no more need then.

[ilgrad]

@RagnarGrootKoerkamp yes — 1.0 ships its own MPH, re-implemented from the PTHash line (buckets, one-byte pilots, remap), not vendored code. The reason was loader safety, not speed: with every array length in my own header, from_bytes and load_mmap can be safe fns — and it costs ~10x your build time (310 ns/key single-threaded vs your 32 on six). PtrHash is credited in my mphf module docs; I'll put it in the README too. Happy to close — and thanks for the 2.1.0 fix.

The one-line seed fix still stands if it's useful to anyone else.

[RagnarGrootKoerkamp]

Lol first you complain that V2 has slightly slower construction and now you have 10x slower instead of seeing if we can fix it here.

Anyway, I'm done talking through a Claude proxy.

[ilgrad]

Lol first you complain that V2 has slightly slower construction and now you have 10x slower instead of seeing if we can fix it here.

Anyway, I'm done talking through a Claude proxy.

@RagnarGrootKoerkamp fair point, thanks for the fix — closing from my side.

[RagnarGrootKoerkamp]

@RagnarGrootKoerkamp fair point, thanks for the fix

what did I fix? You're not making sense.

[ilgrad]

@RagnarGrootKoerkamp fair point, thanks for the fix

what did I fix? You're not making sense.

Sorry, that was unclear - I meant the out-of-bounds fix from #35.

[RagnarGrootKoerkamp]

See, that's why you should not let claude speak for you. You're just producing garbage.