Rust is approximately as fast as C. So a straighforward reimplementation of CPython in Rust would be approximately as fast as the original.

Rust makes it easier to write programs that don't leak memory and don't have data races, but it doesn't make them run faster.

Here the optimism would be around removing the GIL and similar stuff, it is not that rust would make the same architecture magically faster but that it could allow a better one.

Also others have noted that speed was not a primary focus of CPython

Rust is definitely not as fast as C, it's most likely not as fast as C++

It's within 5-10% on average, sometimes faster, usually a little slower, very rarely slower by much. The person you're responding to said "approximately". I feel like this is needless pedantry.

Rust also allows you to make architectural decisions in the name of performance that would be completely unmaintainable in C. See: the Servo project.

Further, it should be possible for Rust to eventually reach a state where it's faster than C because of the lack of pointer aliasing. This opens up a whole host of optimization opportunities, allowing it to get closer in performance to Fortran (which is intrinsically the fastest of the bunch).

Indeed, it's available but currently disabled due to a bug in LLVM that can cause incorrect code generation.

https://github.com/rust-lang/rust/issues/54878

This is not the first time it has been disabled due to an LLVM bug.

https://github.com/rust-lang/rust/issues/31681

What makes you say that? Optimized machine code is for the most part optimized machine code, and unsurprisingly benchmarks tend to come down about even. The bunchmarks game currently has them down as

C vs. Rust: 6 wins for C, one draw, 3 wins for Rust

C++ vs. Rust: 5 wins for C++, two draws, 3 wins for Rust

The wins one way or another are also not by particularly large margins.

https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

This may go on to shift marginally in Rust's favor once a soundness bug related to non-aliasing of references is fixed in LLVM and the compiler can safely leverage some guarantees that Rust provides that C and C++ cannot.

Any update on that bug being fixed?

That’s a false dilemma. We’ve had almost three decades to optimize CPython. It will take a while to catch up.

>We’ve had almost three decades to optimize CPython

Assuming that was actively pursued. But if it was, all those other projects (Unladden Swallow, Dropbox's Python project, PyPy, etc, whose intend was exactly to make Python faster, wouldn't have been started).

Some of those lessons have most definitely been used to improve the reference implementation.

It's not remarkably slow as long as you compare apples to apples, that is non-jitted vm-interpreters.

Jits pay a steep complexity- (and hence maintenance) price for their performance that should be taken into account when comparing.

Designing a significantly faster interpreter with comparable features is non-trivial from my experience [0].

https://gitlab.com/sifoo/snigl

It's not, and I'm curious as to why, I even suggested a reason very similar to your answer. I guess people assumed malice. Oh well.

The dilemma klodoph mentions is:

> [Performance] isn't [...] one of the selling points of Rust

or

> this [...] software has been implemented poorly

It sounds like you're maligning Rust (isn't keeping promises) or RustPython (is implemented poorly), and it's easy to read "implemented poorly" as an attack on the implementers.

Well, it's definitely a possibility. I am not trying to attack them, it might be the case, or it might not. I was just trying to get possible reasons, and that's what came to mind. I'm sure there are other reasons, that's why I asked.

I really don't know how slow it is, I've not done benchmarks, but given that Rust is supposed to be efficient, it certainly can't be that slow, unless the implementation is really poor, I guess. I'm not saying it is because I don't know. If anyone has done benchmarks, please do share!

The reason for why I got the idea that it is slow, is that I believed the parent[1], and people have repeatedly claimed that CPython is slow.

[1] "to eventually get the same or better performance as CPython."

I assume this means that it is slower than CPython, and CPython is already extremely slow according to some people even on this page.

Sorry for the confusion. :)

Thanks for the explanation!

One thing to consider is that CPython isn't slow because of the language it's written in, but because of optimizations it isn't doing (namely JIT, I think). Rust can't do the same things any faster than C can, and an early implementation of Python in Rust isn't likely to be much faster than an early implementation in C. Rust has the potential to make certain classes of optimization easier, eventually.

For an example of the huge developer productivity multiplier Rust is for this kind of thing check out what Yorick Peterse has done in his spare time with Inko: https://gitlab.com/inko-lang/inko

Even if RustPython is faster at the architectural level (which it probably does, CPython is infamously slow), CPython has the advantage of a mature codebase and two and a half decades of accumulated performance tuning.

>and two and a half decades of accumulated performance tuning.

Or two and a half decades of performance neglect.

I've read about things like dicts, sort and the like getting faster implementations, but I've never seen a big effort to make CPython faster in general. In fact the first versions of 3.x were even allowed to regress to slower than 2.x.

This is certainly the case when it comes to startup time (an important thing in a scripting language). On my linux system, python2 starts in about 10ms, python3 takes 20-25 ms.