> py2wasm converts your Python programs to WebAssembly, running them at 3x faster speeds
This is clearly written in the article, but I hope that the impatient readers will understand that this is 3 times faster than the CPython wasm, not the native CPython.
even more specifically, 3 times faster than wasmer's build of cpython (whatever that is), running on their runtime.
i'd be curious to see this benchmark extended, as in my own experience toying with python-like interpreters, you get ~2x slowdown (like their end result) from just compiling to wasm/wasi with clang and running in any 'fast' runtime (e.g. node or wasmtime).
Hey, I'd love to reproduce the ~2x slowdown you commented from running the workload in Native CPython compared to Wasm CPython (in any runtime, browser or outside).
Any tip would be helpful so we can debug it. If your claims are accurate, we can easily get py2wasm even running faster than native CPython!
Note: we benchmarked in a M3 Max laptop, so maybe there's some difference there?
note that i'm not claiming 2x slowdown for cpython.
but here's one test i've run just now:
using your test file, i've run this one-liner on my x86_64 linux laptop in https://pyodide.org/en/stable/console.html in chromium (v8) and natively (pyodide's urllib doesn't handle https for some reason):
That should help us a lot to investigate further the difference in timing. I remember trying the py2wasm strategy about 4 years ago, and I got it running faster than native CPython, so there must be something we are missing!
Even more honest would be “on one particular microbenchmark that everybody optimizes for”.
That said, this seems like a really cool project that could have some real value! It still fully depends on having the full CPython runtime environment, but that means it could work correctly with most existing code and libraries (including numpy and script).
From what I could tell, Nuitka dynamically loads extension modules so this wouldn't work with Webassembly modules which are statically linked. If I could be enhanced to automatically build wheels of packages like numpy and statically link them, then that could bring extensions to Wasm and be very cool. IIRC, Google does this with their Python apps so the concept does exist but don't think I've seen any OSS tooling trying that.
So I had a look at the repo/branches at https://github.com/wasmerio/py2wasm. This might be a nit, but in the spirit of OSS: if I'd done this work, I'd have contributed it to upstream Nuitka. I definitely would not have forked a whole new GitHub repo and given it a completely different name.
What's the rationale for creating a new project and calling it py2wasm? Am I missing something?
We envision py2wasm being a thin layer on top of Nuitka, as also commented in the article (not a fork as it is right now, although forking got us into the proof of concept a bit faster!).
From what we gathered, we believe that there's usefulness on having py2wasm as a separate package, as py2wasm would also need to ship the precompiled Python distribution (3.11) for WASI (which will not be needed for the other Nuitka use cases), apart of also shipping other tools that are not directly relevant for Nuitka
My first thought upon reading Nuitka's name in the article was along the lines of "I hope they've contributed some of this to Nuitka". Not a very nice trend.
Forking happens all the time. It's one of the benefits of open source. I've often made PRs on github to projects while shifting projects I work on to my fork since upstreaming can take months or often never happen
Granted, Nuitka is an active project, but wasmer.io is going to have a much more focused desire with their changes that they can deploy, meanwhile getting it upstream will have to go through rounds of review & adjustments
Nice--it's great to see more options for interoperability between Python and WASM. I was aware of Pyodide [1], but Py2wasm seems to be a tool for compiling specific scripts into WASM rather than having an entire Python distribution in the browser. Please correct me if I'm misunderstanding the difference between the two however.
That's my understanding as well. And Pyodide being a great piece of engineering, is still lagging behind compiled Wasm languages in terms of footprint at least and performance sometimes, unfortunately.
What's up with the botspam in this thread? Looks like hundreds of sex bot accounts are being created. Pages seem really slow to load currently... someone should notify dang.
How come the CPython interpreter is so slow when compiled to WebAssembly? According to the figures in the article, it runs at 23% the speed of the native version.
Wasmer, which they're using in the benchmarks, should run code "at near-native speeds" according to the docs[0]. Apparently it has multiple compiler backends, so maybe the choice of backend affects the result?
With WasmGC finalized, I hope we see more compilers that target it instead of including their own GC.
It's could be a new interpreter, or maybe a version of CPython that uses WasmGC structs for all Python objects, or a compiler similar to this but that targets WasmGC directly.
WasmGC is not really what you think it is. Think of it as a full-on replacement for the linear memory model, not as a way to add GC to it.
It's exceptionally difficult to port a language runtime over to WasmGC -- it doesn't even offer finalizers, so __del__ can't implemented correctly (even ignoring the issues with existing __del__ semantics in Python leading to compatibility issues). It doesn't support interior pointers, so you can't have a pointer into the middle of an array.
Current WasmGC is missing a lot of critical features for production grade GC, like finalization and interior pointers. It's really promising though, so I think once the gaps get filled in you'll see a bunch of runtimes start moving over - maybe .NET, etc.
Nice. Maybe a pie in the sky but considering how prevalent python is in machine learning, how likely is it that at some point most ML frameworks written in python become executable on a web browser through WASM?
Last we checked for one of our use cases around sandboxing, key pydata libraries were slowly moving there, but it takes a village.
At that time, I think our blockers were Apache Arrow, Parquet readers, and startup time. There were active issues on all three. The GPU & multicore thing is a different story.as that is more about Google & Apple than WASM wrt browsers, and I'd be curious about the CUDA story serverside. We didn't research the equivalent of volume mounts and shmem for fast read-only data imports.
For Louie.AI, we ended up continuing with serverside & container-based sandboxing (containers w libseccomp, nsjail, disabled networking, ...).
Hard to motivate wasm in the server for general pydata sandboxing in 2024 given startup times, slowdowns, devices, etc: most of our users who want the extra protection would also rather just self-host, decreasing the threat model. Maybe look again in 2025? It's still a good direction, just not there yet.
As a browser option, or using with some more limited cloud FaaS use cases, still potentially interesting for us, and we will keep tracking.
Python in ML acts as a glue language for loading the data, the interface, api, et. The hard work is done by C libraries running in parallel on GPUs.
Python is quite slow, and handles parallelization very badly. This is not very important for data loading and conditioning tasks, which would benefit little from parallelization, but it is critical for inference.
Depending on the underling machine learning activity (GPU/no-GPU) it should be already possible today. Any low level machine learning loops are raw native code or GPU already and Python’s execution speed is irrelevant here.
The question is do the web browsers and WebAssembly have enough RAM to do any meaningful machine learning work.
> FWIU Service Workers and Task Workers and Web Locks are the browser APIs available for concurrency in browsers
sqlite-wasm, sqlite-wasm-http, duckdb-wasm, (edit) postgresql WASM / pglite ; WhatTheDuck, pretzelai ; lancedb/lance is faster than pandas with dtype_backend="arrow" and has a vector index
The actual underlying models run in a lower-level language (not Python).
But with the right tool chain, you already can do this. You can use Pyodide to embed a Python interpreter in WASM, and if you set things up correctly you should be able to make the underlying C/FORTRAN/whatever extensions target WASM also and link them up.
TFA is compiling a subset of actual raw Python to WASM (no extension). To be honest, I think applications for this are pretty niche. I don't think Python is a super ergonomic language once you remove all the dynamicity to allow it to compile down. But maybe someone can prove me wrong.
We implemented an in-browser Python editor/interpreter built on Pyodide over at Comet. Our users are data scientists who need to build custom visualizations quite often, and the most familiar language for most of them is Python.
One of the issues you'll run into is that Pyodide only works by default with packages that have pure Python wheels available. The team has developed support for some libraries with C dependencies (like scikit-learn, I believe), but frameworks like PyTorch are particularly thorny (see this issue: https://github.com/pyodide/pyodide/issues/1625 )
For popular ML/DL models, you could already export model to ONNX format for interference. However, glue codes are still python and you may need to replace that part with the host’s language
Similar examples for raw DOM manipulation should be available for Pyodide as well. It has bindings to all JS code, so it can do everything that JS can do.
> We worked on py2wasm to fulfill our own needs first, as we want to accelerate Python execution to the maximum, so we can move our Python Django backend from Google Cloud into Wasmer Edge.
I was under the impression that Django was stateful and not meant to be run in a serverless/edge cloud. Is that not the case or are you planning to do a special setup to support that?
I want the opposite. The Python VM is everywhere. Can't I just run
my WASM on Python? (The WASM runtime must be pure Python, installing C/C++ extensions is against the spirit of this.)
Hmm, what I want is to run WASM using a CPython extension. CPython extensions are vital to Python. I'm curious why you say an extension is against the spirit of it.
I know Python 2 has been EOL for over four years now but you still see it (much to the chagrin of decent engineers everywhere) in the wild; could generate confusion.
Indeed, this can be way further optimized.
For example, you can probably do a wasm-strip and wasm-opt passes that would leave the wasm file being ~5-10Mb. Still very big, but a bit more reasonable.
The good thing is that thanks to Nuitka you could actually do some tree shaking and only include the imported files and not everything in between (although this might break other behavior such as eval and so).
This is clearly written in the article, but I hope that the impatient readers will understand that this is 3 times faster than the CPython wasm, not the native CPython.