No server, no C++ toolchain;
everything below happens in this tab, runs in the browser, samples on your machine.
stanc3 (OCaml→JS) compiles the model, stanli.wasm lowers it to an op graph and runs
Stan-dard Dynamic HMC, WALNUTS
or Pathfinder
— or a pair of them at once, side by side.
Surprised it was that quick?
Look ma, no compiles! Other Stan interfaces all lower your model to C++ and then use a system C++ compiler to build it,
which takes a minimum of 6 seconds for the smallest models even after the precompiled headers have been built.
Stanli has its own lowering and optimization passes that run in tens of milliseconds and then just interprets that high level result rather than using a compiler.
How
it works
Not just faster to start up, but usually faster gradients and sampling?? Median
2.07x CmdStan across
119 posteriordb models, with
100 of them at or above it. We benchmark every posteriordb model and explain why some are slower:
benchmarks .
The biggest architectural win is that Stanli analyzes the model graph and pre-allocates a linear array for gradient storage for everything except for ODE UDFs and conditionals on parameters.
The other graph optimizations are explained here .
This tab is the slow way to run Stanli, though. The same source
compiled to WebAssembly instead of native costs about 1.5x to 2x per
gradient. The figures in the paragraph
above are native ones, so the margin over CmdStan in here is nearer par
than 2x. For heavy work, pip install stanli to run the native build.
Numerically accurate and consistent with CmdStan
118/120 posteriordb models are
replayed against the log density, the full gradient and the generated
quantities CmdStan actually printed, and
44 agree to the last bit. Worst
disagreement anywhere is
2.6e-12 relative. Per-model results:
corpus
status .
Interested in learning more, or even contributing? Check out hacking.md :)