3 ms·
There was a question from Shannon about ""what people think is a acceptable slowdown for single-threaded code"" ... he had estimated an impact "in the 1
by TekMol 3y ago
There was a question from Shannon about ""what people think is a
acceptable slowdown for single-threaded code"" ... he had estimated
an impact "in the 15-20% range"
Horror!
To me, the acceptable slowdown is exactly zero.
I can already use multiple cores by running multiple Python processes.
Any slowdown of single-process performance would be a terrible step backwards.
Python is already slow. It should look at PHP and see what it can take out of their book. PHP 7, which had no JIT, was already about 6x faster than Python. PHP 8 is even faster for some workloads. I'm not sure if the overhead of a JIT makes sense though. But PHP 7 is a good place to look for a performance benchmark.
- deleted 3y ago[deleted]
- dagw 3y agoTo me, the acceptable slowdown is exactly zero. This has been the reason most of the previous GIL removal projects failed. GvR had a strict zero slowdown in single-thread performance rule for any nogil patches and none of them managed that. I wonder if the core team has decided to abandon that rule now that GvR is gone?
- alecmg 3y agoI saw comments that if introduced together with Faster CPython single thread performance optimisations, nogil would end up no slower than previous version. So it is best time to implement
- ohgodplsno 3y ago>I can already use multiple cores by running multiple Python processes. Because you have terribly simple processes that don't need to do synchronization. Even a simple parallel map would have Python scream and kick, because the GIL prevents it from having any kind of reasonable performance, and your multiprocess can't handle that unless they all write to files.
- pkolaczk 3y ago> Horror! To me, the acceptable slowdown is exactly zero. If you care about single % of performance, why are you using Python in the first place? You're likely losing 100x to more performant languages already.
- TekMol 3y agoBecause I care about elegance of code and developer productivity even more. And there is no other language which comes close to Python in these regards.
- pkolaczk 3y agoElegance of code is subjective and developer productivity is more a trait of a developer than a language (which means it is inherently subjective, e.g. in my case Python is among the languages I was least productive in; I find myself much more productive in Scala, Kotlin, Rust and even R for statistics).
- talideon 3y agoPHP doesn't have the same constraints around it as Python. With Python, you have long-running threads of execution, while this is rarely the case in PHP. PHP has no shared state outside of the interpreter, so it's inherently GIL-less. PHP got threads late and as an extension. The issues with the GIL centre around the C extension API. PHP doesn't have to deal with that, so they were able to concentrate on making single threaded performance as good as possible. The GIL also blocks some potential avenues around making single threaded performance better, which is why the plan for this current attempt is to make it opt-in. Also keep in mind that all this is happening concurrently with efforts around making single threaded performance better, with the idea bring that any loss of performance due to the GIL removal should be compensated by other speed improvements. If we could go back in time and make the C API more like that of, say, Lua, that would solve the issue, but we can't.