Re: [Python-Dev] "Fixing" the new GIL

There is no need for the "forced" switch to be guaranteed. The motivation for the wait is to increase throughput and decrease latency when OS schedules next thread to run on same core as yielding thread but yielding thread is about to continue running into CPU intensive library code. An occasional

Re: [Python-Dev] "Fixing" the new GIL

That code will not switch to another thread if the condition variable either does not actually block the thread on the call (which is allowed by the standard to give implementations some flexibility for making it work correctly ­ read the standard reasoning for more information), or the thread is w

Re: [Python-Dev] "Fixing" the new GIL

Please describe clearly a step by step scenario in which that code will fail. On Mon, Apr 12, 2010 at 10:25 PM, Peter Portante wrote: > Yes, but unless you loop until the predicate is False, no forced switch > is guaranteed to occur. You might as well remove the code. If you want to > keep the

Re: [Python-Dev] "Fixing" the new GIL

Yes, but unless you loop until the predicate is False, no forced switch is guaranteed to occur. You might as well remove the code. If you want to keep the code as is, call me when you need a life guard to help debug mystifying behaviors. ;) -peter On 4/12/10 3:17 PM, "Nir Aides" wrote: > The lo

Re: [Python-Dev] "Fixing" the new GIL

At some point there was a loop, later it remained since I feel it is more readable than a bunch of nested if-else clauses. Should probably replace with do {...} while(0) I was conditioned with electrical shocks in the dungeons of a corporate to always use for loops. I uploaded the patch to Rietve

Re: [Python-Dev] "Fixing" the new GIL

The loop-less wait is similar to the one in new GIL. It is used to force a switch to next thread in particular scenario and the motivation is explained in comment to another if clause a few lines up. Those two if clauses can be joined though. On Mon, Apr 12, 2010 at 3:37 PM, Peter Portante wrote:

Re: [Python-Dev] "Fixing" the new GIL

And why the for(;;) loop in bfs_schedule()? I don¹t see a code path that would loop there. Perhaps I am missing it ... -peter On 4/12/10 8:37 AM, "Peter Portante" wrote: > Hmm, so I see in bfs_yield(): > > +if (tstate != NULL && bfs_thread_switch == tstate) { > +COND_RESET(tstate-

Re: [Python-Dev] "Fixing" the new GIL

Hmm, so I see in bfs_yield(): +if (tstate != NULL && bfs_thread_switch == tstate) { +COND_RESET(tstate->bfs_cond); +COND_WAIT(tstate->bfs_cond, bfs_mutex); +} So, to me, the above code says, ³Wait for the condition that tstate is either NULL, or bfs_thread_switch does not

Re: [Python-Dev] "Fixing" the new GIL

Hi Peter, There is no need for a loop in bfs_yield(). On Mon, Apr 12, 2010 at 4:26 AM, Peter Portante wrote: > Nir, > > Per the POSIX standard, both pthread_cond_wait() and > pthread_cond_timedwait() need to be performed in a loop. See the fourth > paragraph of the description from: > > > htt

Re: [Python-Dev] "Fixing" the new GIL

Nir, Per the POSIX standard, both pthread_cond_wait() and pthread_cond_timedwait() need to be performed in a loop. See the fourth paragraph of the description from: > http://www.opengroup.org/onlinepubs/95399/functions/pthread_cond_timedwait > .html For the Windows side, I think you have a

Re: [Python-Dev] "Fixing" the new GIL

Hello all, I would like to kick this discussion back to life with a simplified implementation of the BFS scheduler, designed by the Linux kernel hacker Con Kolivas: http://ck.kolivas.org/patches/bfs/sched-BFS.txt I submitted bfs.patch at http://bugs.python.org/issue7946. It is work in progress bu

Re: [Python-Dev] "Fixing" the new GIL

gt; Robert Hancock > Sent: 16. mars 2010 20:10 > To: Peter Portante > Cc: David Beazley; python-dev@python.org > Subject: Re: [Python-Dev] "Fixing" the new GIL > > The Linux kernel scheduler deals with two types of ratings and has a > heuristic algorithm that rewards

Re: [Python-Dev] "Fixing" the new GIL

> -Original Message- > From: Nick Coghlan [mailto:ncogh...@gmail.com] > Sent: 16. mars 2010 22:08 > To: Kristján Valur Jónsson > Cc: Antoine Pitrou; python-dev@python.org > Subject: Re: [Python-Dev] "Fixing" the new GIL > > Kristján Valur Jónsson

Re: [Python-Dev] "Fixing" the new GIL

:10 To: Peter Portante Cc: David Beazley; python-dev@python.org Subject: Re: [Python-Dev] "Fixing" the new GIL The Linux kernel scheduler deals with two types of ratings and has a heuristic algorithm that rewards and penalizes on a rapid basis. To determine the next thread it in

Re: [Python-Dev] "Fixing" the new GIL

; ticking going on. >> > 3) There isn't an immediate gil request made when an IO thread requests >> the gil back, only after an initial timeout. >> > >> > What we are trying to write here is a thread scheduler, and th

Re: [Python-Dev] "Fixing" the new GIL

> You can't. This isn't an example where I am personally bitten by the GIL. > I may be, but there's plenty of other stuff in terms of tuning or > optimisation in my particular app before I get anywhere near the GIL. > > My point is not that it's biting me right now but that earlier you > said the

Re: [Python-Dev] "Fixing" the new GIL

Le Tue, 16 Mar 2010 17:02:13 +, Kristján Valur Jónsson a écrit : >> >> Well, I don't think this has ever been by design, and it's not obvious >> this is desirable either (see Dave Beazley's benchmark). >> > Did Dave benchmark a straight FIFO system? Well, he presented benchmark figures with t

Re: [Python-Dev] "Fixing" the new GIL

> David explained that in the issue tracker - 2.x typically doesn't do > that much work per bytecode instruction, Oh, but that's wrong in general. Dave's *spinning loop* doesn't do much work per bytecode instruction, however ;) > The current settings mean we have less GIL overhead in the normal

Re: [Python-Dev] "Fixing" the new GIL

Kristján Valur Jónsson wrote: > We have never had high priority for IO threads in > python (and its not-by-design round robin scheduler on single core > cpus) and it is unclear why that should be required now as a fix. David explained that in the issue tracker - 2.x typically doesn't do that much

Re: [Python-Dev] "Fixing" the new GIL

gt; > > > What we are trying to write here is a thread scheduler, and that is > complex business. > > K > > > > > > > >> -Original Message- > >> From: python-dev-bounces+kristjan=ccpgames.com <http://ccpgames.com> @ > python.o

Re: [Python-Dev] "Fixing" the new GIL

; progress at the same time, thus you may have an unnecessarily high rate of >>> ticking going on. >>> > 3) There isn't an immediate gil request made when an IO thread requests >>> the gil back, only after an initial timeout. >>> > >>> > What we are trying

