Split out of #738. Answers the question asked there: "can kdisco PR #52 be optimalisation?"
kDisco PR #52 (bedaHovorka/kdisco#52) bumps Kotlin 2.1.10 → 2.3.21, Gradle 8.12 → 8.14.5, Koin, JUnit,
coroutines. The question was whether the newer Kotlin/Native backend speeds up fast-sim — plausible,
since the hot path is ~1.85M tight numeric derivative evaluations (see #750).
Result: performance-neutral. Neither an optimisation nor a pessimisation.
Method: published PR #52's branch to mavenLocal as 0.6.0-k2321-SNAPSHOT, pointed a throwaway
interlockSim worktree at it, rebuilt the native linuxX64 release binary, measured
example shuntingLoop 300 (median of 7).
| kDisco build |
wall |
| 0.6.0, Kotlin 2.1.10 (current) |
341 ms |
| 0.6.0, Kotlin 2.3.21 (PR #52) |
349 ms |
Identical workload (5 trains, 211.1 s sim time). The 8 ms gap is inside this machine's run-to-run noise
(±7%; the same binary measured 307–329 ms and 336–348 ms across repeated batches). There is no measurable
performance difference in either direction.
Conclusion: merge PR #52 on toolchain-currency grounds whenever convenient — it neither helps nor hurts
fast-sim performance. It is not a lever for #750.
Caveat on scope: this rebuilds only the kDisco library with 2.3.21. The dominant hot code
(Train.Motor.derivatives) lives in interlockSim and is compiled by interlockSim's own Kotlin version.
Bumping interlockSim's toolchain could be evaluated separately, but given the RKF45 step-count problem
(#750) dominates by two orders of magnitude, codegen is not where the win is.
Acceptance
Split out of #738. Answers the question asked there: "can kdisco PR #52 be optimalisation?"
kDisco PR #52 (bedaHovorka/kdisco#52) bumps Kotlin
2.1.10 → 2.3.21, Gradle8.12 → 8.14.5, Koin, JUnit,coroutines. The question was whether the newer Kotlin/Native backend speeds up
fast-sim— plausible,since the hot path is ~1.85M tight numeric derivative evaluations (see #750).
Result: performance-neutral. Neither an optimisation nor a pessimisation.
Method: published PR #52's branch to
mavenLocalas0.6.0-k2321-SNAPSHOT, pointed a throwawayinterlockSim worktree at it, rebuilt the native
linuxX64release binary, measuredexample shuntingLoop 300(median of 7).Identical workload (5 trains, 211.1 s sim time). The 8 ms gap is inside this machine's run-to-run noise
(±7%; the same binary measured 307–329 ms and 336–348 ms across repeated batches). There is no measurable
performance difference in either direction.
Conclusion: merge PR #52 on toolchain-currency grounds whenever convenient — it neither helps nor hurts
fast-sim performance. It is not a lever for #750.
Caveat on scope: this rebuilds only the kDisco library with 2.3.21. The dominant hot code
(
Train.Motor.derivatives) lives in interlockSim and is compiled by interlockSim's own Kotlin version.Bumping interlockSim's toolchain could be evaluated separately, but given the RKF45 step-count problem
(#750) dominates by two orders of magnitude, codegen is not where the win is.
Acceptance