[issue44130] GIL Improvement

Change by Shreyan Avigyan : -- resolution: -> wont fix ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https

[issue44130] GIL Improvement

Shreyan Avigyan added the comment: I suspected right. This was just CPU instability. In fact the patch is 1x-2x slower as reported by pyperf. Therefore I'm closing this issue. Though I'm working on another "yet to be failed attempt" to remove or rewrite the GIL to improve performance. Of co

[issue44130] GIL Improvement

STINNER Victor added the comment: > Mean +- std dev: 455 ms +- 13 ms A single benchmark is useless without a reference. Please run the benchmark on unpatched python, then run it again on a patched Python, and compare results. You can store benchmark results using -o option. Example: # Unpat

[issue44130] GIL Improvement

Shreyan Avigyan added the comment: pyperf results - Mean +- std dev: 455 ms +- 13 ms Looks a little bit faster than current 3.11, 3.10 and 3.9 versions. -- ___ Python tracker __

[issue44130] GIL Improvement

STINNER Victor added the comment: > I attached the pyperf benchmark also. Can you please provide pyperf_benchmark.py results? -- ___ Python tracker ___ __

[issue44130] GIL Improvement

Shreyan Avigyan added the comment: I attached the pyperf benchmark also. -- Added file: https://bugs.python.org/file50041/benchmark.py ___ Python tracker ___ _

[issue44130] GIL Improvement

Shreyan Avigyan added the comment: Sure -- ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.pyth

[issue44130] GIL Improvement

Christian Heimes added the comment: The benchmark code has multiple issues. For example it uses a bad clock sources, time.time(). Could you please rewrite the benchmark to use https://pypi.org/project/pyperf/ ? -- ___ Python tracker

[issue44130] GIL Improvement

Shreyan Avigyan added the comment: > "That difference is 0.02 seconds, or about 1%, correct?" I mistook 1.98 as 1.88 in my calculation. Sorry for that. > The information is not very helpful to understand what you are doing. Please > provide your system specs (arch, platform, CPU spec, me

[issue44130] GIL Improvement

Shreyan Avigyan added the comment: Test suite passed and also I'm attaching the benchmark I used to measure. (This is the benchmark used by David Beazley in one of his famous GIL blog posts and talks.) -- Added file: https://bugs.python.org/file50040/benchmark.py ___

[issue44130] GIL Improvement

Eric V. Smith added the comment: "If it ran in 1.98 secs then the new patch would theoretically measure 1.96 (original - 0.22)" That difference is 0.02 seconds, or about 1%, correct? I'm just trying to understand what we're measuring here. -- ___

[issue44130] GIL Improvement

Christian Heimes added the comment: The information is not very helpful to understand what you are doing. Please provide your system specs (arch, platform, CPU spec, memory), the commands you used to compile Python and the commands you used to get the numbers --

[issue44130] GIL Improvement

Shreyan Avigyan added the comment: I took the measurement like this. If it ran in 1.98 secs then the new patch would theoretically measure 1.96 (original - 0.22). The patch isn't very useful but it can sometimes be faster than the present code especially in debug mode. -- _

[issue44130] GIL Improvement

Eric V. Smith added the comment: "there's an increase in speed by 0.22 or something like that" 0.22 what? Seconds? Percent? A factor of 0.22? What are you measuring, and how are you measuring it? -- nosy: +eric.smith ___ Python tracker

[issue44130] GIL Improvement

Shreyan Avigyan added the comment: Forgot to do that. I'll report back with the test suite result. -- ___ Python tracker ___ ___ Py

[issue44130] GIL Improvement

Christian Heimes added the comment: Does Python's unit test suite pass? -- nosy: +christian.heimes, pitrou, vstinner ___ Python tracker ___ ___

[issue44130] GIL Improvement

Shreyan Avigyan added the comment: Instability is more likely. But I'll run the benchmark once more and see what is happening. -- ___ Python tracker ___ _

[issue44130] GIL Improvement

New submission from Shreyan Avigyan : Today while working on an attempt to improve the GIL (either by modifying it or removing it) I noticed that in destroy_gil function first we unlock the mutex and then we set the gil->locked to -1 using _Py_atomic_store_explicit. Therefore the cycle is, "U