Re: [Python-Dev] "Fixing" the new GIL

ial timeout. > > > > What we are trying to write here is a thread scheduler, and that is > complex business. > > K > > > > > > > >> -Original Message- > >> From: python-dev-bounces+kristjan=ccpgames@python.org > >> [mail

Re: [Python-Dev] "Fixing" the new GIL

> -Original Message- > From: python-dev-bounces+kristjan=ccpgames@python.org > [mailto:python-dev-bounces+kristjan=ccpgames@python.org] On Behalf > Of Antoine Pitrou > > The key to this > > is implementing your GIL in such a way that you (and not the system) > > chooses which thre

Re: [Python-Dev] "Fixing" the new GIL

Martin v. Löwis wrote: > > If it's lurking behind a filesystem interface or in its daemon mode > > (remote archive store), multiple client processes can be using it at once, > > and it will be processing multiple tasks somewhat in parallel. Here one > > can get a compute bound thread answering on

Re: [Python-Dev] "Fixing" the new GIL

Le Tue, 16 Mar 2010 14:10:33 +, Kristján Valur Jónsson a écrit : > > The key to this > is implementing your GIL in such a way that you (and not the system) > chooses which threads runs next. On Windows it works in a nice, > determinitstic FIFO order becoause that's how the underlying Event >

Re: [Python-Dev] "Fixing" the new GIL

> -Original Message- > From: python-dev-bounces+kristjan=ccpgames@python.org > [mailto:python-dev-bounces+kristjan=ccpgames@python.org] On Behalf > Of Antoine Pitrou > Sent: 16. mars 2010 12:00 > To: python-dev@python.org > Subject: Re: [Python-Dev]

Re: [Python-Dev] "Fixing" the new GIL

matters much. Cheers, Kristján > -Original Message- > From: David Beazley [mailto:d...@dabeaz.com] > Sent: 16. mars 2010 11:03 > To: Kristján Valur Jónsson > Cc: David Beazley; python-dev@python.org > Subject: Re: [Python-Dev] "Fixing" the new GIL > >

Re: [Python-Dev] "Fixing" the new GIL

Hi Kristján, > In the new GIL, there appear to be several problems: > 1) There is no FIFO queue of threads wanting the queue, thus thread > scheduling becomes non-deterministic Thread scheduling has always been non-deterministic. > 2) The "ticking" of the GIL is > now controled by a condition v

Re: [Python-Dev] "Fixing" the new GIL

d that is complex > business. > K > > > >> -Original Message- >> From: python-dev-bounces+kristjan=ccpgames....@python.org >> [mailto:python-dev-bounces+kristjan=ccpgames@python.org] On Behalf >> Of David Beazley >> Sent: 15. mars 2010 03:07 >>

