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 foreseeable future. Moreover, there are plenty of programmers who are using Python to build applications involving concurrency, distributed computing, and compute intensive processing.While everyone agrees that it would be great if the GIL simply disappeared, the next best option is for the GIL to have well-defined and reasonably predictable behavior (i.e., behavior that can be easily explained and justified). Specifically, if multiple threads happen to be performing CPU intensive work at the same time, it would be nice if they didn't thrash on multiple cores (the problem with the old GIL) and if I/O is mixed with CPU-bound processing it would be nice if I/O requests didn't have their responsiveness and priority penalized (the problem with 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 passing. Ironically, these are exactly the kinds of parallel programming techniques that people are going to use because of the GIL in the first place. So, why would you want the new GIL to behave poorly here? In any case, if the GIL can be improved in a way that is simple and which either improves or doesn't negatively impact the performance of existing applications, why wouldn't you want to do it? Seems like a no-brainer. Cheers, Dave ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
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 thrashers. > > Have you checked whether the 2.x patch improved your use case? > It would be nice to get real-world feedback of which situations the > new GIL helps (or doesn't help) improve. Yes, good thought. I'll try it and see if I can get some numbers. I do have a mix of I/O and CPU bound threads, and we are seeing core usage by Python similar to that David originally discovered. Bill ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
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 > simulate? > In a server which involves CPU intensive work in response to a socket > request the behavior may be significantly different. > In such a system, high CPU load will significantly reduce socket > responsiveness which in turn will reduce CPU load and increase socket > responsiveness. > 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. > There is still the question of latency - a single request which takes long > time to process will affect the latency of other "small" requests. However, > it can be argued if such a scenario is practical, or if modifying the GIL is > the solution. Such a scenario is practical and is an area that we really should not fall flat on our face in. Python should not regress to performing worse when an application adds a cpu intensive thread that isn't tempered by the activity of its IO threads. 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 stop performing well on other requests for as long (it could be a significant amount of time) as the cpu intensive request threads are running. That is not a graceful degration in serving capacity / latency as one would normally expect. It is a sudden drop off. (followed by a sudden ramp up, and a sudden drop off and a sudden ramp up, and drop off... etc. not pretty. not predictable. not easy to deploy and manage as a service) If we don't fix this issue, we need to document as an official part of the Python threading module docs that people should not mix computation with IO in threaded applications when using CPython if they care about IO performance. This will blow people's mind. > If a change is still required, then I vote for the simpler approach - that > of having a special macro for socket code. > I remember there was reluctance in the past to repeat the OS scheduling > functionality and for a good reason. I don't consider needing to modify code specifically for it to indicate if it is IO bound or CPU bound to be the simpler approach. So +1 on the interactiveness calculation for me. +0.5 on annotating the IO lock release/acquisitions. Basically: I want to see this fixed, even if its not my preferred approach I still think it is important. -gps ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] __file__ and bytecode-only
Jon Ribbens wrote: Sorry if I missed it, but why on earth is the bytecode directory __pycache__ and not .pycache? (Or indeed anything else that starts with a '.') Surely this is a classic ideal use case for a "hidden" directory? Please don't try to hide it. On MacOSX, it makes it impossible to look inside using the Finder if you want to, and it won't have any effect on Windows anyway. -- Greg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
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 mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
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 dependent on the TCP stack's implementation specifics. Therefore, you should use the UDP version of Dave Beazley's benchmark. I have posted it on http://bugs.python.org/issue7946, and included a variant of it in ccbench. > The special macro for socket code is one of the alternatives proposed > by Antoine above. > > However, thinking about it again, with this approach as soon as the > new incoming request tries to read a file, query the DB, decompress > some data or do anything which releases the GIL, it goes back to > square one. no? Indeed. This approach involves using the macro in every place where releasing the GIL is meant to cover OS- or IO-dependent latencies. Even then, though, there may be cases (such as doing a very small amount of zlib compression) where the background CPU-bound thread will get "too much time" compared to the "mostly IO" thread. But the other approach isn't perfect either. These are heuristics anyway. > I remember there was reluctance in the past to repeat the OS > scheduling > functionality and for a good reason. I agree with this. Hence my posting on this list, about whether we should go with an additional amount of complexity to solve what may be considered an annoying performance problem. Regards Antoine. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
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.x patch improved your use case? It would be nice to get real-world feedback of which situations the new GIL helps (or doesn't help) improve. Thanks Antoine. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] __file__ and bytecode-only
R. David Murray wrote: > On Sun, 14 Mar 2010 12:59:50 -, Jon Ribbens > wrote: >> Sorry if I missed it, but why on earth is the bytecode directory >> __pycache__ and not .pycache? (Or indeed anything else that starts >> with a '.') Surely this is a classic ideal use case for a "hidden" >> directory? > > You did miss it. Perhaps a link to the discussion should be added to > the PEP, or a summary of it. If I remember correctly the BDFL even > weighed in on this point. He did (in favour of keeping the directory visible). Here's one reference (although not the main one): http://osdir.com/ml/python-dev/2010-02/msg00114.html My Google-fu is failing me, so I don't have a link to the other part of the thread that I refer to in that message. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia --- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
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 what you saw and explain how you think TCP_NODELAY makes > a difference, including what kind of system you ran your tests and what the > application was that demonstrates those dramatic results? > 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. The system is Ubuntu Karmic 64bit with latest revision of python 3.2. 2) What category of socket servers is dave's spin() function intended to > simulate? > > What is the problem you are trying to get at with this question? > > Does Dave’ spin() function have to have a category? Or perhaps the question > is, for these solutions, what category of application do they hurt? Perhaps > we can look at the solutions as general, but consider their impact in > various categories. > In Dave's code sample, spin() is loading the CPU regardless of requests. This may demonstrate how short IO bound requests will behave while the server is processing a long Python-algorithmic CPU intensive request, or an ongoing CPU intensive task unrelated to incoming requests. However is this typical for socket servers? If you change the sample server code to start a CPU bound thread with work X for each incoming request you will see different behavior. There is still the question of latency - a single request which takes long > time to process will affect the latency of other "small" requests. However, > it can be argued if such a scenario is practical, or if modifying the GIL is > the solution. > > Perhaps Dave already documented this effect in his visualizations, no? > Naturally. I did not imply otherwise. His analysis is brilliant. > If a change is still required, then I vote for the simpler approach - that > of having a special macro for socket code. > > What is that simpler approach? How would that special macro work? > The special macro for socket code is one of the alternatives proposed by Antoine above. However, thinking about it again, with this approach as soon as the new incoming request tries to read a file, query the DB, decompress some data or do anything which releases the GIL, it goes back to square one. no? I remember there was reluctance in the past to repeat the OS scheduling > functionality and for a good reason. > > > In what ways do we consider the CPython interpreter to be different than > another application that has multiple threads and contention for one > resource? Perhaps we have a unique problem among all other user space > applications. Perhaps we don’t. > I think a rule of thumb is to protect a resource (typically a data structure), as tightly as possible, avoiding for example locking across function calls, etc, if possible. In contrast CPython is "locked" the entire time. As for the behavior of the GIL, how are the proposed solutions repeating OS > scheduling functionality? > Dave discussed this in his analysis. Nir ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
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". Me, too :-). Though I also do a lot of processing in pure Python... > Still, it is unusual and I suspect it will self limit to an extent > anyway; I can't fairly claim to have had it cause me trouble yet. > (Indeed, I've not used the new GIL at all - it's mostly using python > 2.6). 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. I'm dismayed that the backport of the new GIL work to the 2.x line has been stopped (see issue 7753); I see a future of OS X 10.7 with presumably 64-bit Python 2.7 on, say, 32-core machines running even more slowly than it currently does. That's a pretty hard-core backwards compatibility decision. Maybe the Mac-SIG should adopt that patch... Bill ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
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 then already different from the scenario described. Every call into zlib will release the GIL, for the period of the zlib computation, allowing other threads to run. > On the > client side the same app is often throughput bound by a data examination > process that is compute bound; I can easily see it having compute bound > threads and I/O bound threads talking to daemon instances. I can't see that. I would expect that typically (and specifically including your application), the compute bound threads will synchronize with the IO bound ones, asking for more requests to perform. That's the whole point of using the "bound" adjective (?): execution time is *bound* by the computation time. It can't get faster than what the computation can process. Regards, Martni ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] __file__ and bytecode-only
On Sun, 14 Mar 2010 12:59:50 -, Jon Ribbens wrote: > On Fri, Mar 12, 2010 at 05:56:57PM -0500, Barry Warsaw wrote: > > Nope, sorry I should have been clearer. > > > > *creation* is the key here. As per BDFL pronouncement, we'll support > > reading > > pyc-only modules just like we do today. This is in PEP 3147. We won't > > support creating them though. > > > > BTW, I'm actually starting to work on the implementation now, so if you want > > to play along: > > > > % bzr branch lp:~barry/python/pep3147 > > Sorry if I missed it, but why on earth is the bytecode directory > __pycache__ and not .pycache? (Or indeed anything else that starts > with a '.') Surely this is a classic ideal use case for a "hidden" > directory? You did miss it. Perhaps a link to the discussion should be added to the PEP, or a summary of it. If I remember correctly the BDFL even weighed in on this point. -- R. David Murray www.bitdance.com ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] __file__ and bytecode-only
On 13 March 2010 14:17, Nick Coghlan wrote: > The creation side could be made a little more explicit in the PEP. We > could also do something via the compileall module. > > (Pause while Nick goes and reads the source code for compileall for the > first time ever...) > > Hmm - methinks the PEP actually needs to talk explicitly about the > py_compile and compileall modules. These compile the files directly > rather than using the import system's side-effect, so they'll need to > understand the intricacies of the new system. The bdist_wininst installer also compiles modules explicitly on install (as does the python.org Windows MSI installer). I've always assumed that this worked via compileall, but haven't checked. Regardless, these should probably also be covered in the PEP. Paul. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] __file__ and bytecode-only
Le Sun, 14 Mar 2010 12:59:50 +, Jon Ribbens a écrit : > > Sorry if I missed it, but why on earth is the bytecode directory > __pycache__ and not .pycache? (Or indeed anything else that starts > with a '.') Surely this is a classic ideal use case for a "hidden" > directory? I suppose the same reason pyc files are not hidden nowadays. We want people to be aware that these files exist. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] __file__ and bytecode-only
On Sun, 14 Mar 2010 11:59:50 pm Jon Ribbens wrote: > Sorry if I missed it, but why on earth is the bytecode directory > __pycache__ and not .pycache? (Or indeed anything else that starts > with a '.') Surely this is a classic ideal use case for a "hidden" > directory? I disagree with your assumption that there is *any* use-case for a hidden directory, let alone an ideal one. I despise hidden directories and dot files. I know it is the "Unix way", and I suppose it made sense back in 1975 when users had two or three dot files in their home directory, but I count 215 dot files in my home directory compared to only 77 visible files, and I have no idea how most of them got there or what they do. Programs that litter the file system with dot files are bad enough when they do it in $HOME, but sprinkling dot files everywhere they can is inexcusable. This is not the place for me to rant over the evil that is dot files, so I'll just say this: Python works on platforms other than Unix/Linux, and some of those platforms don't treat dot files as anything more than a file with a leading dot in the file name. -- Steven D'Aprano ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] __file__ and bytecode-only
On Fri, Mar 12, 2010 at 05:56:57PM -0500, Barry Warsaw wrote: > Nope, sorry I should have been clearer. > > *creation* is the key here. As per BDFL pronouncement, we'll support reading > pyc-only modules just like we do today. This is in PEP 3147. We won't > support creating them though. > > BTW, I'm actually starting to work on the implementation now, so if you want > to play along: > > % bzr branch lp:~barry/python/pep3147 Sorry if I missed it, but why on earth is the bytecode directory __pycache__ and not .pycache? (Or indeed anything else that starts with a '.') Surely this is a classic ideal use case for a "hidden" directory? ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
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, including what kind of system you ran your tests and what the application was that demonstrates those dramatic results? > 2) What category of socket servers is dave's spin() function intended to > simulate? What is the problem you are trying to get at with this question? Does Dave¹ spin() function have to have a category? Or perhaps the question is, for these solutions, what category of application do they hurt? Perhaps we can look at the solutions as general, but consider their impact in various categories. > In a server which involves CPU intensive work in response to a socket request > the behavior may be significantly different. In such a system, high CPU load > will significantly reduce socket responsiveness which in turn will reduce CPU > load and increase socket responsiveness. Not sure I follow how high CPU load will in turn reduce CPU load. :) Can you explain more about what you are trying to say here? > 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. Are you saying that a change to the new GIL may not be required at all? Did your modified server run any worse with any of the proposed changes? Could you document what you saw? > There is still the question of latency - a single request which takes long > time to process will affect the latency of other "small" requests. However, it > can be argued if such a scenario is practical, or if modifying the GIL is the > solution. Perhaps Dave already documented this effect in his visualizations, no? > If a change is still required, then I vote for the simpler approach - that of > having a special macro for socket code. What is that simpler approach? How would that special macro work? > I remember there was reluctance in the past to repeat the OS scheduling > functionality and for a good reason. Folks, Do we believe that every other application that has contention for one resource leaves the solution of that problem to the OS scheduler? In what ways do we consider the CPython interpreter to be different than another application that has multiple threads and contention for one resource? Perhaps we have a unique problem among all other user space applications. Perhaps we don¹t. Do we see Antoine¹s or Dave¹s proposed solutions as being solutions to a niche problem? Or are they algorithms for handling one or more of the behaviors the CPython interpreter will encounter when running the many python applications across OS/CPU environments? As for the behavior of the GIL, how are the proposed solutions repeating OS scheduling functionality? Could we instead look at these solutions as repeating what other applications have done that have contention for one resource? Can anyone show that Antoine¹s proposed solution hurts performance? -peter > Nir > > > On Sat, Mar 13, 2010 at 11:46 PM, Antoine Pitrou wrote: >> >> Hello, >> >> As some of you may know, Dave Beazley recently exhibited a situation >> where the new GIL shows quite a poor behaviour (the old GIL isn't very >> good either, but still a little better). This issue is followed in >> http://bugs.python.org/issue7946 >> >> This situation is when an IO-bound thread wants to process a lot of >> incoming packets, while one (or several) CPU-bound thread is also >> running. Each time the IO-bound thread releases the GIL, the CPU-bound >> thread gets it and keeps holding it for at least 5 milliseconds >> (default setting), which limits the number of individual packets which >> can be recv()'ed and processed per second. >> >> I have proposed two mechanisms, based on the same idea: IO-bound >> threads should be able to steal the GIL very quickly, rather than >> having to wait for the whole "thread switching interval" (again, 5 ms >> by default). They differ in how they detect an "IO-bound threads": >> >> - the first mechanism is actually the same mechanism which was >> embodied in the original new GIL patch before being removed. In this >> approach, IO methods (such as socket.read() in socketmodule.c) >> releasing the GIL must use a separate C macro when trying to get the >> GIL back again. >> >> - 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. >> >> Both approaches show similar benchmark results (for the benchmarks >> that I know of) and basically fix the issue put forward by Dave Beazley. >> >> Any thoughts? >> >> Regards >> >> Antoine. >> >> >> ___ >> Python-Dev ma
Re: [Python-Dev] C++
Jeffrey Yasskin wrote: On Fri, Mar 12, 2010 at 7:54 PM, wrote: OS/2: http://www.andymac.org/ I can't find a modern c++ compiler for OS/2. Then again, your link only provides python 2.4. While the gcc used as part of the EMX toolchain is 2.8.1, there are ports of gcc 3.3.5 and 4.4.x using a somewhat compatible runtime (known as klibc). I have an unreleased 2.6 binary package which I'm holding up pending 2.6.5. OpenWatcom is also supported on OS/2, though I don't know whether the C++ support is advanced enough... while I like this compiler, the runtime support (or lack thereof) for Posixish features makes platform support a lot of work. Andrew. -- - Andrew I MacIntyre "These thoughts are mine alone..." E-mail: andy...@bullseye.apana.org.au (pref) | Snail: PO Box 370 andy...@pcug.org.au (alt) |Belconnen ACT 2616 Web:http://www.andymac.org/ |Australia ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
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 response to a socket request the behavior may be significantly different. In such a system, high CPU load will significantly reduce socket responsiveness which in turn will reduce CPU load and increase socket responsiveness. 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. There is still the question of latency - a single request which takes long time to process will affect the latency of other "small" requests. However, it can be argued if such a scenario is practical, or if modifying the GIL is the solution. If a change is still required, then I vote for the simpler approach - that of having a special macro for socket code. I remember there was reluctance in the past to repeat the OS scheduling functionality and for a good reason. Nir On Sat, Mar 13, 2010 at 11:46 PM, Antoine Pitrou wrote: > > Hello, > > As some of you may know, Dave Beazley recently exhibited a situation > where the new GIL shows quite a poor behaviour (the old GIL isn't very > good either, but still a little better). This issue is followed in > http://bugs.python.org/issue7946 > > This situation is when an IO-bound thread wants to process a lot of > incoming packets, while one (or several) CPU-bound thread is also > running. Each time the IO-bound thread releases the GIL, the CPU-bound > thread gets it and keeps holding it for at least 5 milliseconds > (default setting), which limits the number of individual packets which > can be recv()'ed and processed per second. > > I have proposed two mechanisms, based on the same idea: IO-bound > threads should be able to steal the GIL very quickly, rather than > having to wait for the whole "thread switching interval" (again, 5 ms > by default). They differ in how they detect an "IO-bound threads": > > - the first mechanism is actually the same mechanism which was > embodied in the original new GIL patch before being removed. In this > approach, IO methods (such as socket.read() in socketmodule.c) > releasing the GIL must use a separate C macro when trying to get the > GIL back again. > > - 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. > > Both approaches show similar benchmark results (for the benchmarks > that I know of) and basically fix the issue put forward by Dave Beazley. > > Any thoughts? > > Regards > > Antoine. > > > ___ > Python-Dev mailing list > Python-Dev@python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/nir%40winpdb.org > ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
