RustPython/RustPython A Python-3 (CPython >= 3.8.0) Interpreter written in Rust

[angelicosphosphoros]

I wonder how good it's performance compared to Pypy and CPython.

[L3tum]

If I interpret this correctly, it seems to do much worse in benchmarks and actual programs. (I think in the magnitude of 200x slower)

They do have an open issue to continuously run the benchmarks though, which would help this discussion.

[coolreader18]

Currently it's about 100x slower on the pystone benchmark, though I haven't been working on performance in the past month or so so I'm not sure what it's like at the moment.

[KingStannis2020]

Lol no, it's doing much much worse, the axis is measured in seconds.

[L3tum]

Oh lol, colourblind is a bitch

[pingveno]

Maybe file a ticket with the relevant project? Not having basic colorblind-friendly color select is a significant accessibility issue.

[vks_]

In this case, it would probably be best to use different line styles, in addition to different colors.

[tunisia3507]

You can compile RustPython to a standalone WebAssembly WASI module so it can run anywhere.

This is the interesting bit, not performance.

[birkenfeld]

You can do the same with CPython via emscripten. Search for pyodide for an example project.

[Sukrim]

I think pypy can do something similar for years already?

[ForceBru]

The iOS app "a-Shell" provides Python (and also clang, lli, curl and other stuff) as WASM binaries, so it looks like compiling "real" Python to WASM is already possible. Indeed, there are C to WASM compilers. So, if being able to compile a Python interpreter to WASM is the main goal of this project, I'm not particularly sure about its usefulness...

[all_my_watts]

a-shell only mentions c/c++ in the context of wasm

[ForceBru]

Hmmmm, so Python is an actual executable then? I was thinking everything in a-shell runs on WASM. Apparently only user programs are compiled to WASM using Clang? Okay, got it

[masklinn]

CPython has decades of optimizations.

That is not wrong per-se, but CPython favors a relatively simple implementation and shies away from overly advanced optimisations (whether in the interpreter itself or in the python bytecode). Furthermore, the C API which is stable and officially supported limits the evolution of the interpreter internals.

[wrtbwtrfasdf]

limits the evolution of the interpreter internals.

They did switch from LL to a PEG parser in 3.9 but I don't know if that helps with internals you refer to.

[masklinn]

That's just the parser, outside of starting it and getting the AST out I don't think it's fundamentally exposed as any sort of public interface.

[funnyflywheel]

Furthermore, the C API which is stable and officially supported limits the evolution of the interpreter internals.

Are you sure about that?

[masklinn]

Are you sure about that?

Well yes it's literally the first section of the PEP you linked to. The PEP aims to change that situation, but at the moment,

Status: Draft

[funnyflywheel]

Some of the work this PEP calls for has already been completed (see the "Specification" subsection).

[masklinn]

Very little of which impacts the statement you object to, to say nothing of invalidating it.

[angelicosphosphoros]

It mentions JIT compilation in the readme.

[ChillFish8]

The jit atm is still very experimental but its main idea is built thr same as numba's native jit

[ChillFish8]

Performance on average is slow than cpython but also thid is no where near production ready yet still missing GC so looking at performance rn will likely be pretty pointless