Re: [Python-Dev] "Fixing" the new GIL

d scheduler, and that is complex business. K > -Original Message- > From: python-dev-bounces+kristjan=ccpgames@python.org > [mailto:python-dev-bounces+kristjan=ccpgames@python.org] On Behalf > Of David Beazley > Sent: 15. mars 2010 03:07 > To: python-dev@python.o

Re: [Python-Dev] "Fixing" the new GIL

Martin v. Löwis wrote: > Cameron Simpson wrote: >> The idea here is that one has a few threads receiving requests (eg a >> daemon watching a socket or monitoring a db queue table) which then use >> the FuncMultiQueue to manage how many actual requests are processed >> in parallel (yes, a semaphore

Re: [Python-Dev] "Fixing" the new GIL

On 16Mar2010 09:02, "Martin v. Löwis" wrote: | > If it's lurking behind a filesystem interface or in its daemon mode | > (remote archive store), multiple client processes can be using it at once, | > and it will be processing multiple tasks somewhat in parallel. Here one | > can get a compute boun

Re: [Python-Dev] "Fixing" the new GIL

On 16Mar2010 08:59, "Martin v. Löwis" wrote: | Cameron Simpson wrote: | > On 15Mar2010 09:28, Martin v. L�wis wrote: | > | > As for the argument that an application with cpu intensive work being | > | > driven by the IO itself will work itself out... No it won't, it can | > | > get into beat pat

Re: [Python-Dev] "Fixing" the new GIL

> If it's lurking behind a filesystem interface or in its daemon mode > (remote archive store), multiple client processes can be using it at once, > and it will be processing multiple tasks somewhat in parallel. Here one > can get a compute bound thread answering one request, impacting quick > resp

Re: [Python-Dev] "Fixing" the new GIL

Cameron Simpson wrote: > On 15Mar2010 09:28, Martin v. L�wis wrote: > | > As for the argument that an application with cpu intensive work being > | > driven by the IO itself will work itself out... No it won't, it can > | > get into beat patterns where it is handling requests quite rapidly up > |

Re: [Python-Dev] "Fixing" the new GIL

On 14Mar2010 19:32, "Martin v. Löwis" wrote: | > Speaking for myself, I have an app with a daemon mode which I expect | > will sometimes behave as described; it answers requests and thus has I/O | > bound threads waiting for requests and dispatching replies, and threads | > doing data handling, wh

Re: [Python-Dev] "Fixing" the new GIL

On 15Mar2010 09:28, Martin v. L�wis wrote: | > As for the argument that an application with cpu intensive work being | > driven by the IO itself will work itself out... No it won't, it can | > get into beat patterns where it is handling requests quite rapidly up | > until one that causes a long c

Re: [Python-Dev] "Fixing" the new GIL

> So, just to be clear about the my bug report, it is directly related > to the problem of overlapping I/O requests with CPU-bound processing. > This kind of scenario comes up in the context of many > applications--especially those based on cooperating processes, > multiprocessing, and message pass

Re: [Python-Dev] "Fixing" the new GIL

> As for the argument that an application with cpu intensive work being > driven by the IO itself will work itself out... No it won't, it can > get into beat patterns where it is handling requests quite rapidly up > until one that causes a long computation to start comes in. At that > point it'll

Re: [Python-Dev] "Fixing" the new GIL

I have been following this discussion about fixing the GIL and just wanted to make a few comments about it. To the doubters who don't think this is a real problem worth fixing, I must respectfully disagree. Multicore systems and parallel programming issues are not going away any time in the

Re: [Python-Dev] "Fixing" the new GIL

Antoine Pitrou wrote: > Le Sun, 14 Mar 2010 12:37:48 PDT, > Bill Janssen a écrit : > > > > The old GIL is causing me a great deal of grief. My server is heavily > > threaded, and when I get a number of Python 2.6 threads doing layout > > analysis, my 4 and 8 core machines turn into slow thrash

Re: [Python-Dev] "Fixing" the new GIL

On Sun, Mar 14, 2010 at 4:31 AM, Nir Aides wrote: > There are two possible problems with Dave's benchmark: > 1) On my system setting TCP_NODELAY option on the accepted server socket > changes results dramatically. > 2) What category of socket servers is dave's spin() function intended to > simulat

Re: [Python-Dev] "Fixing" the new GIL

> Testing with a modified server that reflects the above indicates the new > GIL behaves just fine in terms of throughput. > So a change to the GIL may not be required at all. Thanks - I think you put it better than I did. Regards, Martin ___ Python-Dev

Re: [Python-Dev] "Fixing" the new GIL

Le Sun, 14 Mar 2010 23:11:44 +0200, Nir Aides a écrit : > > I first disabled the call to spin() but client running time remained > around 30 seconds. > I then added TCP_NODELAY and running time dropped to a few dozen > milliseconds for the entire no-spin run. You don't want the benchmark to be d

Re: [Python-Dev] "Fixing" the new GIL

Le Sun, 14 Mar 2010 12:37:48 PDT, Bill Janssen a écrit : > > The old GIL is causing me a great deal of grief. My server is heavily > threaded, and when I get a number of Python 2.6 threads doing layout > analysis, my 4 and 8 core machines turn into slow thrashers. Have you checked whether the 2

Re: [Python-Dev] "Fixing" the new GIL

inline: On Sun, Mar 14, 2010 at 3:54 PM, Peter Portante wrote: > On 3/14/10 7:31 AM, "Nir Aides" wrote: > > There are two possible problems with Dave's benchmark: > > 1) On my system setting TCP_NODELAY option on the accepted server socket > changes results dramatically. > > Could you document

Re: [Python-Dev] "Fixing" the new GIL

Cameron Simpson wrote: > Currently all the above is somewhat "batchy"; the client end looks like > an archiving command line tool, but it's intended to have a FUSE mode to > present the archive as a filesystem; that I can imagine tripping over > this issue as a user uses the filesystem for "stuff

Re: [Python-Dev] "Fixing" the new GIL

> Speaking for myself, I have an app with a daemon mode which I expect > will sometimes behave as described; it answers requests and thus has I/O > bound threads waiting for requests and dispatching replies, and threads > doing data handling, which make constant use of the zlib library. This is th

Re: [Python-Dev] "Fixing" the new GIL

On 3/14/10 7:31 AM, "Nir Aides" wrote: > There are two possible problems with Dave's benchmark: > > 1) On my system setting TCP_NODELAY option on the accepted server socket > changes results dramatically. Could you document what you saw and explain how you think TCP_NODELAY makes a difference, i

Re: [Python-Dev] "Fixing" the new GIL

There are two possible problems with Dave's benchmark: 1) On my system setting TCP_NODELAY option on the accepted server socket changes results dramatically. 2) What category of socket servers is dave's spin() function intended to simulate? In a server which involves CPU intensive work in respons

Re: [Python-Dev] "Fixing" the new GIL

On 13Mar2010 23:03, Martin v. L�wis wrote: | > Any thoughts? | | My initial reaction to this report, and still my current opinion is: | This issue is not a problem. | It's a boundary case, so it's not clear whether Python should be able to | deal with it gracefully. I doubt it's a realistic case.

Re: [Python-Dev] "Fixing" the new GIL

Brett Cannon wrote: > > > On Sat, Mar 13, 2010 at 13:52, Benjamin Peterson > wrote: > > 2010/3/13 Antoine Pitrou >: > > Any thoughts? > \ > The latter solution seems best to me as it would help any 3rd party IO > l

Re: [Python-Dev] "Fixing" the new GIL

On Sat, Mar 13, 2010 at 13:52, Benjamin Peterson wrote: > 2010/3/13 Antoine Pitrou : > > Any thoughts? > \ > The latter solution seems best to me as it would help any 3rd party IO > libraries and require less code modification. > Plus the interactiveness approach has been tested by OS thread sche

Re: [Python-Dev] "Fixing" the new GIL

Le Sat, 13 Mar 2010 17:11:41 -0600, s...@pobox.com a écrit : > > If the 5ms interval is too long would it be possible to adaptively > reduce it in this situation? How would you detect it? I assume this > would be akin to your interactiveness computation. I think modulating the interval is what

Re: [Python-Dev] "Fixing" the new GIL

If the 5ms interval is too long would it be possible to adaptively reduce it in this situation? How would you detect it? I assume this would be akin to your interactiveness computation. Skip ___ Python-Dev mailing list Python-Dev@python.org http://ma

Re: [Python-Dev] "Fixing" the new GIL

On Sat, Mar 13, 2010 at 3:46 PM, Antoine Pitrou wrote: > - the second mechanism dynamically computes the "interactiveness" of a > thread and allows interactive threads to steal the GIL quickly. In > this approach, IO methods don't have to be modified at all. > I like the second approach as wel

Re: [Python-Dev] "Fixing" the new GIL

> Any thoughts? My initial reaction to this report, and still my current opinion is: This issue is not a problem. It's a boundary case, so it's not clear whether Python should be able to deal with it gracefully. I doubt it's a realistic case. Regards, Martin

Re: [Python-Dev] "Fixing" the new GIL

2010/3/13 Antoine Pitrou : > Any thoughts? \ The latter solution seems best to me as it would help any 3rd party IO libraries and require less code modification. -- Regards, Benjamin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python