Two follow-ups named in #996 that are worth doing separately rather than being forgotten.
The comparison takes 91 seconds and grows linearly
hyperion::differential scenarios_match_vanilla is flagged slow by nextest:
SLOW [> 60.000s] (───────) hyperion::differential scenarios_match_vanilla
PASS [ 91.226s] (465/465) hyperion::differential scenarios_match_vanilla
That is 100 world.progress() calls on a full HyperionCore world, for two
scenarios. Every scenario added costs its tick count again, and the whole point
of the design is that adding scenarios should be cheap. It is one test rather
than one per scenario because HyperionCore initialises rayon's global thread
pool and a second import panics, so this cannot simply be parallelised as it
stands.
Worth understanding where the per-tick cost goes before there are many more
scenarios.
Projectile state is f32, and the tolerance says so
Position and Velocity are glam::Vec3, so entity state is f32 while
vanilla's is double. That is the only remaining source of disagreement in the
differential traces, and it forces a position tolerance of 5e-4 blocks over 60
ticks.
The wire quantum for an entity position delta is 1/4096 of a block, about
2.4e-4, so on a long flight this is on the edge of being visible to a client
rather than being invisible rounding. Storing projectile state as f64 would
close it, at the cost of the cache locality the f32 choice was made for.
Neither is urgent. Both are the kind of thing that stops being findable once the
PR scrolls away.
See docs/differential-testing.md.
Filed by Claude.
Two follow-ups named in #996 that are worth doing separately rather than being forgotten.
The comparison takes 91 seconds and grows linearly
hyperion::differential scenarios_match_vanillais flagged slow by nextest:That is 100
world.progress()calls on a fullHyperionCoreworld, for twoscenarios. Every scenario added costs its tick count again, and the whole point
of the design is that adding scenarios should be cheap. It is one test rather
than one per scenario because
HyperionCoreinitialises rayon's global threadpool and a second import panics, so this cannot simply be parallelised as it
stands.
Worth understanding where the per-tick cost goes before there are many more
scenarios.
Projectile state is
f32, and the tolerance says soPositionandVelocityareglam::Vec3, so entity state isf32whilevanilla's is
double. That is the only remaining source of disagreement in thedifferential traces, and it forces a position tolerance of
5e-4blocks over 60ticks.
The wire quantum for an entity position delta is 1/4096 of a block, about
2.4e-4, so on a long flight this is on the edge of being visible to a clientrather than being invisible rounding. Storing projectile state as
f64wouldclose it, at the cost of the cache locality the
f32choice was made for.Neither is urgent. Both are the kind of thing that stops being findable once the
PR scrolls away.
See
docs/differential-testing.md.Filed by Claude.