On 21.06.2020 01:47, Guido van Rossum wrote:
Hm, I remember Greg's free threading too, but that's not the idea I was trying to recall this time. There really was something about bytecode objects being loaded from a read-only segment to speed up code loading. (Much quicker than unmarshalling a .pyc file.) I don't think we ever got the details worked out to the point where we could benchmark.
Perhaps you are thinking about reading byte code from C arrays, as is done when freezing Python modules. I'm using this logic in PyRun to freeze (more or less) the entire Python stdlib. It does have some effect on startup time and due to the OS typically sharing such static code segments between processes helps a bit when you run multiple processes, but since the C arrays only store byte code and not code objects, you still need to create code objects and store a copy of the byte code in memory for every single process. This could probably be optimized by having the code object point to the C array to hold the byte code data, but I haven't looked into that. I mainly use PyRun for packaging Python based products for distribution on Linux and as a replacement for virtualenv which doesn't rely on system Python installations, not so much to speed up anything.
On Sat, Jun 20, 2020 at 4:57 AM Jonathan Fine <jfine2358@gmail.com <mailto:jfine2358@gmail.com>> wrote:
Hi All
Guido wrote:
I remember vaguely that about two decades ago Greg Stein hatched an idea for code objects loaded from a read-only segment in shared libraries.
[Thank you for this, Guido. Your memory is good.]
Here's a thread from 2009, where Guido said: Greg Stein reached this same conclusion (and similar numbers) over 10 years ago ...
Subject: Remove GIL with CAS instructions? https://mail.python.org/archives/list/python-ideas@python.org/thread/6ZONFLM...
I looked up https://en.wikipedia.org/wiki/Compare-and-swap to read about CAS.
Guido said this in the context of Antione's statement: Which makes me agree with the commonly expressed opinion that CPython would probably need to ditch refcounting (at least in the critical paths) if we want to remove the GIL.
In 2007 Guido posted to Artima: It isn't Easy to Remove the GIL: https://www.artima.com/weblogs/viewpost.jsp?thread=214235
In this post Guido writes: In 1999 Greg Stein (with Mark Hammond?) produced a fork of Python (1.5 I believe) that removed the GIL, replacing it with fine-grained locks on all mutable data structures. [...] However, after benchmarking, it was shown that even on the platform with the fastest locking primitive (Windows at the time) it slowed down single-threaded execution nearly two-fold.
Guido also referenced this write-up from Greg: https://mail.python.org/pipermail/python-dev/2001-August/017099.html
I hope this helps.
-- Jonathan
-- --Guido van Rossum (python.org/~guido <http://python.org/~guido>) /Pronouns: he/him //(why is my pronoun here?)/ <http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-change-the-world/>
_______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-leave@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/7XTH3P... Code of Conduct: http://python.org/psf/codeofconduct/
-- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Experts (#1, Jun 21 2020)
Python Projects, Coaching and Support ... https://www.egenix.com/ Python Product Development ... https://consulting.egenix.com/
::: We implement business ideas - efficiently in both time and costs ::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 https://www.egenix.com/company/contact/ https://www.malemburg.com/