3 ms·
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)
by brrrrrm 4y ago
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
- 0cf8612b2e1e 4y agoNot 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.
- brrrrrm 4y agoWhy do you say that? I assume the timeit magic reduces a lot of overhead
- voxelghost 4y agoOn 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.
- 0cf8612b2e1e 4y agoI’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.
- lozenge 4y agoIn 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.
- hnews_account_1 4y agoJupyter 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.
- thejosh 4y agoSure, but if you want to do a demo or have students do something quick, it's a great start
- geysersam 4y agoWhat happened if you increase the size of the matrices? I think we might be measuring the overhead
- SilverBirch 4y agoWhile 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.
- e12e 4y agoIs 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).
- kmacdough 4y agoI 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.
- SilverBirch 4y agoYeah 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.
- cyanydeez 4y agoThere'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.