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

RustPython

rustpython.github.io

Post reply on HN
Print view View original

211–220 of 244 posts

Re: RustPython

#211

Post by soerxpso »

ashish01 wrote: post #207

I was curious about how slow (or fast) it is compared to cpython. On fibonacci.py rustpython about 11x slower than cpython. def fib(n): if n == 0 or n == 1: return 1 return fib(n-1) + fib(n-2) print(fib(35)) time python3 ~/code/fibs.py 14930352 ________________________________________________________ Executed in 1.18 secs fish external usr time 1.14 secs 180.00 micros 1.14 secs sys time 0.01 secs 616.00 micros 0.01 s…

Using the .__jit__() method in your rustpython version might get you a speedup (I assume they intend for this to be automatic eventually, and it's only explicit right now while the feature is under construction).

Re: RustPython

#212

Post by mcherm »

DanielHB wrote: post #105
esrauch wrote: post #97

Earlier quoted context omitted.

The reality is that the "dark" majority of preexisting code has essentially no performance requirements/concerns; they're business scripts that could literally run on a toaster with no problem if you could get the code onto it. So really most business logic can easily be satisfied by "compile the interpreter to wasm and then run the dynamic language on that", and doing it this way can move existing "learned the hard…

I don't think you grasp quite the implications of what I was saying, this kind of approach could take _seconds_ to even start running your python application. Large python codebases could take like a minute to start if loaded that way. Once it does start then your arguments can make sense, but even so it would still make it impractical for most things. Trust me, when the Javascript dev tells you something will be slo…

> this kind of approach could take _seconds_ to even start running

Only seconds? Today it takes 45 minutes to do the update by hand, but there's this handy 20-line Python script that does it instantly.

(Hypothetical example only, but it's not uncommon.)

Re: RustPython

#213

Post by crabmusket »

hobofan wrote: post #128
DanielHB wrote: post #89

> "it can be compiled to WebAssembly in order to run Python in the browser." I have seen this approach with C-python and NodeJS already and I think it simply not viable, what they are suggesting is compiling the runtime (the same one you use in non-wasm projects) to wasm and then run your python code on top of it. This is a double-whammy of performance degradation, you basically have two JIT-compilation steps happeni…

> once by the wasm runtime to compile the rust-python wasm I'm not sure what you mean by that. The runtime doesn't compile WASM, it simply executes it. There are tools for dealing with interpreter runtime overhead this by pre-initalizing the environment like Wizer[0]. ComponentizeJS[1] uses it to pre-initialize the Spidermoney engine it packages to gain fast startup times (and you can then prune the initialization on…

> The runtime doesn't compile WASM, it simply executes it.

That's not necessarily true. For example, Wasmtime uses Cranelift to compile WASM binary into native code. https://docs.wasmtime.dev/contributing-architecture.html

Re: RustPython

#214

Post by buddhu »

pkolaczk wrote: post #67
amelius wrote: post #61

Earlier quoted context omitted.

Turns out 99% of the time you don't need to parse terabytes or have μs-response times. Meaning you should be programming just about 99% of your time in Python. The Rust memory management puzzles are not really complicated. They just get in the way. > they don't have basic language tools like proper sum types or traits that get things done Sum types and traits are not getting things done.

> Meaning you should be programming just about 99% of your time in Python. No, not me, because I’m less productive in Python than in Rust, assuming the same level of final product quality, even excluding runtime performance. > Turns out 99% of the time you don't need to parse terabytes or have μs-response times. Performance is not the primary reason to use Rust. It has way more to offer than performance.

> Performance is not the primary reason to use Rust. It has way more to offer than performance.

So much this. I've been doing mostly Scala (and some Haskell) for the last 10 years, and now I'm really enjoying Rust precisely because of its language features. Performance is just a (really) nice bonus.

Other bonuses include simple deployments (single binaries versus massive JVM and fat jars), low memory footprint, simple builds that just work (Cargo is an absolute joy), great concurrency, great ecosystem, etc. etc.

Re: RustPython

#215

Post by lmm »

pletnes wrote: post #57
brnt wrote: post #4

Earlier quoted context omitted.

I wonder if anyone actually uses those third-party interpreters for anything serious. I've never come across anyone that did.

Pypy is nice if you want more performance. From my experience it seems underused. Never seen jython and ironpython used - yet.

Pypy gives you at best a single-digit speedup, and requires carefully going through your dependencies and checking all your codepaths. That's rarely a good value proposition for a business - if you're growing fast enough that performance is an issue, you're going to need a bigger speedup than that pretty soon, and if you're taking the time to go through all your codepaths, it doesn't cost a lot more to make a bigger change like switching languages entirely.

Re: RustPython

#216

Post by simonw »

bornfreddy wrote: post #197
simonw wrote: post #123

Earlier quoted context omitted.

Pyodide (standard cPython in WebAssembly) loads surprisingly quickly. My https://lite.datasette.io application usually starts up in less than 10s - most of that is downloading about 10MB of WASM blobs, and 10MB isn't actually that big these days (many sites serve more than that in image headers). When I built Datasette Lite I did it as a research project, assuming it would be far too slow loading to be useful. I've s…

Curious - could these blobs be cached? I'm assuming they change only on upgrade?

Yes, they're cached using standard browser HTTP caching.

A very rough estimate just now on my iPhone over 5G: 12s for the first load, then when I visited again took around 3s.

Re: RustPython

#217

Post by jjtheblunt »

nick238 wrote: post #196
jjtheblunt wrote: post #191

Earlier quoted context omitted.

I haven't used any such slow thing yet (am mostly a commandline world person).

Don't work for a company where you need to turn in receipts or fill out info in crappy HR software? I mean, good for you and knowing the command line, but doing the less-fun, less-specialized parts of jobs usually involves regressing to the mean of what interfaces people know how to use.

I don’t. But I understand what you’re describing

Re: RustPython

#218

Post by DanielHB »

phkahler wrote: post #106
esrauch wrote: post #97

Earlier quoted context omitted.

The reality is that the "dark" majority of preexisting code has essentially no performance requirements/concerns; they're business scripts that could literally run on a toaster with no problem if you could get the code onto it. So really most business logic can easily be satisfied by "compile the interpreter to wasm and then run the dynamic language on that", and doing it this way can move existing "learned the hard…

>> The reality is that the "dark" majority of preexisting code has essentially no performance requirements/concerns; they're business scripts that could literally run on a toaster with no problem if you could get the code onto it. Which means this whole thing is pointless from an end user point of view. The technology stack is getting very deep - Python, Rust interpreter, WASM, in a browser. I'd love to get back to r…

Technically this approach puts the burden on the build toolchain, the toaster only needs a WASM runtime which is actually not that big of an ask (it is far easier to put a standalone WASM runtime in a toaster than a full browser)

Re: RustPython

#219

Post by DanielHB »

Izkata wrote: post #152
DanielHB wrote: post #89

> "it can be compiled to WebAssembly in order to run Python in the browser." I have seen this approach with C-python and NodeJS already and I think it simply not viable, what they are suggesting is compiling the runtime (the same one you use in non-wasm projects) to wasm and then run your python code on top of it. This is a double-whammy of performance degradation, you basically have two JIT-compilation steps happeni…

> > "it can be compiled to WebAssembly in order to run [..] in the browser." > and NodeJS Wait... what? Why?

So you can run NodeJS code in the browser, even though both are JS-based, NodeJS has a bunch of APIs that deal with things like file systems that the browser doesn't have.

For example, imagine you have a lib that converts markdown to html, but the lib happens to write the files directly to the disk, hence it can't be used in the browser. If you compile the nodejs runtime to wasm with a WASI that maps the file system to local storage, then you can just read the file from local storage after invoking the lib.

Just saying it is a technical possibility, this kind of approach is really only meant to be used if you _really_ just want to run some lib in the browser, no matter how slow it gets.

Also technically if you could compile JS to wasm (without nodejs, so more like how you run C through wasm right now) then you don't need to care about browser versions and JS api polyfills while still using JS.

Re: RustPython

#220

Post by berkes »

ddorian43 wrote: post #10
berkes wrote: post #8

Earlier quoted context omitted.

I was recently looking for some ways to make a rust project dynamically configurable. Yaml/toml/etc are too static or are terrible to describe logic in (yet we do it all the time for CI, infra etc, ugh). WASM would be an option, but overengineered for my case. Ruby (through Artichoke), or Python (through RustPython); but they come with the downside of introducing Ruby or Python. I haven't decided yet, but would prefe…

why not lua?

No particular reason.

edit: to be clear, I did mention "I would prefer lua for it's simplicity".

I'm exploring all the existing work out there. Lua is certainly an option. From what I can see on the outside, is that lua embedding for rust is immature compared to some other solutions. But maybe that's because the lua-folks are just more honest :)

Post reply on HN