Hacker News Reader

Comment by simonw | Hacker News Reader

JupyterLite is such an incredible piece of software. It came out of the Pyodide project, which first got Python compiled to WebAssembly working in the browser.

It really is astonishing that they've managed to get the full data science Python stack - a lot of it based around custom C extensions (numpy, Pandas etc) running entirely in the browser.

View on HN

Shameless self promotion: I made a constrained particle simulator and an numerical integrator visualizer with pyodide. (They are both for class assignments.)

https://scleox.github.io/constrained-particle-system-simulat...

https://scleox.github.io/integrator-visualizer/index.html

it's neat, but it's kinda slow (25x slower than native when I tested it)

In a JupyterLyte notebook:

    import numpy as np
    a = np.random.randn(128,128)
    b = np.random.randn(128,128)
    %timeit a @ b
    1.5 ms ± 3.3 µs per loop (mean ± std. dev. of 7 runs, 1,000 loops each)

On my command line:

    $ python3 -m timeit --setup 'import numpy as np; a = np.random.randn(128,128); b = np.random.randn(128,128)' 'a @ b'
    5000 loops, best of 5: 59.4 usec per loop

Not that I expect this to have fantastic performance, but I think your benchmark is cheating. Locally hosted Jupyter is going to have significant overhead compared to a straight Python interpreter.

Why do you say that? I assume the timeit magic reduces a lot of overhead

On my machine parents test is;

   python command line 247µs 
   local  jupyter lab  274µs
          jupyter lite 4ms  (about 16 times slower than the other two)

Honestly considering how jupyter lite is working, I still feel this is pretty good.

I’m shocked the local instance is so tight with the interpreter. I assumed jupyter injected itself all over the place to allow halting loops and what have you.

I do not care about the performance of jupyer lite - that it runs at all is a miracle. That it is acceptable performance for doing demos/teaching from a browser is simply magic.

In Jupyter you choose Run Cell or Debug Cell. Debug Cell just uses sys.settrace like pdb does. Run Cell is straight python. Also, the example they gave pretty much calls into C straight away.

Jupyter is incredibly powerful. I think a lot of the surprise (which I also had) is when you come from compiled languages and see the huge difference between running a compiled machine code vs just some faux interpreter. Python doesn’t have that. Everything is an interpreter (in a very loose sense). Jupyter, ipython, the shell etc all typically work similarly. If you think the overhead of rendering a webpage should slow down Jupyter, that is not the case. The “kernel” running your code and what’s handling your interactivity with Jupyter are separate processes.

Sure, but if you want to do a demo or have students do something quick, it's a great start

What happened if you increase the size of the matrices? I think we might be measuring the overhead

While this is obviously a great demonstration as to why you wouldn't do something silly like build an entire code editor in the browser for day to day use (because it would be slow and clunky and have all sorts of issues), it's great for a accessibility when you don't need performance at all.

Is this a snide comment on Atom and VS code? (I do think they're "slow" but not necessarily more than non-web rich IDEs - just compared to something like vim with conservative config/plug-ins).

I don't think so.

VSCode, Atom (and Jupyter) all run natively, only using a browser renderer for UI.

Jupiter already uses a browser as the front end, but the kernel runs natively.

JupiterLite runs entirely in the browswer, including the kernel. This means you don't need Jupyter installed or running on a server to execute the kernel. But it also means the kernel is running much slower in Web Assembly.

Yeah I’ve had a slowly bubbling level of hatred towards vscode for the last few months. Because it’s heft it’s absorbed all the plug-in ecosystem but it’s like sublime text left the sunroof open and now everything is soggy.

There's definitely a noticeable input lag in vscode.

I basically nerfed the vscode language features which make it more manageable.

But sublime still feels far more responsive.

Such a compact resource usage in WebAssembly.

I am seeing about 50-60MB resource usage which is fantastic considering that includes pandas, numpy, sklearn and some other non standard modules.

By comparison when I tried to package a hello world pandas project with PyInstaller the single file exe for Windows came out to 500MB.

and Fortran! SciPy is like 20% fortran (as far as I remember).

It really is. I guess this'll be quite useful for people on chromebooks and iPads as well.

Chromebooks can run linux containers out of the box, you don't need to hurt yourself like this. The experience is similar to WSL.

https://support.google.com/chromebook/answer/9145439?hl=en

Not school-issued ones, as my son and I discovered. He told me that the school had assigned a Chromebook to each student. I said: "Great, let's install Python on it."

Nope. Locked down like a crab's arse.

Sad. The Chromebook went under his bed, and came back out at the end of the school year when it had to be returned.

I’ve never mentally rendered a crab’s ass but now your comment got me thinking, is it some sort of chitin-based mechanical trap door? Or maybe an iris like the star gate but with fewer petals? This is a particularly glaring gap in my intuition’s ability to improvise an answer.

I didn’t believe it when I first read it but I can indeed run arbitrary code on my iPhone with Jupyterlite. This is great! So finally I can analyse data using the iPad on a plane, hopefully… if I find a way to reliably start Jupyterlite from the iPad‘s local storage, load my data from there, and have a persistent python environment.

Reply on news.ycombinator.com