4 ms·
one wasmtime dependency and a self contained python file with 100 loc seems reasonable! much better than calling deno, at least if you have no pip dependencies
by singularity2001 1y ago
one wasmtime dependency and a self contained python file with 100 loc seems reasonable!
much better than calling deno, at least if you have no pip dependencies...
just had to update to new api:
# store.add_fuel(fuel)
store.set_fuel(fuel)
fuel_consumed=fuel-store.get_fuel()
and it works!!
time to hello world:
hello_wasm_python311.py 0.20s user 0.03s system 97% cpu 0.234 total
- lopuhin 1y agoit's pretty difficult to package native python dependencies for wasmtime or other wasi runtimes, e.g. lxml
- Already__Taken 1y agoyeh if you can't shove numpy in there its not really useful.
- antonvs 1y agoI was interested in how this compares in a kind of absolute sense. For comparison, an optimized C hello world program gave these results using `perf` on my Dell XPS 13 laptop: 0.000636230 seconds time elapsed 0.000759000 seconds user 0.000000000 seconds sys That's 36,800% faster. Hand-written assembly was very slightly slower. Using the standard library for output instead of a syscall brought it down to 20,900% faster. (Yes I used percentages to underscore how big the difference is. It's 368x and 209x respectively. That's huge.) Begrudgingly, here are the standard Python numbers: real 0m0.019s user 0m0.015s sys 0m0.004s About 1230% faster than the sandbox, i.e. 12.3x. About an order of magnitude, which is typical for these kinds of exercises.
- singularity2001 1y agohaha, 99% is startup time for the sandbox, but yeah, python via wasm is probably still 10-400 times slower than c.
- fzzzy 1y agoGreat, thanks for your post! I got it working too. This is going to be incredibly handy.