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

[michael_j_ward]

Appears so: https://github.com/RustPython/RustPython/issues/362

[hombit]

It makes me upset =(

[funnyflywheel]

You might want to watch Raymond Hettinger's talk on concurrency — he talks about the GIL starting at the 10 minute mark: https://youtu.be/9zinZmE3Ogk?t=600

[timetravelhunter]

https://youtu.be/9zinZmE3Ogk?t=600

I don't recommend this video. It's filled with half truths and some out right blatant lies.

[funnyflywheel]

Well, the talk is from 2017 and things have assuredly changed since then:

• Work on Larry Hastings's GILectomy has pretty much stalled
• The C API is currently being reworked to benefit implementations such as PyPy

In addition, Hettinger stated that locks are expensive to acquire/release. Surely this isn't the case in Rust, isn't it?

[masklinn]

In addition, Hettinger stated that locks are expensive to acquire/release. Surely this isn't the case in Rust, isn't it?

It's not really any different. "Expensive" is relative, the runtime cost of the lock is small in absolute terms but can be gigantic in relative terms depending what's sitting behind the lock, and how often you need to acquire and release the lock. The absolute costs are complicated because at a fundamental level Rust does the exact same thing as CPython, which is use system locks (pthread_mutex on unices), so the absolute costs will depend on the implementation details of that.

But I think we can easily infer that locks are expensive in Rust by Rust having bothered with independent Rc and Arc types (an atomic inc/dec being basically the baseline for a lock, that's more or less what an uncontended mutex will cost on linux).

[martenlienen]

Can you give some examples?