RustPython Is Implementing Python 3 Within Rust

[SimonK]

Graal (http://www.graalvm.org) also provides a Python implementation on top of the JVM. Its implementation is interesting: Graal uses the Truffle framework which takes a basic interpreter for any language and converts it into an optimised JIT compiler. Interestingly, graal/truffle also has an interpreter for LLVM bytecode - and through this can support c-language python extensions.

[Michael_S]

Another thing is that with a more rigorous memory management, this new interpreter might be able to reduce reliance on dynamic garbage collecting (the Python language will always require some form of GC, but the interpreter itself may be able to streamline it), which would theoretically allow it to provide better support for multithreading by avoiding the GIL.

I thought the default Python implementation uses reference counting? That's not really dynamic garbage collecting, but it is very slow.

[fuzz]

These days I pretty much us pypy everywhere I can and target python 3.5 as a result. Would love to see them take some hints from that project and also work on the GIL issues.

[Michael_S]

Btw: I don't understand the meaning of "dynamic GC". What would "static GC" mean: compile-time GC without any GC at runtime (it is achievable for some programs)?

Good point. I should have dropped "dynamic".

In my opinion, optimized reference counting isn't necessarily slow because an advanced compiler can sometimes elide refcount updates. In CPython, it is slow because neither the bytecode nor the interpreter have explicit inc/dec refcount instructions, which makes it impossible to elide them, and consequently every object pointer assignment has to update two refcounts.

Escape analysis is able to put objects onto the stack to avoid heap allocations.

My wild guess is that it's not practical to do that kind of advanced analysis of code to elide refcount updates in a scripting language. If someone invents a dialect of Python that compiles to binary executables, I imagine it can be done. But if you launch a 15,000 line Python program that is not precompiled and the startup time is equivalent to the time it takes to do a clean compile of an equivalent C program, users will run away screaming.

An advantage of reference counting is much lower memory consumption compared to deferred garbage collection strategies, unless the object graph contains cycles.

Good point.

I know that garbage collection is the bogey man to a lot of long time C or C++ developers and there are definitely environments where memory is tightly constrained and GC flat out can't be used. But GC technology is still improving and it looks like the Java Virtual Machine is leading or close to leading the way. The JVM G1GC garbage collector seems to be best for total throughput on average. For latency, the JVM Shenandoah GC can do sub 10ms pauses on 100GB heaps: http://openjdk.java.net/jeps/189 . There is also the JVM Z Garbage Collector: http://openjdk.java.net/jeps/333 - in a benchmark with a 128GB heap, max pause time was 1.681ms. The ZGC is currently Linux/x64 only, but once it's on other platforms Call of Duty: Black Ops 6 could be written in it.

[Vistaus]

At last, a project that is uid313 proof

[uid313]

At last, a project that is uid313 proof

I don't really care for Python 3 in Rust. Can as well be CPython or PyPy.
Where I care about Rust is decoders.

[Michael_S]

Thanks for the information.

Also Go 1.8+ has sub-millisecond (500µs) pauses on large (18GiB) heaps: https://blog.golang.org/ismmkeynote

I forgot that Go has such small garbage collection pauses. That's really impressive. On the other hand, on the larger topic of garbage collection the reason I consider the JVM ahead of Go is articulated here: https://blog.plan99.net/modern-garba...n-911ef4f8bd8e

[ssokolow]

I thought the default Python implementation uses reference counting? That's not really dynamic garbage collecting, but it is very slow.

It uses refcounting with a minimal GC for catching reference cycles. If you're sure you're not creating reference cycles, you can improve that aspect of performance with import gc followed by gc.disable()

Good point. I should have dropped "dynamic".

One could argue that what Rust does is static GC. It is basically doing unreachability analysis at compile time.

[Michael_S]

One could argue that what Rust does is static GC. It is basically doing unreachability analysis at compile time.

Thanks. I did know that, one of the major contributors sparked a big discussion on Hackernews and Reddit Programming by suggesting it. I don't know if he originated that label for the concept or not.

[jacob]

I wonder how this would turn out. I tried suggesting a Rusted-Ruby, but there aren't that much interest.

It's probably because Ruby is more of a niche language. Its use revolves pretty much around the Rails and Metasploit frameworks, but outside of these areas its community is much smaller than Python's. However the two languages are conceptually very similar so I guess if a corroded Python is a success, the accumulated experience should make the potential subsequent development of a corroded Ruby a lot easier.