It also works with Pytensor & PyMC!

The persistent caching part is what I would watch most closely, because Numba's on-disk cache has an invalidation rule that this environment can break completely silently.

Functions defined in a notebook cell are fine. The IPython locator stamps the cache with a sha256 of the cell source, so it is content addressed and nothing about the filesystem enters the check.

Functions inside installed packages are the ones to worry about. Those use the file backed locator, whose stamp is (st.st_mtime, st.st_size) of the .py file, and _load_index just returns an empty dict when the stamp does not match. The only trace is a _cache_log line nobody sees unless NUMBA_DEBUG_CACHE is set. So if a later session has its packages unpacked fresh by mamba, every recorded mtime is wrong on arrival, every cached compilation is silently thrown away, and the user simply experiences a slow notebook with cache=True dutifully set.

This is the same problem that led CPython to hash based .pyc in PEP 552, and the reason pip writes them: an installer cannot promise anything about the mtimes of the files it has just written, and a package manager unpacking into a browser filesystem is in exactly that position. The content addressed path already exists in Numba for the IPython case, so the pieces are there.

Worth measuring whether mtimes survive a mamba install into the persistent filesystem across sessions, because that answer decides whether cache=True does anything at all for the PyTensor and PyMC users, who are the ones with compilations expensive enough to care.

This is nice actually!

Are there some benchmarks of the browser vs non-browser version? I.e., what are the absolute numbers behind

> Numba delivers a roughly 250× speedup in WebAssembly, compared with about 90× natively.

Congrats for a serious engineering achievement!

I had experimented with a similar idea in an infinitely more primitive way more than ten years ago (https://cyrille.rossant.net/numpy-browser-llvm/). I'm glad to see so much progress since then.

This is awesome! For those here not familiar with Numba, it helps bridge that performance vs ergonomics tradeoff that's always existed when you reach for python over a lower level but faster lang like C or C++.

Sure you could write Cython but then you have to have a build step and make wheels for every platform you and python version. Sure numpy has gotten faster over the years but you're still hampered by the GIL.

Numba is a little magic because you get to write stuff that feels like numpy, but get literal bytecode perf.

BUT there's a cost to this, which u learned the hard way when I imported a color map extension for matplotlib recently.

I thought i was going to be importing a couple megabytes at most. But Numba+llvmlite alone is almost 100MB!

This might be a drop in the bucket in some applications but for a color map library that has only two hot paths that need to be JITed, it's excessive.

Overall though, love this achievement, and i love what's being done for in-browser (aka local-first) scientific computing!

jax in the browser on WebGPU next please?

This is awesome!! Another great addition to awsm-wasm!

Does this bring me closer to being able to run notebooks natively on my ipad?

Emscripten-forge looks like 32-bit.

I don't understand the article. It stresses that you don't need to run code on a Python server any more.

That assumes that the only option for scientists is to interact with the browser. Scientists used to be able to write Fortran and didn't rely on a crappy web interface. That was of course when they did science instead of blogging about tools.