[Python-ideas] Re: Improved multi-tasking performance through deterministic GIL hand-off
I'm currently learning about the GIL and how can it be removed. So I'm confessing that I understood only half of your words and I can be wrong. As far I understood by reading your long passage, the problem is other threads don't get enough chance to run and the CPU-Bound Python process will re-acquire the GIL right? If that's what you're trying to say, Antoine Pitrou already solved this by implementing the "new gil" which tells that before reacquiring the GIL make sure that other threads have a chance to run. However as I confessed earlier I can be wrong and I misunderstood what you're trying to say. Please correct me if that's the case. ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@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/DWGJ7RKWEVF53VDUQ5ZADYJC5OK43XYV/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Barrier Object in asyncio lib
Hello! If anyone didn't note, there's a PR about this topic :) https://github.com/python/cpython/pull/24903 Cheers! ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@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/EXG2DUDTWZHCVPIBRQASWLCC42YKRHWH/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Add a mechanism so that multiple exceptions can be caught using `except E1, E2, E3:`
On 10/05/2021 12:43, Chris Angelico wrote:
On Mon, May 10, 2021 at 9:36 PM Steven D'Aprano wrote:
On Mon, May 10, 2021 at 10:04:58AM +1000, Chris Angelico wrote:
On Mon, May 10, 2021 at 9:57 AM Steven D'Aprano wrote:
[...]
Is there an aim beyond saving two characters?
It would remove a level of frustration. I've watched a lot of novice
programmers, and some intermediate programmers, run into a source of
(now completely unnecessary) pain that changing this:
except ValueError:
into this:
except ValueError, TypeError:
doesn't work. Yes, it's a quick SyntaxError,
You say it is completely unnecessary, but is it? The way `as` currently
works and the way this proposal will have it work are just different
enough to make me fret.
import spam, eggs, cheese, aardvark as hovercraft
with spam, eggs as f
except ValueError, KeyError, TypeError as err
How long will it be before people, fooled by the similarity to other
uses of `as`, try writing this:
except ValueError as verr, KeyError as kerr, TypeError as terr
and how soon after that before people propose it as an actual feature?
but the editor won't show
it up (since most editors are Python 2 compatible, and wouldn't be
checking this level of syntax anyway), so there's X amount of time
spent coding, then go to run the thing, and it won't work the way they
expect it to.
"My editor doesn't recognise this error" is not a strong argument in
favour of a change that otherwise adds no new functionality.
If it weren't for the Python 2 issues, would there be any good reason
for demanding parentheses? We don't need them in a for loop:
for i, thing in enumerate(stuff):
True, but we do need them here:
[1,x for x in range(3)]
even though there is only one possible interpretation of the code. It
can't be `[1, generator]` because the hypothetical generator expression
isn't parenthesized.
Sometimes we require parens as a "belts and braces" sort of thing.
There's no *actual* syntactic ambiguity, but we require the parens just
to be sure:
a := len('abc')
File "", line 1
a := len('abc')
^
SyntaxError: invalid syntax
(a := len('abc'))
3
I feel the same about this proposal. Without the brackets grouping the
exceptions, it feels too close to binding only the last one in the group
rather than the entire tuple of exceptions.
What if the parens could be omitted only if there's no 'as' clause?
That eliminates the ambiguity. Is it really necessary to clarify what
"except TypeError, ValueError:" means, either to the interpreter or to
another programmer? Every objection has been based on the confusion of
"except TypeError, ValueError as e:", and I agree with that.
+0.9. A practical solution, although it makes the language definition
more complicated. Practicality beating purity.
Rob Cliffe
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@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/7PRV7OMPN52GOFF6HLNPCCD7FBE3MQ2J/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Improved multi-tasking performance through deterministic GIL hand-off
> On 10 May 2021, at 20:23, Barry Scott wrote: > > > >> On 10 May 2021, at 15:30, Sophist wrote: >> >> I don't know how many people will remember some work that David Beazley did >> about a decade ago on how the GIL impacts multithreading performance - >> essentially he instrumented the Python interpreter to log how multiple >> threads competed for the GIL and gave several presentations over the space >> of 2-3 years. A couple of years ago I reached out to him with an idea on how >> to significantly improve the way that Python handles multi-threading >> hand-off of the GIL, but unfortunately he was not interested in pursuing >> this further. I am raising it here in the hope that someone else would be >> interested in implementing this. >> >> In essence my idea is to stop Python handing off the GIL through a >> competition between threads that are ready to run, and instead for Python to >> implement a scheduler for the GIL which decides which thread should get the >> GIL next and directly hands it over. >> >> Background >> >> Here are the links to David Beazley's presentations: >> >> 2009: Inside the Python GIL - >> https://www.youtube.com/watch?v=ph374fJqFPE >> 2010: Understanding the Python GIL- >> https://speakerdeck.com/dabeaz/understanding-the-python-gil >> https://www.youtube.com/watch?v=Obt-vMVdM8s >> 2011: Embracing the Global Interpreter Lock - >> https://speakerdeck.com/dabeaz/embracing-the-global-interpreter-lock >> https://www.youtube.com/watch?v=fwzPF2JLoeU >> 2011: In Search of the Perfect Global Interpreter Lock - >> https://speakerdeck.com/dabeaz/in-search-of-the-perfect-global-interpreter-lock >> https://www.youtube.com/watch?v=5jbG7UKT1l4 > > Given this is very old information I think the first thing needed is to > reproduce David's experiments and see if the 3.10 implementation has the same > issues. > > Have you done this already? > > If you turn these slides into benchmark code that would make it easier to > experiment with. > > Benchmarks will need running on macOS, Windows, Linux at least. It looks like the GIL code has not changed in a long time. But for 3.7 FORCE_SWITCHING is always defined that changes the GIL behaviour. This comment in Python/ceval_gil.h explains what that does: - When a thread releases the GIL and gil_drop_request is set, that thread ensures that another GIL-awaiting thread gets scheduled. It does so by waiting on a condition variable (switch_cond) until the value of last_holder is changed to something else than its own thread state pointer, indicating that another thread was able to take the GIL. This is meant to prohibit the latency-adverse behaviour on multi-core machines where one thread would speculatively release the GIL, but still run and end up being the first to re-acquire it, making the "timeslices" much longer than expected. (Note: this mechanism is enabled with FORCE_SWITCHING above) Barry ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@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/RPRFINFGHOMYOVQSEA64PXOVGQGVURLQ/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Improved multi-tasking performance through deterministic GIL hand-off
> On 10 May 2021, at 15:30, Sophist wrote: > > I don't know how many people will remember some work that David Beazley did > about a decade ago on how the GIL impacts multithreading performance - > essentially he instrumented the Python interpreter to log how multiple > threads competed for the GIL and gave several presentations over the space > of 2-3 years. A couple of years ago I reached out to him with an idea on how > to significantly improve the way that Python handles multi-threading hand-off > of the GIL, but unfortunately he was not interested in pursuing this further. > I am raising it here in the hope that someone else would be interested in > implementing this. > > In essence my idea is to stop Python handing off the GIL through a > competition between threads that are ready to run, and instead for Python to > implement a scheduler for the GIL which decides which thread should get the > GIL next and directly hands it over. > > Background > > Here are the links to David Beazley's presentations: > > 2009: Inside the Python GIL - > https://www.youtube.com/watch?v=ph374fJqFPE > 2010: Understanding the Python GIL- > https://speakerdeck.com/dabeaz/understanding-the-python-gil > https://www.youtube.com/watch?v=Obt-vMVdM8s > 2011: Embracing the Global Interpreter Lock - > https://speakerdeck.com/dabeaz/embracing-the-global-interpreter-lock > https://www.youtube.com/watch?v=fwzPF2JLoeU > 2011: In Search of the Perfect Global Interpreter Lock - > https://speakerdeck.com/dabeaz/in-search-of-the-perfect-global-interpreter-lock > https://www.youtube.com/watch?v=5jbG7UKT1l4 Given this is very old information I think the first thing needed is to reproduce David's experiments and see if the 3.10 implementation has the same issues. Have you done this already? If you turn these slides into benchmark code that would make it easier to experiment with. Benchmarks will need running on macOS, Windows, Linux at least. Barry ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@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/AUASYYYOMQGGWLHOPMP4J5RGRQTDYCAK/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Improved multi-tasking performance through deterministic GIL hand-off
I don't know how many people will remember some work that David Beazley did about a decade ago on how the GIL impacts multithreading performance - essentially he instrumented the Python interpreter to log how multiple threads competed for the GIL and gave several presentations over the space of 2-3 years. A couple of years ago I reached out to him with an idea on how to significantly improve the way that Python handles multi-threading hand-off of the GIL, but unfortunately he was not interested in pursuing this further. I am raising it here in the hope that someone else would be interested in implementing this. In essence my idea is to stop Python handing off the GIL through a competition between threads that are ready to run, and instead for Python to implement a scheduler for the GIL which decides which thread should get the GIL next and directly hands it over. Background Here are the links to David Beazley's presentations: 2009: Inside the Python GIL - https://www.youtube.com/watch?v=ph374fJqFPE 2010: Understanding the Python GIL- https://speakerdeck.com/dabeaz/understanding-the-python-gil https://www.youtube.com/watch?v=Obt-vMVdM8s 2011: Embracing the Global Interpreter Lock - https://speakerdeck.com/dabeaz/embracing-the-global-interpreter-lock https://www.youtube.com/watch?v=fwzPF2JLoeU 2011: In Search of the Perfect Global Interpreter Lock - https://speakerdeck.com/dabeaz/in-search-of-the-perfect-global-interpreter-lock https://www.youtube.com/watch?v=5jbG7UKT1l4 The Problem A currently executing thread can give up the GIL (essentially) for two reasons: A) It has started a blocking operation (like a reading data from disk) and is no longer runnable; or B) because it is using a lot of CPU and has reached a Python CPU timeout (nothing to do with the O/S scheduler time-slice) and is still runnable. When the currently executing thread wants to give up the GIL, the current competitive approach essentially sends a signal to all runnable threads that the GIL is now available and the first thread to grab it gets to execute with the GIL. The problem with this (at least as I understand it) is that all threads except the thread that has just given up the GIL are not actually running on a CPU and need the O/S Scheduler to dispatch them before they can run, but the current thread is already running - so if the currently executing thread is is still runnable i.e. because it has reached the Python CPU timeout, then it is highly likely to be the first to grab the GIL back again. This leads to CPU-heavy threads dominating the CPU usage, and the I/O threads being starved out - and this is the opposite of what O/S Scheduling Theory says is optimum - which is to run the I/O threads first to keep the data flowing and everything responsive, typically using low levels of CPU, and let the CPU heavy threads mop up the remaining CPU. But even if the currently executing CPU heavy thread doesn't grab the GIL again, there is no guarantee that the most appropriate of the other threads will grab it instead. It should also be noted that this competitive approach has a lot of overhead - because every thread wakes up to try to compete for the GIL. Proposed Solution My proposed solution is for Python to implement its own (light-weight) scheduling system for the GIL - maintaining a list of threads that are runnable and whether they are I/O bound (gave up the GIL because they became non-runnable due to blocking I/O or waiting for a signal) or CPU heavy (gave up the GIL because of reaching the Python timeout). Ideally we would also add functionality to Python to allow you to specify a thread priority (ideally adjusting the O/S thread priority to match) and we would also retain this priority as part of the GIL scheduling. As far as I can see this proposal is complementary to the current work on sub-interpreters - because there is a big base of existing code which would immediately benefit from these changes without any coding changes. The solution I have in mind is this: a. A scheduling queue is created with its own mutex. The reason for having a separate mutex is that threads can add themselves to the queue without needing to obtain the GIL. b. The queue consists of a tree with the following branches: i) A list of thread priorities, decreasing order ii) Two subqueues: I/O bound, CPU bound iii) Each has a FIFO list of runnable threads When a thread is created, it is assumed to be I/O bound and is added to the back of the appropriate queue. When the GIL is given up, if the currently executing thread is still runnable (reached the Python timeout) it adds itself to the back of the appropriate queue. It then takes the first runnable thread in the queue (highest priority, I/O bound if non empty, otherwise CPU bound) and signals that thread to take
[Python-ideas] OT: Accessibility: Jana Schroeder's Holman Prize Application
Perhaps Off Topic, but for a good cause. This year I met Jana Scroeder, a blind person forced to change jobs as part of the social cost of Covid. Her outsider experience of computer coding training became a wish to make things better. She has applied for a Holman Prize ($25,000 over a year) to fund this. She's also set up a survey to reach and know better those with similar wishes. One simple way to help open to many is to volunteer to be a sighted helper for a code and math variant of BeMyEyes.org. I encourage you to listen to Jana's pitch for a Holman prize, and if you want to help complete the survey (whether you're blind or sighted, code or math, young or old). I've learnt a lot about accessibility from Jana. *Jana Schroeder's Holman pitch* (90 seconds): https://www.youtube.com/watch?v=3ywl5d162vU *Jana Schroeder's survey* (15 minutes): https://tinyurl.com/blindcodersurvey Finally, *The Holman Prize*: https://holman.lighthouse-sf.org/ best regards Jonathan ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@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/J67MRND6SQMPXTRNSJMSD2ZKGNEELKVJ/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Add a mechanism so that multiple exceptions can be caught using `except E1, E2, E3:`
how about: ``` try: ... except E1 | E2 | E3 as e: ... ``` it's syntactically valid but is this again: https://bugs.python.org/issue12029 ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@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/MKUMC6CCGLRY6IJJF2WD6CSMQUZN5Z2Q/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Add a mechanism so that multiple exceptions can be caught using `except E1, E2, E3:`
On Mon, May 10, 2021 at 9:36 PM Steven D'Aprano wrote:
>
> On Mon, May 10, 2021 at 10:04:58AM +1000, Chris Angelico wrote:
> > On Mon, May 10, 2021 at 9:57 AM Steven D'Aprano wrote:
>
> [...]
> > > Is there an aim beyond saving two characters?
>
> > It would remove a level of frustration. I've watched a lot of novice
> > programmers, and some intermediate programmers, run into a source of
> > (now completely unnecessary) pain that changing this:
> >
> > except ValueError:
> >
> > into this:
> >
> > except ValueError, TypeError:
> >
> > doesn't work. Yes, it's a quick SyntaxError,
>
> You say it is completely unnecessary, but is it? The way `as` currently
> works and the way this proposal will have it work are just different
> enough to make me fret.
>
> import spam, eggs, cheese, aardvark as hovercraft
>
> with spam, eggs as f
>
> except ValueError, KeyError, TypeError as err
>
> How long will it be before people, fooled by the similarity to other
> uses of `as`, try writing this:
>
> except ValueError as verr, KeyError as kerr, TypeError as terr
>
> and how soon after that before people propose it as an actual feature?
>
>
> > but the editor won't show
> > it up (since most editors are Python 2 compatible, and wouldn't be
> > checking this level of syntax anyway), so there's X amount of time
> > spent coding, then go to run the thing, and it won't work the way they
> > expect it to.
>
> "My editor doesn't recognise this error" is not a strong argument in
> favour of a change that otherwise adds no new functionality.
>
>
> > If it weren't for the Python 2 issues, would there be any good reason
> > for demanding parentheses? We don't need them in a for loop:
> >
> > for i, thing in enumerate(stuff):
>
> True, but we do need them here:
>
> [1,x for x in range(3)]
>
> even though there is only one possible interpretation of the code. It
> can't be `[1, generator]` because the hypothetical generator expression
> isn't parenthesized.
>
> Sometimes we require parens as a "belts and braces" sort of thing.
> There's no *actual* syntactic ambiguity, but we require the parens just
> to be sure:
>
> >>> a := len('abc')
> File "", line 1
> a := len('abc')
>^
> SyntaxError: invalid syntax
> >>> (a := len('abc'))
> 3
>
>
> I feel the same about this proposal. Without the brackets grouping the
> exceptions, it feels too close to binding only the last one in the group
> rather than the entire tuple of exceptions.
>
What if the parens could be omitted only if there's no 'as' clause?
That eliminates the ambiguity. Is it really necessary to clarify what
"except TypeError, ValueError:" means, either to the interpreter or to
another programmer? Every objection has been based on the confusion of
"except TypeError, ValueError as e:", and I agree with that.
ChrisA
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@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/Z43NB4QKWPP5X7HTSE4VG3YJ5XQENVY2/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Add a mechanism so that multiple exceptions can be caught using `except E1, E2, E3:`
On Mon, May 10, 2021 at 10:04:58AM +1000, Chris Angelico wrote:
> On Mon, May 10, 2021 at 9:57 AM Steven D'Aprano wrote:
[...]
> > Is there an aim beyond saving two characters?
> It would remove a level of frustration. I've watched a lot of novice
> programmers, and some intermediate programmers, run into a source of
> (now completely unnecessary) pain that changing this:
>
> except ValueError:
>
> into this:
>
> except ValueError, TypeError:
>
> doesn't work. Yes, it's a quick SyntaxError,
You say it is completely unnecessary, but is it? The way `as` currently
works and the way this proposal will have it work are just different
enough to make me fret.
import spam, eggs, cheese, aardvark as hovercraft
with spam, eggs as f
except ValueError, KeyError, TypeError as err
How long will it be before people, fooled by the similarity to other
uses of `as`, try writing this:
except ValueError as verr, KeyError as kerr, TypeError as terr
and how soon after that before people propose it as an actual feature?
> but the editor won't show
> it up (since most editors are Python 2 compatible, and wouldn't be
> checking this level of syntax anyway), so there's X amount of time
> spent coding, then go to run the thing, and it won't work the way they
> expect it to.
"My editor doesn't recognise this error" is not a strong argument in
favour of a change that otherwise adds no new functionality.
> If it weren't for the Python 2 issues, would there be any good reason
> for demanding parentheses? We don't need them in a for loop:
>
> for i, thing in enumerate(stuff):
True, but we do need them here:
[1,x for x in range(3)]
even though there is only one possible interpretation of the code. It
can't be `[1, generator]` because the hypothetical generator expression
isn't parenthesized.
Sometimes we require parens as a "belts and braces" sort of thing.
There's no *actual* syntactic ambiguity, but we require the parens just
to be sure:
>>> a := len('abc')
File "", line 1
a := len('abc')
^
SyntaxError: invalid syntax
>>> (a := len('abc'))
3
I feel the same about this proposal. Without the brackets grouping the
exceptions, it feels too close to binding only the last one in the group
rather than the entire tuple of exceptions.
--
Steve
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@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/PDSS7VQ26UTOLXBJDJDS5UKAYBZWGHFY/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Add a mechanism so that multiple exceptions can be caught using `except E1, E2, E3:`
+1 and -1 at the same time. I feel like :- "This makes sense", try: # something except E1, E2, E3: # something "This doesn't make sense", try: # something except E1, E2, E3 as e: # something The second one according to this idea would be parsed as, try: # something except (E1, E2, E3) as e: # something Though it would seem this way to people, try: # something except E1, E2, (E3 as e): # something The first example I gave is much more logical. Because (E1, E2, E3) and E1, E2, E3 are the same thing logically. ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@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/J7FUCBFV2TPA7SY3DYNPEBGZ354CYNFR/ Code of Conduct: http://python.org/psf/codeofconduct/
