Hacker News Reader

Comment by singularity2001 | Hacker News Reader

singularity2001·

Yeah the performance comparison doesn't look too great yet: https://rustpython.github.io/benchmarks

Currently it's more about clarity and a nice clean code base, but it can only get faster from here

This seems like a very optimistic take. For some reason, it made me think about spectre and heartbleed and how my computer just kept getting slower a couple years back.

Any idea where the slowness is coming from?

I've been playing with making a rust interpreter and reading other people's work. Here's an interesting blog post (not mine) on making a interpreter in rust match the speed of a c implementation. It seems folks often have to resort to unsafe rust to get the performance they want. I don't claim to fully understand that and am looking for more information myself.

http://www.dannyvankooten.com/blog/2022/rewriting-interprete...

With webservers we already saw that the way to make new things fast in Rust is to use lots of unsafe Rust when needed, optimize the code, and after that think about the right abstractions that minimize the unsafe code surface.

Well there's no production class garbage collector in Rust yet, so in RustPython they're just using Rc's I think. That's one place to start. The other will probably be the quality of the JIT.

Does Python have a GC these days?

It uses refcounting in the common case and then a second cycle-detecting GC for the less common cases

Ah, I forgot the cycle-detector.

Thanks!

RustPython didn't adapt the optimization designs yet. One of the current major goal is this optimization: https://github.com/RustPython/RustPython/issues/3244

RustPython even cannot run `1+1` without calling `int.__add__` yet. And it is working on https://github.com/RustPython/RustPython/pull/4615

So it still has long way to go not C vs Rust but from the design level.

Reply on news.ycombinator.com