Numba in the Browser: Unlocking a New Scientific Python Stack in JupyterLite
notebook.link
notebook.link
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!
I'd stick with the venv if it's heavy duty crunching and you do it often.
However, if this is a one off or doesn't need heavy compute, and you don't mind waiting a little longer, use the notebook.link.
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.
> Numba delivers a roughly 250× speedup in WebAssembly, compared with about 90× natively.
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.
It's not the only option but jupyter notebooks are excellent for (at least) quick prototyping, data visualisation, literate programming and exploring ideas. I write plenty of Fortran and C++ and I still reach for notebooks when appropriate. In discussing with a non-technical, scientist friend, she pointed out that existing notebooks can be used and edited by folk even if they don't know python that well.
At the very least I see this particular tech as enabling more science by removing the operational challenge of running a jupyter server.
These tools take nothing from those who want to write fortran to do their science but make computation more accessible to those who don't.
I'm not super familiar with JAX though.
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.