3 ms·

Perhaps better coverage on LWN: https://lwn.net/Articles/872869/ https://lwn.net/Articles/872869/ The no-GIL version is actually about 8% slower on single-thr

by comex 5y ago

Perhaps better coverage on LWN: https://lwn.net/Articles/872869/ https://lwn.net/Articles/872869/ The no-GIL version is actually about 8% slower on single-threaded performance than the GIL version, but the author bundled in some unrelated performance improvements that make the no-GIL version overall 10% faster than today's Python.

qeternity 5y ago
This suggests that the unrelated patches improve perf by 20% (0.92 * 1.20 ~= 1.10) I would love to be proven wrong but I am skeptical.
- selcuka 5y ago
  That is already explained by the author [1]: > The resulting interpreter is about 9% faster than the no-GIL proof-of-concept (or ~19% faster than CPython 3.9.0a3). That 9% difference between the “nogil” interpreter and the stripped-down “nogil” interpreter can be thought of as the “cost” of the major GIL-removal changes. [1] https://docs.google.com/document/d/18CXhDb1ygxg-YXNBJNzfzZsDFosB5e6BfnXLlejd9l0/edit https://docs.google.com/document/d/18CXhDb1ygxg-YXNBJNzfzZsD...
  - qeternity 5y ago
    Thanks for this. It’s interesting because I think many people (myself included) would be far more interested in the perf patches than the GILectomy.
- guenthert 5y ago
  Why? It's not like CPython is a speed daemon. I'd think there are some low hanging fruits, simply because performance is such a low priority for the maintainers. It doesn't even do TCO after all.
vitus 5y ago
Subscriber link from Twitter if you (like me) ran into a paywall: https://lwn.net/SubscriberLink/872869/0e62bba2db51ec7a/ https://lwn.net/SubscriberLink/872869/0e62bba2db51ec7a/
- ignoramous 5y ago
  also: https://archive.is/1gLVY https://archive.is/1gLVY
Ph0X 5y ago
Right, the 20% boost is unrelated to the Gilectomy. > though, as Guido van Rossum noted, the Python developers could always just take the performance improvements without the concurrency work and be even faster yet. Why be 10% faster single threaded when you can be 20% faster single threaded!

by comex 5y ago

qeternity 5y ago

This suggests that the unrelated patches improve perf by 20% (0.92 * 1.20 ~= 1.10) I would love to be proven wrong but I am skeptical.

selcuka 5y ago
That is already explained by the author [1]: > The resulting interpreter is about 9% faster than the no-GIL proof-of-concept (or ~19% faster than CPython 3.9.0a3). That 9% difference between the “nogil” interpreter and the stripped-down “nogil” interpreter can be thought of as the “cost” of the major GIL-removal changes. [1] https://docs.google.com/document/d/18CXhDb1ygxg-YXNBJNzfzZsDFosB5e6BfnXLlejd9l0/edit https://docs.google.com/document/d/18CXhDb1ygxg-YXNBJNzfzZsD...
- qeternity 5y ago
  Thanks for this. It’s interesting because I think many people (myself included) would be far more interested in the perf patches than the GILectomy.
guenthert 5y ago
Why? It's not like CPython is a speed daemon. I'd think there are some low hanging fruits, simply because performance is such a low priority for the maintainers. It doesn't even do TCO after all.

vitus 5y ago

Subscriber link from Twitter if you (like me) ran into a paywall: https://lwn.net/SubscriberLink/872869/0e62bba2db51ec7a/ https://lwn.net/SubscriberLink/872869/0e62bba2db51ec7a/

ignoramous 5y ago
also: https://archive.is/1gLVY https://archive.is/1gLVY

Ph0X 5y ago

Right, the 20% boost is unrelated to the Gilectomy. > though, as Guido van Rossum noted, the Python developers could always just take the performance improvements without the concurrency work and be even faster yet. Why be 10% faster single threaded when you can be 20% faster single threaded!