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!
greggsy 5 hours ago [-]
I run some Jupyter notebooks against a local Postgres realestate db to do statistical analysis. Could I use this to just run it on a compute host without having to manually set up and activate a venv?
rossant 15 hours ago [-]
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.
32191868 5 hours ago [-]
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.
jamiejquinn 4 hours ago [-]
I find your take a little lacking in nuance...
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.
lmc 15 hours ago [-]
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.
SylvainCorlay 4 days ago [-]
It also works with Pytensor & PyMC!
ballooney 6 hours ago [-]
Does this bring me closer to being able to run notebooks natively on my ipad?
I’m aware of Jax-js. It’s a different beast: an [incomplete last I checked] port of jax for JS, not something you can run your, e.g. jax-dependent marimo notebook or pyodide against
saliei 17 hours ago [-]
This is nice actually!
analog_daddy 10 hours ago [-]
This is awesome!! Another great addition to awsm-wasm!
maitrungduc 4 days ago [-]
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.
Rendered at 19:59:58 GMT+0000 (Coordinated Universal Time) with Vercel.
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 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.
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.
> Numba delivers a roughly 250× speedup in WebAssembly, compared with about 90× natively.
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.