Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Python scientific stack, compiled to WebAssembly

github.com

Post reply on HN
Print view View original

11–20 of 54 posts

Re: The Python scientific stack, compiled to WebAssembly

#13

Post by zitterbewegung »

xtrapolate wrote: post #4
mr_toad wrote: post #2

Part of an effort to make a Jupytr notebook-like environment without relying on server side code. https://github.com/iodide-project/iodide

> "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. That we can, doesn't mean that we should.

It would work on a Chromebook and a iPad also.

And yes I could pay for a Jupiter notebook hosted on some instance but I dont want to.

Re: The Python scientific stack, compiled to WebAssembly

#15

Post by lkbm »

amelius wrote: post #9

Is there a performance hit compared to "native" Python?

There's a chart and some discussion here: http://droettboom.com/blog/2018/04/04/python-in-the-browser/ (and some followup at http://droettboom.com/blog/2018/04/11/profiling-webassembly/ )

TL;DR: pyodide in Firefox was slower than cpython.

Re: The Python scientific stack, compiled to WebAssembly

#16

Post by mjs2600 »

nerdponx wrote: post #11

What happens to all of the C code in Numpy, and the calls to external libraries like BLAS?

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.

Re: The Python scientific stack, compiled to WebAssembly

#17

Post by amelius »

lkbm wrote: post #15
amelius wrote: post #9

Is there a performance hit compared to "native" Python?

There's a chart and some discussion here: http://droettboom.com/blog/2018/04/04/python-in-the-browser/ (and some followup at http://droettboom.com/blog/2018/04/11/profiling-webassembly/ ) TL;DR: pyodide in Firefox was slower than cpython.

Thanks. Note that the author of that post said:

> 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/

Re: The Python scientific stack, compiled to WebAssembly

#19

Post by alexeiz »

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.

Re: The Python scientific stack, compiled to WebAssembly

#20

Post by Vinnl »

xtrapolate wrote: post #4
mr_toad wrote: post #2

Part of an effort to make a Jupytr notebook-like environment without relying on server side code. https://github.com/iodide-project/iodide

> "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. That we can, doesn't mean that we should.

Well, you'd download the entire stack indeed - but not every time. Your browser does caching too.
Post reply on HN