> "Part of an effort to make a Jupytr notebook-like environment without relying on server side code."
So there won't be any server side code, you'd just be downloading the entire Python stack and dependencies every time you want to use this through your browser. This time it will be WASM though, instead of x86/x64/pyc.
Absolutely; it's pretty much like installing an application that includes all its dependencies. Which, interestingly, is also the direction installed apps are moving towards somewhat, at least on Linux.
There's an advantage even if you're running it locally. Now you can just load up some static HTML + JS files in your browser instead of spinning up a server and then pointing your browser at localhost.
Actually, Numpy-using-code is closer to native speeds than pure Python is.
The thing that seems to cause a greater gap between wasm and native speeds is lots of Python-level function calls, not the tight C loops that make up much of Numpy.
Yep. You can "import" python objects over to the Javascript side and start using them from there. It's not as pleasant as working with Numpy in Python, of course, due to lack of operator overloading, of course.
C can compile to WASM, but I have no clue about external tools like BLAS. I'd assume that things like Numpy are able to work without tools like BLAS, but you might also be able to compile the essential ones to WASM as well.
NumPy can work without libraries like BLAS or LAPACK, but it will be sloooooooooow. There are C versions of those libraries however, maybe they are using those?
Python C extensions like NumPy are compiled into shared libraries, and loaded using dlopen() etc. normally by the main compiled Python runtime. (The only special thing here is that all those components are compiled to WebAssembly so it can run on the Web.)
This is great. Many times I wanted to showcase to colleagues who don't use Python how things would work in Python, but they don't have either Python or Jupyter installed. So I had to run Jupyter server in my own environment and give them access to it. This is quite an inconvenience as well as a security risk. Having a completely server-less Python/Jupyter environment should make this kind of showcasing much easier.
I'll chime in to mention notebooks.azure.com as well.
(Typical disclaimer, I'm a dev on the azure notebooks team; we just try to solve exactly the scenario GP was asking so I would be remiss to not throw our hat in the ring)
I do a lot of work with Skulpt, which included adding (somewhat superficial) support for MatPlotLib. You can make line plots, scatter plots, and histograms. It's a pretty cool system, though I will say developing in it isn't always very fun :)
I benchmarked this recently. It comes in at 4-10x slower than cpython for random typical use cases on my machine, which is not too shabby at all. The author also states that numpy is slower than it should be due to lack of support for BLAS at this time.
The real impressive feat to me isn't hosting jupyter in the browser. It's access to a reasonably fast implementation of numpy in the browser which smokes native JS code for homogeneous array operations. I would love to see a minimalistic WASM implementation of numpy that can seamlessly interop with normal JS. Such a library would open up all sorts of possibilities that aren't currently feasible due to perf reasons.
I can't believe I'm saying this but it would be neat to have a browser native BLAS, or absent that perhaps cross-compiled to WASM from a RUST implementation or something! Makes me think of all the demos like the tensorflow playground (dunno if all that happens in the browser or not).
Numpy is fast thanks to having much of its code compiled as a native library.
They were purposefully working to reduce abstraction, since performance mattered from day one.
WASM is a huge step backwards in that regard. If you care about performance, just install Python on your box and "pip install numpy". Do you absolutely have to have it come in a browser now?
53 comments
[ 2.4 ms ] story [ 82.8 ms ] threadhttps://github.com/iodide-project/iodide
So there won't be any server side code, you'd just be downloading the entire Python stack and dependencies every time you want to use this through your browser. This time it will be WASM though, instead of x86/x64/pyc.
That we can, doesn't mean that we should.
Like npm? No.
It exists and it's called bower.
And yes I could pay for a Jupiter notebook hosted on some instance but I dont want to.
Of course when it's like 50-100MB you wouldn't use it in some cases. But once cached you're golden for your repeat visitor audience.
Wouldn't Bokeh make more sense? I'd be very interested in a serverless Bokeh that didn't force me to ditch Python, for example.
More recently, pyodide has grown full matplotlib support. See, for example, https://iodide.io/pyodide-demo/matplotlib-sideload.html?side...
TL;DR: pyodide in Firefox was slower than cpython.
> UPDATE 2018-04-11: My hunch was wrong, and I was able to get to the bottom of the root cause and significantly speed up these benchmarks.
And there's an updated graph here:
http://droettboom.com/blog/2018/04/11/profiling-webassembly/
The thing that seems to cause a greater gap between wasm and native speeds is lots of Python-level function calls, not the tight C loops that make up much of Numpy.
(Typical disclaimer, I'm a dev on the azure notebooks team; we just try to solve exactly the scenario GP was asking so I would be remiss to not throw our hat in the ring)
The real impressive feat to me isn't hosting jupyter in the browser. It's access to a reasonably fast implementation of numpy in the browser which smokes native JS code for homogeneous array operations. I would love to see a minimalistic WASM implementation of numpy that can seamlessly interop with normal JS. Such a library would open up all sorts of possibilities that aren't currently feasible due to perf reasons.
Running the exported notebook here takes
time py3 python.py real 0m0.145s
chrome: load html: 2sec run html: 13sec!
That's not 10 times slower, but a 100 times slower!
Still good start.
They were purposefully working to reduce abstraction, since performance mattered from day one.
WASM is a huge step backwards in that regard. If you care about performance, just install Python on your box and "pip install numpy". Do you absolutely have to have it come in a browser now?
``` TypeError: window[s] is undefined ```
with firefox.
I'd love to get to the bottom of that.