mojojojo
Research
Notes from building a service that runs other people's Python fast. Two threads: containment — how untrusted code shares a compile cache without sharing a process — and speed — where compiling Python to Mojo pays, where it does not, and how early we can tell.
Everything here is measured on the machine that serves this page and says so. The engine is mojosub, which is open source; its own lab notebook is docs/research.md.
There is no compiler in the sandbox
How a multi-tenant service shares a compile cache without letting one tenant put code in another tenant's process — and the four isolation bugs we shipped and fixed on the way there.
Read →How early do we know it has to be CPython?
Most submitted Python cannot be compiled, and finding that out late costs five seconds of somebody else's compiler. Measuring the pipeline against a labelled corpus, and the static filter that came out of it.
Read →Converting Python to Mojo, with an agent for the rest
A transpiler that follows rules can be trusted and refuses most code; an agent converts anything and can be trusted about nothing. So the agent's output goes through the same gate — compile, compare against CPython, measure. Plus what fuzzing the transpiler found.
Read →The copy nobody needed
Compiled Mojo was slower than CPython on a million-element list. More than half of that was a copy back the kernel had provably not earned — plus three name-collision bugs found by reading compiler stderr.
Read →What we will not write about
Nothing here is a benchmark of somebody else's product. mojosub
competes with the CPython interpreter, not with BLAS — a hand-written Mojo loop
loses to np.dot and we say so in the posts rather than
picking kernels where it does not. Where a measurement went against the design,
the post is about that.