Re: Status of Python threading support (GIL removal)?
Paul Rubin http://phr...@nospam.invalid wrote: Hendrik van Rooyen m...@microcorp.co.za writes: I think that this is because (like your link has shown) the problem is really not trivial, and also because the model that can bring sanity to the party (independent threads/processes that communicate with queued messages) is seen as inefficient at small scale. That style works pretty well in Python and other languages. The main gripe about it for Python is the subject of this thread, i.e. the GIL. I have found that if you accept it, and sprinkle a few judicious time.sleep(short_time)'s around, things work well. Sort of choosing yourself when the thread gives up its turn. - Hendrik -- http://mail.python.org/mailman/listinfo/python-list
Re: Status of Python threading support (GIL removal)?
Look, guys, here's the thing: In the company I work at we decided to rewrite our MRP system in Python. I was one of the main proponents of it since it's nicely cross platform and allows for quite rapid application development. The language and it's built in functions are simply great. The opposition was quite strong, especially since the owner cheered for it - .net. So, recently I started writing a part of this new system in Python. A report generator to be exact. Let's not go into existing offerings, they are insufficient for our needs. First I started on a few tests. I wanted to know how the reporting engine will behave if I do this or that. One of the first tests was, naturally, threading. The reporting engine itself will have separate, semi-independent parts that can be threaded well, so I wanted to test that. The rest you know if you read the two threads I started on this group. Now, the core of the new application is designed so that it can be clustered so it's no problem if we just start multiple instances on one server, say one for each available core. The other day, a coworker of mine said something like: what?!? you've been using Python for two days already and you already say it's got a major fault? I kinda aggreed with him, especially since this particular coworker programmed strictly in Python for the last 6 months (and I haven't due to other current affairs). There was no way my puny testing could reveal such a major drawback. As it turns out, I was right. I have programmed enough threading to have tried enough variations which all reveal the GIL. Which I later confirmed through searching on the web. My purpose with developing the reporting engine in Python was twofold: learn Python as I go and create a native solution which will work out- of-the-box for all systems we decide to support. Making the thing open source while I'm at it was a side-bonus. However: Since the testing revealed this, shall we say problem, I am tempted to just use plain old C++ again. Furthermore, I was also not quite content with the speed of arithmetic processing of the python engine. I created some simple aggregating objects that only performed two additions per pass. Calling them 200K times took 4 seconds. This is another reason why I'm beginning to think C++ might be a better alternative. I must admit, had the GIL issue not popped up, I'd just take the threading benefits and forget about it. But both things together, I'm thinking I need to rethink my strategy again. I may at some point decide that learning cross platform programming is worth a shot and just write a Python plugin for the code I write. The final effect will be pretty much the same, only faster. Perhaps I will even manage to get close to Crystal Reports speed, though I highly doubt that. But in the end, my Python skill will suffer. I still have an entire application (production support) to develop in it. Thanks for all the information and please don't flame each other. I already get the picture that GIL is a hot subject. -- http://mail.python.org/mailman/listinfo/python-list
Re: Status of Python threading support (GIL removal)?
On 21 juin, 03:27, Jure Erznožnik jure.erznoz...@gmail.com wrote: Add: Carl, Olivier co. - You guys know exactly what I wanted. Others: Going back to C++ isn't what I had in mind when I started initial testing for my project. Do you think multiprocessing can help you seriously ? Can you benefit from multiple cpu ? did you try to enhance your code with numpy ? Olivier (installed a backported multiprocessing on his 2.5.1 Python, but need installation of Xcode first) -- http://mail.python.org/mailman/listinfo/python-list
Re: Status of Python threading support (GIL removal)?
On Jun 21, 9:32 am, OdarR olivier.da...@gmail.com wrote: Do you think multiprocessing can help you seriously ? Can you benefit from multiple cpu ? did you try to enhance your code with numpy ? Olivier (installed a backported multiprocessing on his 2.5.1 Python, but need installation of Xcode first) Multithreading / multiprocessing can help me with my problem. As you know, database reading is typically I/O bound so it helps to put it in a separate thread. I might not even notice the GIL if I used SQL access in the first place. As it is, DBFPY is pretty CPU intensive since it's a pure Python DBF implementation. To continue: the second major stage (summary calculations) is completely CPU bound. Using numpy might or might not help with it. Those are simple calculations, mostly additions. I try not to put the entire database in arrays to save memory and so I mostly just add counters where I can. Soe functions simply require arrays, but they are more rare, so I guess I'm safe with that. You wouldn't believe how complex some reports can be. Threading + memory saving is a must and even so, I'll probably have to implement some sort of serialization later on, so that the stuff can run on more memory constrained devices. The third major stage, rendering engine, is again mostly CPU bound, but at the same time it's I/O bound as well when outputting the result. All three major parts are more or less independent from each other and can run simultaneously, just with a bit of a delay. I can perform calculations while waiting for the next record and I can also start rendering immediately after I have all the data for the first group available. I may use multiprocessing, but I believe it introduces more communication overhead than threads and am so reluctant to go there. Threads were perfect, other stuff wasn't. To make things worse, no particular extension / fork / branch helps me here. So if I wanted to just do the stuff in Python, I'd have to move to Jthon or IronPython and hope cPython eventually improves in this area. I do actually need cPython since the other two aren't supported on all platforms my company intends to support. The main issue I currently have with GIL is that execution time is worse when I use threading. Had it been the same, I wouldn't worry too much about it. Waiting for a permenent solution would be much easier then... -- http://mail.python.org/mailman/listinfo/python-list
Re: Status of Python threading support (GIL removal)?
Kay Schluehr k...@fiber-space.de wrote: This implies that people stay defensive concerning concurrency ( like me right now ) and do not embrace it like e.g. Erlang does. Sometimes there is a radical change in the way we design applications and a language is the appropriate medium to express it succinctly. Concurrency is one example, writing GUIs and event driven programs in a declarative style ( Flex, WPF, JavaFX ) is another one. In particular the latter group shows that new skills are adopted rather quickly. I don't see that a concurrency oriented language has really peaked though yet. I think that this is because (like your link has shown) the problem is really not trivial, and also because the model that can bring sanity to the party (independent threads/processes that communicate with queued messages) is seen as inefficient at small scale. - Hendrik -- http://mail.python.org/mailman/listinfo/python-list
Re: Status of Python threading support (GIL removal)?
Christian Heimes wrote: Hard computations gain more speed from carefully crafted C or Fortran code that utilizes features like the L1 and L2 CPU cache, SIMD etc. or parallelized algorithms. If you start sharing values between multiple cores you have a serious problem. Oh, and use NumPy for the job ;) [...] It *is* a well known limitation of Python. All the nice 'n shiny syntax and features are coming with a cost. Python is a powerful language and good tool for lots of stuff. But Python is and will never become the übertool that solves every problem perfectly. At some point you need a different tool to get the raw power of your machine. C (and perhaps Fortran) are the weapons of choice for number crunching. Well, and there's always Cython to the rescue when you need it. Stefan -- http://mail.python.org/mailman/listinfo/python-list
Re: Status of Python threading support (GIL removal)?
Jure Erznožnik wrote: On Jun 20, 1:36 am, a...@pythoncraft.com (Aahz) wrote: You should put up or shut up -- I've certainly seen multi-core speedup with threaded software, so show us your benchmarks! -- Sorry, no intent to offend anyone here. Flame wars are not my thing. I have shown my benchmarks. See first post and click on the link. That's the reason I started this discussion. All I'm saying is that you can get threading benefit, but only if the threading in question is implemented in C plugin. I have yet to see pure Python code which does take advantage of multiple cores. From what I read about GIL, this is simply impossible by design. Well, CPython is written in C. So running Python code in CPython will necessarily run C code (whatever plugin means in your post above). If that C code frees the GIL or not depends on the parts of CPython or external packages that you use. And there are many parts that free the GIL and will thus benefit (sometimes heavily) from threading and multiple-cores, and there are also many parts that do not free the GIL and will therefore not (or likely not) benefit from multiple-cores. Claiming that pure Python code does not free the GIL in the context of CPython when you define pure Python code as code that does not depend on C code is plain flawed. Stefan -- http://mail.python.org/mailman/listinfo/python-list
Re: Status of Python threading support (GIL removal)?
Jesse Noller wrote: Sorry, you're incorrect. I/O Bound threads do in fact, take advantage of multiple cores. I don't know whether anyone else brought this up, but it looks like Python has problems with even this form of threading http://www.dabeaz.com/python/GIL.pdf It's certainly a very interesting read if you're interested in this subject. -- Jeremy Sanders http://www.jeremysanders.net/ -- http://mail.python.org/mailman/listinfo/python-list
Re: Status of Python threading support (GIL removal)?
In article 90303b55-8686-4d56-b89c-01e31d0a6...@l8g2000vbp.googlegroups.com, =?windows-1252?Q?Jure_Erzno=9Enik?= jure.erznoz...@gmail.com wrote: So, recently I started writing a part of this new system in Python. A report generator to be exact. Let's not go into existing offerings, they are insufficient for our needs. First I started on a few tests. I wanted to know how the reporting engine will behave if I do this or that. One of the first tests was, naturally, threading. The reporting engine itself will have separate, semi-independent parts that can be threaded well, so I wanted to test that. This is not something that I would expect Python threads to provide a performance boost for. I would expect that if it were a GUI app, it would improve responsiveness, properly designed. If performance were a goal, I would start by profiling it under a single-threaded design and see where the hotspots were, then either choose one of several options for improving performance or go multi-process. Note that I'm generally one of the Python thread boosters (unlike some people who claim that Python threads are worthless), but I also never claim that Python threads are good for CPU-intensive operations (which report generation is), *except* for making GUI applications more responsive. -- Aahz (a...@pythoncraft.com) * http://www.pythoncraft.com/ as long as we like the same operating system, things are cool. --piranha -- http://mail.python.org/mailman/listinfo/python-list
Re: Status of Python threading support (GIL removal)?
In article h1l6m3$3f...@gemini.csx.cam.ac.uk, Jeremy Sanders jeremy+complangpyt...@jeremysanders.net wrote: Jesse Noller wrote: Sorry, you're incorrect. I/O Bound threads do in fact, take advantage of multiple cores. I don't know whether anyone else brought this up, but it looks like Python has problems with even this form of threading http://www.dabeaz.com/python/GIL.pdf Most of us have already seen this. It's a good point, but IME writing multi-threaded apps for multi-core machines, I think one should be careful to avoid reading too much into it. -- Aahz (a...@pythoncraft.com) * http://www.pythoncraft.com/ as long as we like the same operating system, things are cool. --piranha -- http://mail.python.org/mailman/listinfo/python-list
Re: Status of Python threading support (GIL removal)?
Hendrik van Rooyen m...@microcorp.co.za writes: I think that this is because (like your link has shown) the problem is really not trivial, and also because the model that can bring sanity to the party (independent threads/processes that communicate with queued messages) is seen as inefficient at small scale. That style works pretty well in Python and other languages. The main gripe about it for Python is the subject of this thread, i.e. the GIL. -- http://mail.python.org/mailman/listinfo/python-list
Re: Status of Python threading support (GIL removal)?
Jure Erznožnik jure.erznoz...@gmail.com (JE) wrote: JE Sorry, just a few more thoughts: JE Does anybody know why GIL can't be made more atomic? I mean, use JE different locks for different parts of code? JE This way there would be way less blocking and the plugin interface JE could remain the same (the interpreter would know what lock it used JE for the plugin, so the actual function for releasing / reacquiring the JE lock could remain the same) JE On second thought, forget this. This is probably exactly the cause of JE free-threading reduced performance. Fine-graining the locks increased JE the lock count and their implementation is rather slow per se. The major obstacles are the refcounts. It would mean that each refcounted object would need a separate lock including constants like 0, 1, True, None. You would have much more locking and unlocking then with the GIL. So to get rid of it first the refcounting has to go. But that is not sufficient. When the GIL will be removed I suspect that many concurrent programs will start to fail subtly because they make assumptions about the atomicity of the operations. In CPython each bytecode is atomic, but when there is no GIL this is no longer true. Java has defined this quite rigorously in its memory model (although there first memory model had subtle bugs): Read and write operations on 32-bit quantities are atomic, others not. This means that on a 64-bit system, where pointers are 64-bit even assignments on variables of object types are not atomic and have to be protected with synchronized. (My info is a few years old, so in the meantime it may have changed.) In a GIL-less python the same would be true. Of course the hardware that your program is running on could have atomic read/writes on 64-bit quantities but if you rely upon that your program may no longer be portable. -- Piet van Oostrum p...@cs.uu.nl URL: http://pietvanoostrum.com [PGP 8DAE142BE17999C4] Private email: p...@vanoostrum.org -- http://mail.python.org/mailman/listinfo/python-list
Re: Status of Python threading support (GIL removal)?
Jure Erznožnik jure.erznoz...@gmail.com (JE) wrote: JE I have shown my benchmarks. See first post and click on the link. JE That's the reason I started this discussion. JE All I'm saying is that you can get threading benefit, but only if the JE threading in question is implemented in C plugin. JE I have yet to see pure Python code which does take advantage of JE multiple cores. From what I read about GIL, this is simply impossible JE by design. In fact, at least theoretically, your original application could benefit from multiple cores. Take this scenario: You have one thread that reads from a file. On each read the GIL is released until the read has completed. In the meantime the other thread could do some CPU-intensive work. Now if the read comes entirely from the O.S. cache it is also CPU-bound. So there a second core comes in handy. Now usually these reads will not consume so much CPU so it will probably be hardly noticeable. But if you would have some kind of CPU-intensive User-space File System, for example with compression and/or encryption and the data is in memory you might notice it. In this example all your application code is written in Python. -- Piet van Oostrum p...@cs.uu.nl URL: http://pietvanoostrum.com [PGP 8DAE142BE17999C4] Private email: p...@vanoostrum.org -- http://mail.python.org/mailman/listinfo/python-list
Re: Status of Python threading support (GIL removal)?
Ross Ridge rri...@csclub.uwaterloo.ca (RR) wrote: RR By definition an I/O bound thread isn't CPU bound so won't benefit from RR improved CPU resources. But doing I/O is not the same as being I/O bound. And Python allows multithreading when a thread does I/O even if that thread is not I/O bound but CPU bound. See my other posting for an example. -- Piet van Oostrum p...@cs.uu.nl URL: http://pietvanoostrum.com [PGP 8DAE142BE17999C4] Private email: p...@vanoostrum.org -- http://mail.python.org/mailman/listinfo/python-list
Re: Status of Python threading support (GIL removal)?
On Jun 19, 4:42 pm, Christian Heimes li...@cheimes.de wrote: OdarR schrieb: On 19 juin, 21:41, Carl Banks pavlovevide...@gmail.com wrote: He's saying that if your code involves extensions written in C that release the GIL, the C thread can run on a different core than the Python-thread at the same time. The GIL is only required for Python code, and C code that uses the Python API. C code that spends a big hunk of time not using any Python API (like, as Skip pointed out, a matrix multiply) can release the GIL and the thread can run on a different core at the same time. I understand the idea, even if I don't see any examples in the standard library. any examples ? http://svn.python.org/view/python/trunk/Modules/posixmodule.c?revisio... Search for Py_BEGIN_ALLOW_THREADS / Py_END_ALLOW_THREADS yes, I also speak about hard computation that could benefit with multiple cores. Hard computations gain more speed from carefully crafted C or Fortran code that utilizes features like the L1 and L2 CPU cache, SIMD etc. or parallelized algorithms. If you start sharing values between multiple cores you have a serious problem. Oh, and use NumPy for the job ;) I wish people would just say, This is a limitation of CPython. There are reasons why it's there, and it helps some people, but unfortunately it has drawbacks for others, instead of the typical all u hav 2 do is rite it in C LOL. LOL I would like to say such thing about my weather...I live in Europe in a rainy country. It *is* a well known limitation of Python. All the nice 'n shiny syntax and features are coming with a cost. Python is a powerful language and good tool for lots of stuff. But Python is and will never become the übertool that solves every problem perfectly. At some point you need a different tool to get the raw power of your machine. C (and perhaps Fortran) are the weapons of choice for number crunching. This is the narrowminded attitude that irritates me. Here's the thing: not everyone complaining about the GIL is trying to get the raw power of their machines. They just want to take advantage of multiple cores so that their Python program runs faster. It would be rude and presumptuous to tell such a person, Well, GIL isn't that big of a deal because if you want speed you can always rewrite it in C to take advantage of multiple cores. Carl Banks -- http://mail.python.org/mailman/listinfo/python-list
Re: Status of Python threading support (GIL removal)?
On Jun 19, 4:35 pm, a...@pythoncraft.com (Aahz) wrote: In article 157e0345-74e0-4144-a2e6-2b4cc854c...@z7g2000vbh.googlegroups.com, Carl Banks pavlovevide...@gmail.com wrote: I wish Pythonistas would be more willing to acknowledge the (few) drawbacks of the language (or implementation, in this case) instead of all this rationalization. Please provide more evidence that Pythonistas are unwilling to acknowledge the drawbacks of the GIL. I will not, since I was not making an assertion, but an observation that some Pythonistas ignore (and even outright dismiss) claims that Python has a drawback by countering with a suggestion that they should be doing it some other, often more obtuse, way anyway--and expressing a wish that I could observe this less often. Carl Banks -- http://mail.python.org/mailman/listinfo/python-list
Re: Status of Python threading support (GIL removal)?
You might want to read about The Problem with Threads: http://www.eecs.berkeley.edu/Pubs/TechRpts/2006/EECS-2006-1.pdf and then decide to switch to an appropriate concurrency model for your use case. and to a programming language that supports it. -- http://mail.python.org/mailman/listinfo/python-list
Re: Status of Python threading support (GIL removal)?
On 20 juin, 11:02, Carl Banks pavlovevide...@gmail.com wrote: Here's the thing: not everyone complaining about the GIL is trying to get the raw power of their machines. They just want to take advantage of multiple cores so that their Python program runs faster. It would be rude and presumptuous to tell such a person, Well, GIL isn't that big of a deal because if you want speed you can always rewrite it in C to take advantage of multiple cores. merci Carl, you expressed what I would like to tell. Olivier -- http://mail.python.org/mailman/listinfo/python-list
Re: Status of Python threading support (GIL removal)?
Carl Here's the thing: not everyone complaining about the GIL is trying Carl to get the raw power of their machines. They just want to take Carl advantage of multiple cores so that their Python program runs Carl faster. If their code is CPU-bound it's likely that rewriting critical parts in C or using packages like numpy would improve there performance with or without multi-threading. For people who aren't used to C there are tools like Pyrex and Cython which provide a middle road. Skip -- http://mail.python.org/mailman/listinfo/python-list
Re: Status of Python threading support (GIL removal)?
Kay Schluehr wrote: You might want to read about The Problem with Threads: http://www.eecs.berkeley.edu/Pubs/TechRpts/2006/EECS-2006-1.pdf and then decide to switch to an appropriate concurrency model for your use case. and to a programming language that supports it. Maybe, yes. But many different concurrency models are supported by a larger number of programming languages in one way or another, so the choice of an appropriate library is often sufficient - and usually a lot easier than using the 'most appropriate' programming language. Matter of available skills, mostly. There's usually a lot less code to be written that deals with concurrency than code that implements what the person paying you makes money with, so learning a new library may be worth it, while learning a new language may not. Stefan -- http://mail.python.org/mailman/listinfo/python-list
Re: Status of Python threading support (GIL removal)?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jean-Paul Calderone wrote: On Sat, 20 Jun 2009 00:07:27 GMT, Lie Ryan lie.1...@gmail.com wrote: [snip] Perhaps we should have more built-in/stdlib operations that can release GIL safely to release GIL by default? And perhaps some builtin/stdlib should receive an optional argument that instruct them to release GIL and by passing this argument, you're making a contract that you wouldn't do certain things that would disturb the builtin/stdlib's operations; the specifics of what operations are prohibited would be noted on their docs. There would be a lot less useless discussion if people would do a minimal amount of checking to see if the ideas they're suggesting are at all feasible. Why don't you take a look at the CPython source and see if this is actually possible? If you're not comfortable diving into a C program, then maybe you could try to become so first, or refrain from making suggestions that rely on technical details you know nothing about? Jean-Paul There are 4 types of people's attitude towards discussion on GIL: Two useless ones: 1. seasoned developers who have run out of ideas and moved to other more important issues, leaving GIL problems to be solved by the future generation; 2. newbies who spurts out random ideas, often half-baked, impossible, unfeasible, or just plain stupid; and two helpful ones: 3. people who are too tired discussing GIL and just shut their mouth up; 4. people who preached resistance against GIL is futile and converted people of type 2 into type 3. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAko9IfcACgkQqC3FTmXeMUa11wCdFMmvLM6Y3fx8DPcty27XhuVS eJkAnAup/G/cQkDML0k49a+SlM1ymvCS =1cRN -END PGP SIGNATURE- -- http://mail.python.org/mailman/listinfo/python-list
Re: Status of Python threading support (GIL removal)?
On Jun 20, 6:36 am, s...@pobox.com wrote: Carl Here's the thing: not everyone complaining about the GIL is trying Carl to get the raw power of their machines. They just want to take Carl advantage of multiple cores so that their Python program runs Carl faster. If their code is CPU-bound it's likely that rewriting critical parts in C or using packages like numpy would improve there performance with or without multi-threading. For people who aren't used to C there are tools like Pyrex and Cython which provide a middle road. Once again you miss the point. I'm sure you think you're trying to be helpful, but you're coming off as really presumptuous with this casual dismissal of their concerns. There are many, many valid reasons why people don't want to stray from Pure Python. Converting to C, Fortran, Pyrex, etc. has a significant cost (in both implementation and maintenance): much more than the cost of parallelizing pure Python code. I guess what really bothers me about this is how easily people throw out shut up and use C for some things, especially things that quite reasonably appear to be a silly limitation. Maybe you don't intend to sound like you're saying shut up and use C, but to me, that's how you come off. If you're going to advise someone to use C, at least try to show some understanding for their concerns--it would go a long way. Carl Banks -- http://mail.python.org/mailman/listinfo/python-list
Re: Status of Python threading support (GIL removal)?
Add: Carl, Olivier co. - You guys know exactly what I wanted. Others: Going back to C++ isn't what I had in mind when I started initial testing for my project. -- http://mail.python.org/mailman/listinfo/python-list
Re: Status of Python threading support (GIL removal)?
Carl I'm sure you think you're trying to be helpful, but you're coming Carl off as really presumptuous with this casual dismissal of their Carl concerns. My apologies, but in most cases there is more than one way to skin a cat. Trust me, if removing the global interpreter lock was easy, or probably even it was simply hard, it almost certainly would have been done by now. Continuing to harp on this particular aspect of the CPython implementation doesn't help. Carl I guess what really bothers me about this is how easily people Carl throw out shut up and use C for some things, especially things Carl that quite reasonably appear to be a silly limitation. You completely misunderstand I think. People don't throw out shut up and use C out of ignorance. In fact, I don't believe I've ever read a response which took that tone. The practical matter is that there has so far been no acceptable patch to CPython which gets rid of the global interpreter lock. Extremely smart people have tried. More than once. If Guido knew then (20 years ago) what he knows now: * that the chip manufacturers would have run out of clock speed improvements for a few years and resorted to multi-core CPUs as a way to make their computers faster * that garbage collection algorithms would have improved as much as they have in the past twenty years I suspect he might well have considered garbage collection instead of reference counting as a way to reclaim unreferenced memory and we might have a GIL-less CPython implementation today. Carl Maybe you don't intend to sound like you're saying shut up and Carl use C, but to me, that's how you come off. If you're going to Carl advise someone to use C, at least try to show some understanding Carl for their concerns--it would go a long way. Then you haven't been listening. This topic comes up over and over and over again. It's a well-known limitation of the implementation. Poking people in the eye with it over and over doesn't help. The reasons for the limitation are explained every time the topic is raised. In the absence of a GIL-less CPython interpreter you are simply going to have to look elsewhere for performance improvements I'm afraid. Yes, I'll drag out the same old saws: * code hot spots in C or C++ * use tools like Pyrex, Cython, Psyco or Shed Skin * for array procesing, use numpy, preferably on top of a recent enough version of Atlas which does transparent multi-threading under the covers * use multiple processes * rewrite your code to use more efficient algorithms I don't write those out of ignorance for your plight. It's just that if you want a faster Python program today you're going to have to look elsewhere for your speedups. -- Skip Montanaro - s...@pobox.com - http://www.smontanaro.net/ when i wake up with a heart rate below 40, i head right for the espresso machine. -- chaos @ forums.usms.org -- http://mail.python.org/mailman/listinfo/python-list
Re: Status of Python threading support (GIL removal)?
On 20 Jun., 17:28, Stefan Behnel stefan...@behnel.de wrote: Kay Schluehr wrote: You might want to read about The Problem with Threads: http://www.eecs.berkeley.edu/Pubs/TechRpts/2006/EECS-2006-1.pdf and then decide to switch to an appropriate concurrency model for your use case. and to a programming language that supports it. Maybe, yes. But many different concurrency models are supported by a larger number of programming languages in one way or another, so the choice of an appropriate library is often sufficient - and usually a lot easier than using the 'most appropriate' programming language. Matter of available skills, mostly. There's usually a lot less code to be written that deals with concurrency than code that implements what the person paying you makes money with, so learning a new library may be worth it, while learning a new language may not. Stefan This implies that people stay defensive concerning concurrency ( like me right now ) and do not embrace it like e.g. Erlang does. Sometimes there is a radical change in the way we design applications and a language is the appropriate medium to express it succinctly. Concurrency is one example, writing GUIs and event driven programs in a declarative style ( Flex, WPF, JavaFX ) is another one. In particular the latter group shows that new skills are adopted rather quickly. I don't see that a concurrency oriented language has really peaked though yet. -- http://mail.python.org/mailman/listinfo/python-list
Re: Status of Python threading support (GIL removal)?
On Jun 20, 8:18 pm, s...@pobox.com wrote: Carl Maybe you don't intend to sound like you're saying shut up and Carl use C, but to me, that's how you come off. If you're going to Carl advise someone to use C, at least try to show some understanding Carl for their concerns--it would go a long way. Then you haven't been listening. This topic comes up over and over and over again. It's a well-known limitation of the implementation. Poking people in the eye with it over and over doesn't help. The reasons for the limitation are explained every time the topic is raised. In the absence of a GIL-less CPython interpreter you are simply going to have to look elsewhere for performance improvements I'm afraid. Yes, I'll drag out the same old saws: * code hot spots in C or C++ * use tools like Pyrex, Cython, Psyco or Shed Skin * for array procesing, use numpy, preferably on top of a recent enough version of Atlas which does transparent multi-threading under the covers * use multiple processes * rewrite your code to use more efficient algorithms I don't write those out of ignorance for your plight. It's just that if you want a faster Python program today you're going to have to look elsewhere for your speedups. Just for the record, I am not taking issue with the advice itself (except that you forgot use Jython/IronPython which have no GIL). I'm not even saying that Python was wrong for having the GIL. All I'm saying is that [this is not aimed specifically at you] this advice can be delivered with more respect for the complainer's problem, and less fanboy-like knee-jerk defensiveness of Python. Carl Banks -- http://mail.python.org/mailman/listinfo/python-list
Status of Python threading support (GIL removal)?
See here for introduction: http://groups.google.si/group/comp.lang.python/browse_thread/thread/370f8a1747f0fb91 Digging through my problem, I discovered Python isn't exactly thread safe and to solve the issue, there's this Global Interpreter Lock (GIL) in place. Effectively, this causes the interpreter to utilize one core when threading is not used and .95 of a core when threading is utilized. Is there any work in progess on core Python modules that will permanently resolve this issue? Is there any other way to work around the issue aside from forking new processes or using something else? -- http://mail.python.org/mailman/listinfo/python-list
Re: Status of Python threading support (GIL removal)?
This is a very long-running issue, that has been discussed many times. Here are the two sides to keeping the gil or removing it: Remove the GIL: - True multi-threaded programming - Scalable performance across a multi-core machine - Unfortunately, this causes a slow-down in single core/thread performance - Most of the slow down comes from Python's Reference counting, as every function is supposed to increase and decrease the references... which leads to a lot of synchronization and checking of locks. - It makes the core interpreter much more complex Keeping the GIL: - Processes should be used instead of threads. Look at Erlang, THE model of concurrency. It uses a process model for concurrency and message passing, rather than threads. This means you avoid deadlocks, livelocks, race conditions(not entirely, but they are reduced) - C extensions can still gain really impressive multi-threaded performance. My C extension, a wrapper around ffmpeg, releases the GIL for 90% or so of its processing time, so all other threads are still extremely responsive. - It allows python to stay simple, understandable, and offer good performance, if you know how to use it properly. Basically the two sides are that you it ends up slowing things down, it makes the interpreter more complex vs you should use processes instead, and be smart about how you use the GIL. -Tyler On Fri, Jun 19, 2009 at 2:52 AM, Jure Erznožnik jure.erznoz...@gmail.comwrote: See here for introduction: http://groups.google.si/group/comp.lang.python/browse_thread/thread/370f8a1747f0fb91 Digging through my problem, I discovered Python isn't exactly thread safe and to solve the issue, there's this Global Interpreter Lock (GIL) in place. Effectively, this causes the interpreter to utilize one core when threading is not used and .95 of a core when threading is utilized. Is there any work in progess on core Python modules that will permanently resolve this issue? Is there any other way to work around the issue aside from forking new processes or using something else? -- http://mail.python.org/mailman/listinfo/python-list -- Visit my blog at http://oddco.ca/zeroth/zblog -- http://mail.python.org/mailman/listinfo/python-list
Re: Status of Python threading support (GIL removal)?
Jure Erznožnik wrote: See here for introduction: http://groups.google.si/group/comp.lang.python/browse_thread/thread/370f8a1747f0fb91 Digging through my problem, I discovered Python isn't exactly thread safe and to solve the issue, there's this Global Interpreter Lock (GIL) in place. Effectively, this causes the interpreter to utilize one core when threading is not used and .95 of a core when threading is utilized. Is there any work in progess on core Python modules that will permanently resolve this issue? Is there any other way to work around the issue aside from forking new processes or using something else? There is a group of people working on an alternative implementation to Python that, among other things, will not have a GIL: http://code.google.com/p/unladen-swallow/ There was even a successful attempt to remove the GIL from CPython, but it caused single threaded python code to be much slower. See more here: http://www.python.org/doc/faq/library/#can-t-we-get-rid-of-the-global-interpreter-lock Cheers, Ben -- http://mail.python.org/mailman/listinfo/python-list
Re: Status of Python threading support (GIL removal)?
Digging through my problem, I discovered Python isn't exactly thread safe and to solve the issue, there's this Global Interpreter Lock (GIL) in place. It's the opposite: Python is exactly thread safe precisely because it has the GIL in place. Is there any other way to work around the issue aside from forking new processes or using something else? If you know that your (C) code is thread safe on its own, you can release the GIL around long-running algorithms, thus using as many CPUs as you have available, in a single process. Regards, Martin -- http://mail.python.org/mailman/listinfo/python-list
Re: Status of Python threading support (GIL removal)?
Digging through my problem, I discovered Python isn't exactly thread safe and to solve the issue, there's this Global Interpreter Lock (GIL) in place. It's the opposite: Python is exactly thread safe precisely because it has the GIL in place. Is there any other way to work around the issue aside from forking new processes or using something else? If you know that your (C) code is thread safe on its own, you can release the GIL around long-running algorithms, thus using as many CPUs as you have available, in a single process. Regards, Martin -- http://mail.python.org/mailman/listinfo/python-list
Re: Status of Python threading support (GIL removal)?
On 19 juin, 11:52, Jure Erznožnik jure.erznoz...@gmail.com wrote: See here for introduction:http://groups.google.si/group/comp.lang.python/browse_thread/thread/3... Digging through my problem, I discovered Python isn't exactly thread safe and to solve the issue, there's this Global Interpreter Lock (GIL) in place. Effectively, this causes the interpreter to utilize one core when threading is not used and .95 of a core when threading is utilized. Is there any work in progess on core Python modules that will permanently resolve this issue? Is there any other way to work around the issue aside from forking new processes or using something else? hi, please read this carefully, http://www.ibm.com/developerworks/aix/library/au-multiprocessing/ index.html?ca=dgr-lnxw07Python- MultiS_TACT=105AGX59S_CMP=grsitelnxw07 there is a solution for Python on multi-core : multiprocessing api. Really nice. http://docs.python.org/library/functions.html Keep real threads for common tasks like network stuff for example. I recently complained too :-) http://groups.google.com/group/comp.lang.python/browse_frm/thread/ dbe0836d9602f322# Olivier -- http://mail.python.org/mailman/listinfo/python-list
Re: Status of Python threading support (GIL removal)?
Jure Erznožnik wrote: See here for introduction: http://groups.google.si/group/comp.lang.python/browse_thread/thread/370f8a1747f0fb91 Digging through my problem, I discovered Python isn't exactly thread safe and to solve the issue, there's this Global Interpreter Lock (GIL) in place. Effectively, this causes the interpreter to utilize one core when threading is not used and .95 of a core when threading is utilized. You might want to read about The Problem with Threads: http://www.eecs.berkeley.edu/Pubs/TechRpts/2006/EECS-2006-1.pdf and then decide to switch to an appropriate concurrency model for your use case. Stefan -- http://mail.python.org/mailman/listinfo/python-list
Re: Status of Python threading support (GIL removal)?
Jure Erznožnik wrote: See here for introduction: http://groups.google.si/group/comp.lang.python/browse_thread/thread/370f8a1747f0fb91 Digging through my problem, I discovered Python isn't exactly thread safe and to solve the issue, there's this Global Interpreter Lock (GIL) in place. Effectively, this causes the interpreter to utilize one core when threading is not used and .95 of a core when threading is utilized. Python does not have (or not have) GIL. It is an implementation issue. CPython uses it, to good effect. Is there any work in progess on core Python modules that will permanently resolve this issue? Is there any other way to work around the issue aside from forking new processes or using something else? Use one of the other implementations. Jython, IronPython, Pypy, ??? -- http://mail.python.org/mailman/listinfo/python-list
Re: Status of Python threading support (GIL removal)?
On 19 juin, 16:16, Martin von Loewis martin.vonloe...@hpi.uni-: If you know that your (C) code is thread safe on its own, you can release the GIL around long-running algorithms, thus using as many CPUs as you have available, in a single process. what do you mean ? Cpython can't benefit from multi-core without multiple processes. Olivier -- http://mail.python.org/mailman/listinfo/python-list
Re: Status of Python threading support (GIL removal)?
CPython itself can't... but the c extension can. Mine did. On Fri, Jun 19, 2009 at 9:50 AM, OdarR olivier.da...@gmail.com wrote: On 19 juin, 16:16, Martin von Loewis martin.vonloe...@hpi.uni-: If you know that your (C) code is thread safe on its own, you can release the GIL around long-running algorithms, thus using as many CPUs as you have available, in a single process. what do you mean ? Cpython can't benefit from multi-core without multiple processes. Olivier -- http://mail.python.org/mailman/listinfo/python-list -- Visit my blog at http://oddco.ca/zeroth/zblog -- http://mail.python.org/mailman/listinfo/python-list
Re: Status of Python threading support (GIL removal)?
If you know that your (C) code is thread safe on its own, you can release the GIL around long-running algorithms, thus using as many CPUs as you have available, in a single process. Olivier what do you mean ? Olivier Cpython can't benefit from multi-core without multiple Olivier processes. It can, precisely as Martin indicated. Only one thread at a time can hold the GIL. That doesn't mean that multiple threads can't execute. Suppose you have two threads, one of which winds up executing some bit of C code which doesn't mess with the Python run-time at all (say, a matrix multiply). Before launching into the matrix multiply, the extension module releases the GIL then performs the multiply. With the GIL released another thread can acquire it. Once the multiply finishes the first thread needs to reacquire the GIL before executing any calls into the Python runtime or returning. -- Skip Montanaro - s...@pobox.com - http://www.smontanaro.net/ when i wake up with a heart rate below 40, i head right for the espresso machine. -- chaos @ forums.usms.org -- http://mail.python.org/mailman/listinfo/python-list
Re: Status of Python threading support (GIL removal)?
On 19 juin, 19:13, s...@pobox.com wrote: Olivier what do you mean ? Olivier Cpython can't benefit from multi-core without multiple Olivier processes. It can, precisely as Martin indicated. Only one thread at a time can hold the GIL. That doesn't mean that multiple threads can't execute. Suppose I don't say multiple threads can't execute(?). I say that with the Python library, I don't see (yet) benefit with multiple threads *on* multiple CPU/core. Ever seen this recent video/presentation ? : http://blip.tv/file/2232410 http://www.dabeaz.com/python/GIL.pdf you have two threads, one of which winds up executing some bit of C code which doesn't mess with the Python run-time at all (say, a matrix multiply). I don't know how to do that with common Python operations... Only one thread will be really running at a time in memory (meanwhile other thread are waiting). Are you refering to a specialized code ? Before launching into the matrix multiply, the extension module releases the GIL then performs the multiply. With the GIL released another thread can acquire it. Once the multiply finishes the first thread needs to reacquire the GIL before executing any calls into the Python runtime or returning. I don't see such improvement in the Python library, or maybe you can indicate us some meaningfull example...? I currently only use CPython, with PIL, Reportlab...etc. I don't see improvement on a Core2duo CPU and Python. How to proceed (following what you wrote) ? A contrario, I saw *real* improvement on parallel computing with the Py 2.6 multiprocessing module. Olivier -- http://mail.python.org/mailman/listinfo/python-list
Re: Status of Python threading support (GIL removal)?
OdarR wrote: I don't see such improvement in the Python library, or maybe you can indicate us some meaningfull example...? I currently only use CPython, with PIL, Reportlab...etc. I don't see improvement on a Core2duo CPU and Python. How to proceed (following what you wrote) ? I've seen a single Python process using the full capacity of up to 8 CPUs. The application is making heavy use of lxml for large XSL transformations, a database adapter and my own image processing library based upon FreeImage. Of course both lxml and my library are written with the GIL in mind. They release the GIL around every call to C libraries that don't touch Python objects. PIL releases the lock around ops as well (although it took me a while to figure it out because PIL uses its own API instead of the standard macros). reportlab has some optional C libraries that increase the speed, too. Are you using them? By the way threads are evil (http://www.eecs.berkeley.edu/Pubs/TechRpts/2006/EECS-2006-1.pdf) and not *the* answer to concurrency. Christian -- http://mail.python.org/mailman/listinfo/python-list
Re: Status of Python threading support (GIL removal)?
On Jun 19, 6:53 am, Ben Charrow bchar...@csail.mit.edu wrote: Jure Erznožnik wrote: See here for introduction: http://groups.google.si/group/comp.lang.python/browse_thread/thread/3... Digging through my problem, I discovered Python isn't exactly thread safe and to solve the issue, there's this Global Interpreter Lock (GIL) in place. Effectively, this causes the interpreter to utilize one core when threading is not used and .95 of a core when threading is utilized. Is there any work in progess on core Python modules that will permanently resolve this issue? Is there any other way to work around the issue aside from forking new processes or using something else? There is a group of people working on an alternative implementation to Python that, among other things, will not have a GIL:http://code.google.com/p/unladen-swallow/ That's not a foregone conclusion. Well it's not a foregone conclusion that unladen-swallow will succeed at all, but even if it does they only say they intend to remove the GIL, not that they necessarily will. The GIL actually solves two problems: the overhead of synchronizing reference counts, and the difficulty of writing threaded extensions. The unladen-swallow team only address the first problem in their plans. So, even if they do remove the GIL, I doubt GvR will allow it to be merged back into CPython unless makes extensions are just as easy to write. That is something I have serious doubts they can pull off. Which means a GIL-less unladen-swallow is likely to end being another fork like IronPython and Jython. Those projects already have no GIL. Carl Banks -- http://mail.python.org/mailman/listinfo/python-list
Re: Status of Python threading support (GIL removal)?
On Jun 19, 11:08 am, OdarR olivier.da...@gmail.com wrote: On 19 juin, 19:13, s...@pobox.com wrote: Olivier what do you mean ? Olivier Cpython can't benefit from multi-core without multiple Olivier processes. It can, precisely as Martin indicated. Only one thread at a time can hold the GIL. That doesn't mean that multiple threads can't execute. Suppose I don't say multiple threads can't execute(?). I say that with the Python library, I don't see (yet) benefit with multiple threads *on* multiple CPU/core. He's saying that if your code involves extensions written in C that release the GIL, the C thread can run on a different core than the Python-thread at the same time. The GIL is only required for Python code, and C code that uses the Python API. C code that spends a big hunk of time not using any Python API (like, as Skip pointed out, a matrix multiply) can release the GIL and the thread can run on a different core at the same time. I always found to be a *terribly* weak rationalization. The fact is, few Python developers can take much advantage of this. (Note: I'm not talking about releasing the GIL for I/O operations, it's not the same thing. I'm talking about the ability to run computations on multiple cores at the same time, not to block in 50 threads at the same time. Multiple cores aren't going to help that much in the latter case.) I wish Pythonistas would be more willing to acknowledge the (few) drawbacks of the language (or implementation, in this case) instead of all this rationalization. It's like people here in Los Angeles who complain about overcast days. What, 330 days of sunshine not enough? Jesus. I wish people would just say, This is a limitation of CPython. There are reasons why it's there, and it helps some people, but unfortunately it has drawbacks for others, instead of the typical all u hav 2 do is rite it in C LOL. Carl Banks -- http://mail.python.org/mailman/listinfo/python-list
Re: Status of Python threading support (GIL removal)?
Thanks guys, for all the replies. They were some very interesting reading / watching. Seems to me, the Unladen-Swallow might in time produce code which will have this problem lessened a bit. Their roadmap suggests at least modifying the GIL principles if not fully removing it. On top of this, they seem to have a pretty aggressive schedule with good results expected by Q3 this year. I'm hoping that their patches will be accepted to cPython codebase in a timely manner. I definitely liket the speed improvements they showed for Q1 modifications. Though those improvements don't help my case yet... The presentation from mr. Beasley was hilarious :D I find it curious to learn that just simple replacement from events to actual mutexes already lessens the problem a lot. This should already be implemented in the cPython codebase IMHO. As for multiprocessing alternatives, I'll have to look into them. I haven't yet done multiprocessing code and don't really know what will happen when I try. I believe that threads would be much more appropriate for my project, but it's definitely worth a shot. Since my project is supposed to be cross platform, I'm not really looking forward to learning cross platform for C++. All my C++ experience is DOS + Windows derivatives till now :( -- http://mail.python.org/mailman/listinfo/python-list
Re: Status of Python threading support (GIL removal)?
On 19 juin, 21:05, Christian Heimes li...@cheimes.de wrote: I've seen a single Python process using the full capacity of up to 8 CPUs. The application is making heavy use of lxml for large XSL transformations, a database adapter and my own image processing library based upon FreeImage. interesting... Of course both lxml and my library are written with the GIL in mind. They release the GIL around every call to C libraries that don't touch Python objects. PIL releases the lock around ops as well (although it took me a while to figure it out because PIL uses its own API instead of the standard macros). reportlab has some optional C libraries that increase the speed, too. Are you using them? I don't. Or maybe I did, but I have no clue what to test. Do you have a real example, some code snippet to can prove/show activity on multiple core ? I accept your explanation, but I also like experiencing :) By the way threads are evil (http://www.eecs.berkeley.edu/Pubs/TechRpts/2006/EECS-2006-1.pdf) and not *the* answer to concurrency. I don't see threads as evil from my little experience on the subject, but we need them. I'm reading what's happening in the java world too, it can be interesting. Olivier -- http://mail.python.org/mailman/listinfo/python-list
Re: Status of Python threading support (GIL removal)?
Sorry, just a few more thoughts: Does anybody know why GIL can't be made more atomic? I mean, use different locks for different parts of code? This way there would be way less blocking and the plugin interface could remain the same (the interpreter would know what lock it used for the plugin, so the actual function for releasing / reacquiring the lock could remain the same) On second thought, forget this. This is probably exactly the cause of free-threading reduced performance. Fine-graining the locks increased the lock count and their implementation is rather slow per se. Strange that *nix variants don't have InterlockedExchange, probably because they aren't x86 specific. I find it strange that other architectures wouldn't have these instructions though... Also, an OS should still be able to support such a function even if underlying architecture doesn't have it. After all, a kernel knows what it's currently running and they are typically not preempted themselves. Also, a beside question: why does python so like to use events instead of true synchronization objects? Almost every library I looked at used that. IMHO that's quite irrational. Using objects that are intended for something else for the job while there are plenty of true options supported in every OS out there. Still, the free-threading mod could still work just fine if there was just one more global variable added: current python thread count. A simple check for value greater than 1 would trigger the synchronization code, while having just one thread would introduce no locking at all. Still, I didn't like the performance figures of the mod (0.6 execution speed, pretty bad core / processor scaling) I don't know why it's so hard to do simple locking just for writes to globals. I used to do it massively and it always worked almost with no penalty at all. It's true that those were all Windows programs, using critical sections. -- http://mail.python.org/mailman/listinfo/python-list
Re: Status of Python threading support (GIL removal)?
On 19 juin, 21:41, Carl Banks pavlovevide...@gmail.com wrote: He's saying that if your code involves extensions written in C that release the GIL, the C thread can run on a different core than the Python-thread at the same time. The GIL is only required for Python code, and C code that uses the Python API. C code that spends a big hunk of time not using any Python API (like, as Skip pointed out, a matrix multiply) can release the GIL and the thread can run on a different core at the same time. I understand the idea, even if I don't see any examples in the standard library. any examples ? (Note: I'm not talking about releasing the GIL for I/O operations, it's not the same thing. I'm talking about the ability to run computations on multiple cores at the same time, not to block in 50 threads at the same time. Multiple cores aren't going to help that much in the latter case.) yes, I also speak about hard computation that could benefit with multiple cores. I wish Pythonistas would be more willing to acknowledge the (few) drawbacks of the language (or implementation, in this case) instead of all this rationalization. It's like people here in Los Angeles who complain about overcast days. What, 330 days of sunshine not enough? Jesus. I wish people would just say, This is a limitation of CPython. There are reasons why it's there, and it helps some people, but unfortunately it has drawbacks for others, instead of the typical all u hav 2 do is rite it in C LOL. LOL I would like to say such thing about my weather...I live in Europe in a rainy country. Olivier -- http://mail.python.org/mailman/listinfo/python-list
Re: Status of Python threading support (GIL removal)?
On Fri, Jun 19, 2009 at 12:50 PM, OdarRolivier.da...@gmail.com wrote: On 19 juin, 16:16, Martin von Loewis martin.vonloe...@hpi.uni-: If you know that your (C) code is thread safe on its own, you can release the GIL around long-running algorithms, thus using as many CPUs as you have available, in a single process. what do you mean ? Cpython can't benefit from multi-core without multiple processes. Olivier Sorry, you're incorrect. I/O Bound threads do in fact, take advantage of multiple cores. -- http://mail.python.org/mailman/listinfo/python-list
Re: Status of Python threading support (GIL removal)?
On Jun 19, 11:45 pm, OdarR olivier.da...@gmail.com wrote: On 19 juin, 21:05, Christian Heimes li...@cheimes.de wrote: I've seen a single Python process using the full capacity of up to 8 CPUs. The application is making heavy use of lxml for large XSL transformations, a database adapter and my own image processing library based upon FreeImage. interesting... Of course both lxml and my library are written with the GIL in mind. They release the GIL around every call to C libraries that don't touch Python objects. PIL releases the lock around ops as well (although it took me a while to figure it out because PIL uses its own API instead of the standard macros). reportlab has some optional C libraries that increase the speed, too. Are you using them? I don't. Or maybe I did, but I have no clue what to test. Do you have a real example, some code snippet to can prove/show activity on multiple core ? I accept your explanation, but I also like experiencing :) By the way threads are evil (http://www.eecs.berkeley.edu/Pubs/TechRpts/2006/EECS-2006-1.pdf) and not *the* answer to concurrency. I don't see threads as evil from my little experience on the subject, but we need them. I'm reading what's happening in the java world too, it can be interesting. Olivier Olivier, What Christian is saying is that you can write a C/C++ Python plugin, release the GIL inside it and then process stuff in threads inside the plugin. All this is possible if the progammer doesn't use any Python objects and it's fairly easy to write such a plugin. Any counting example will do just fine. The problem with this solution is that you have to write the code in C which quite defeats the purpose of using an interpreter in the first place... Of course, no pure python code will currently utilize multiple cores (because of GIL). I do aggree though that threading is important. Regardless of any studies showing that threads suck, they are here and they offer relatively simple concurrency. IMHO they should never have been crippled like this. Even though GIL solves access violations, it's not the right approach. It simply kills all threading benefits except for the situation where you work with multiple I/O blocking threads. That's just about the only situation where this problem is not apparent. We're way past single processor single core computers now. An important product like Python should support these architectures properly even if only 1% of applications written in it use threading. But as Guido himself said; I should not complain but instead try to contribute to solution. That's the hard part, especially since there's lots of code that actually need the locking. -- http://mail.python.org/mailman/listinfo/python-list
Re: Status of Python threading support (GIL removal)?
On Jun 19, 11:59 pm, Jesse Noller jnol...@gmail.com wrote: On Fri, Jun 19, 2009 at 12:50 PM, OdarRolivier.da...@gmail.com wrote: On 19 juin, 16:16, Martin von Loewis martin.vonloe...@hpi.uni-: If you know that your (C) code is thread safe on its own, you can release the GIL around long-running algorithms, thus using as many CPUs as you have available, in a single process. what do you mean ? Cpython can't benefit from multi-core without multiple processes. Olivier Sorry, you're incorrect. I/O Bound threads do in fact, take advantage of multiple cores. Incorrect. They take advantage of OS threading support where another thread can run while one is blocked for I/O. That is not equal to running on multiple cores (though it actually does do that, just that cores are all not well utilized - sum(x) 100% of one core). You wil get better performance running on single core because of the way GIL is implemented in all cases. -- http://mail.python.org/mailman/listinfo/python-list
Re: Status of Python threading support (GIL removal)?
On 19 Jun, 21:41, Carl Banks pavlovevide...@gmail.com wrote: (Note: I'm not talking about releasing the GIL for I/O operations, it's not the same thing. I'm talking about the ability to run computations on multiple cores at the same time, not to block in 50 threads at the same time. Multiple cores aren't going to help that much in the latter case.) There seems to be a mixing together of these two things when people talk about concurrency. Indeed, on the concurrency-sig mailing list [1] there's already been discussion about whether a particular example [2] is really a good showcase of concurrency. According to Wikipedia, concurrency is about computations [...] executing simultaneously [3], not about whether one can handle hundreds of communications channels sequentially, although this topic is obviously relevant when dealing with communications between processing contexts. I agree with the over-rationalisation assessment: it's not convenient (let alone an advantage) for people to have to switch to C so that they can release the GIL, nor is it any comfort that CPython's limitations are acceptable for the socket multiplexing server style of solution when that isn't the kind of solution being developed. However, there are some reasonable tools out there (and viable alternative implementations), and I'm optimistic that the situation will only improve. Paul [1] http://mail.python.org/mailman/listinfo/concurrency-sig [2] http://wiki.python.org/moin/Concurrency/99Bottles [3] http://en.wikipedia.org/wiki/Concurrency_(computer_science) -- http://mail.python.org/mailman/listinfo/python-list
Re: Status of Python threading support (GIL removal)?
On Fri, Jun 19, 2009 at 6:10 PM, Jure Erznožnikjure.erznoz...@gmail.com wrote: On Jun 19, 11:59 pm, Jesse Noller jnol...@gmail.com wrote: On Fri, Jun 19, 2009 at 12:50 PM, OdarRolivier.da...@gmail.com wrote: On 19 juin, 16:16, Martin von Loewis martin.vonloe...@hpi.uni-: If you know that your (C) code is thread safe on its own, you can release the GIL around long-running algorithms, thus using as many CPUs as you have available, in a single process. what do you mean ? Cpython can't benefit from multi-core without multiple processes. Olivier Sorry, you're incorrect. I/O Bound threads do in fact, take advantage of multiple cores. Incorrect. They take advantage of OS threading support where another thread can run while one is blocked for I/O. That is not equal to running on multiple cores (though it actually does do that, just that cores are all not well utilized - sum(x) 100% of one core). You wil get better performance running on single core because of the way GIL is implemented in all cases. No. That's simply incorrect. I (and others) have seen significant increases in threaded, I/O bound code using multiple cores. It's not perfect, but it is faster. -- http://mail.python.org/mailman/listinfo/python-list
Re: Status of Python threading support (GIL removal)?
In article d6d695d8-2af6-4713-bcbf-587e19e16...@n4g2000vba.googlegroups.com, =?windows-1252?Q?Jure_Erzno=9Enik?= jure.erznoz...@gmail.com wrote: I do aggree though that threading is important. Regardless of any studies showing that threads suck, they are here and they offer relatively simple concurrency. IMHO they should never have been crippled like this. Even though GIL solves access violations, it's not the right approach. It simply kills all threading benefits except for the situation where you work with multiple I/O blocking threads. That's just about the only situation where this problem is not apparent. NumPy? -- Aahz (a...@pythoncraft.com) * http://www.pythoncraft.com/ as long as we like the same operating system, things are cool. --piranha -- http://mail.python.org/mailman/listinfo/python-list
Re: Status of Python threading support (GIL removal)?
In article 157e0345-74e0-4144-a2e6-2b4cc854c...@z7g2000vbh.googlegroups.com, Carl Banks pavlovevide...@gmail.com wrote: I wish Pythonistas would be more willing to acknowledge the (few) drawbacks of the language (or implementation, in this case) instead of all this rationalization. Please provide more evidence that Pythonistas are unwilling to acknowledge the drawbacks of the GIL. I think you're just spreading FUD. The problem is that discussions about the GIL almost invariably include false statements about the GIL, and I'm certainly not going to hamper my writing to always include the caveats about GIL drawbacks while correcting the wrong information. -- Aahz (a...@pythoncraft.com) * http://www.pythoncraft.com/ as long as we like the same operating system, things are cool. --piranha -- http://mail.python.org/mailman/listinfo/python-list
Re: Status of Python threading support (GIL removal)?
In article f9ff1a89-813b-4367-9e95-570ab2bac...@h23g2000vbc.googlegroups.com, =?windows-1252?Q?Jure_Erzno=9Enik?= jure.erznoz...@gmail.com wrote: On Jun 19, 11:59=A0pm, Jesse Noller jnol...@gmail.com wrote: Sorry, you're incorrect. I/O Bound threads do in fact, take advantage of multiple cores. Incorrect. They take advantage of OS threading support where another thread can run while one is blocked for I/O. That is not equal to running on multiple cores (though it actually does do that, just that cores are all not well utilized - sum(x) 100% of one core). You wil get better performance running on single core because of the way GIL is implemented in all cases. You should put up or shut up -- I've certainly seen multi-core speedup with threaded software, so show us your benchmarks! -- Aahz (a...@pythoncraft.com) * http://www.pythoncraft.com/ as long as we like the same operating system, things are cool. --piranha -- http://mail.python.org/mailman/listinfo/python-list
Re: Status of Python threading support (GIL removal)?
OdarR schrieb: On 19 juin, 21:41, Carl Banks pavlovevide...@gmail.com wrote: He's saying that if your code involves extensions written in C that release the GIL, the C thread can run on a different core than the Python-thread at the same time. The GIL is only required for Python code, and C code that uses the Python API. C code that spends a big hunk of time not using any Python API (like, as Skip pointed out, a matrix multiply) can release the GIL and the thread can run on a different core at the same time. I understand the idea, even if I don't see any examples in the standard library. any examples ? http://svn.python.org/view/python/trunk/Modules/posixmodule.c?revision=72882view=markup Search for Py_BEGIN_ALLOW_THREADS / Py_END_ALLOW_THREADS yes, I also speak about hard computation that could benefit with multiple cores. Hard computations gain more speed from carefully crafted C or Fortran code that utilizes features like the L1 and L2 CPU cache, SIMD etc. or parallelized algorithms. If you start sharing values between multiple cores you have a serious problem. Oh, and use NumPy for the job ;) I wish people would just say, This is a limitation of CPython. There are reasons why it's there, and it helps some people, but unfortunately it has drawbacks for others, instead of the typical all u hav 2 do is rite it in C LOL. LOL I would like to say such thing about my weather...I live in Europe in a rainy country. It *is* a well known limitation of Python. All the nice 'n shiny syntax and features are coming with a cost. Python is a powerful language and good tool for lots of stuff. But Python is and will never become the übertool that solves every problem perfectly. At some point you need a different tool to get the raw power of your machine. C (and perhaps Fortran) are the weapons of choice for number crunching. Christian -- http://mail.python.org/mailman/listinfo/python-list
Re: Status of Python threading support (GIL removal)?
On Jun 20, 1:36 am, a...@pythoncraft.com (Aahz) wrote: You should put up or shut up -- I've certainly seen multi-core speedup with threaded software, so show us your benchmarks! -- Sorry, no intent to offend anyone here. Flame wars are not my thing. I have shown my benchmarks. See first post and click on the link. That's the reason I started this discussion. All I'm saying is that you can get threading benefit, but only if the threading in question is implemented in C plugin. I have yet to see pure Python code which does take advantage of multiple cores. From what I read about GIL, this is simply impossible by design. But I'm not disputing the fact that cPython as a whole can take advantage of multiple cores. There certainly are built-in objects that work as they should. -- http://mail.python.org/mailman/listinfo/python-list
Re: Status of Python threading support (GIL removal)?
Aahz wrote: In article 157e0345-74e0-4144-a2e6-2b4cc854c...@z7g2000vbh.googlegroups.com, Carl Banks pavlovevide...@gmail.com wrote: I wish Pythonistas would be more willing to acknowledge the (few) drawbacks of the language (or implementation, in this case) instead of all this rationalization. Please provide more evidence that Pythonistas are unwilling to acknowledge the drawbacks of the GIL. I think you're just spreading FUD. The problem is that discussions about the GIL almost invariably include false statements about the GIL, and I'm certainly not going to hamper my writing to always include the caveats about GIL drawbacks while correcting the wrong information. Aahz, my magic pixie dust bag is empty. Do you have some spare dust to remove the cursed GIL all alone? :p Christian -- http://mail.python.org/mailman/listinfo/python-list
Re: Status of Python threading support (GIL removal)?
Jesse Noller jnol...@gmail.com wrote: Sorry, you're incorrect. I/O Bound threads do in fact, take advantage of multiple cores. jure.erznoz...@gmail.com wrote: Incorrect. They take advantage of OS threading support where another thread can run while one is blocked for I/O. That is not equal to running on multiple cores (though it actually does do that, just that cores are all not well utilized - sum(x) 100% of one core). You wil get better performance running on single core because of the way GIL is implemented in all cases. Aahz a...@pythoncraft.com wrote: You should put up or shut up -- I've certainly seen multi-core speedup with threaded software, so show us your benchmarks! By definition an I/O bound thread isn't CPU bound so won't benefit from improved CPU resources. Ross Ridge -- l/ // Ross Ridge -- The Great HTMU [oo][oo] rri...@csclub.uwaterloo.ca -()-/()/ http://www.csclub.uwaterloo.ca/~rridge/ db // -- http://mail.python.org/mailman/listinfo/python-list
Re: Status of Python threading support (GIL removal)?
Jure Erznožnik wrote: On Jun 20, 1:36 am, a...@pythoncraft.com (Aahz) wrote: You should put up or shut up -- I've certainly seen multi-core speedup with threaded software, so show us your benchmarks! -- Sorry, no intent to offend anyone here. Flame wars are not my thing. I have shown my benchmarks. See first post and click on the link. That's the reason I started this discussion. All I'm saying is that you can get threading benefit, but only if the threading in question is implemented in C plugin. I have yet to see pure Python code which does take advantage of multiple cores. From what I read about GIL, this is simply impossible by design. But I'm not disputing the fact that cPython as a whole can take advantage of multiple cores. There certainly are built-in objects that work as they should. I never used threading together with I/O intensively before, but I heard that I/O operations releases the GIL, and such they're similar to GIL-releasing C extensions which makes it possible to benefit from multicore in I/O bound pure python code. Perhaps we should have more built-in/stdlib operations that can release GIL safely to release GIL by default? And perhaps some builtin/stdlib should receive an optional argument that instruct them to release GIL and by passing this argument, you're making a contract that you wouldn't do certain things that would disturb the builtin/stdlib's operations; the specifics of what operations are prohibited would be noted on their docs. -- http://mail.python.org/mailman/listinfo/python-list
Re: Status of Python threading support (GIL removal)?
On Sat, 20 Jun 2009 00:07:27 GMT, Lie Ryan lie.1...@gmail.com wrote: [snip] Perhaps we should have more built-in/stdlib operations that can release GIL safely to release GIL by default? And perhaps some builtin/stdlib should receive an optional argument that instruct them to release GIL and by passing this argument, you're making a contract that you wouldn't do certain things that would disturb the builtin/stdlib's operations; the specifics of what operations are prohibited would be noted on their docs. There would be a lot less useless discussion if people would do a minimal amount of checking to see if the ideas they're suggesting are at all feasible. Why don't you take a look at the CPython source and see if this is actually possible? If you're not comfortable diving into a C program, then maybe you could try to become so first, or refrain from making suggestions that rely on technical details you know nothing about? Jean-Paul -- http://mail.python.org/mailman/listinfo/python-list
Re: Threading and GIL
Hi, thats the reason why its not working. Imagine the end() method of the thread object is called so the C++ Function is opened where the code for this method is in. At a line the Code ...-End() is called which waits that the C++ Thread class is finished. BUT here is the problem: In the Method of the C++ class which is in threaded mode can't run because its still waiting that the GIL is released by the thread which executed the -End() command. So the app has a deadlock when it arrives at -End() and PyGILState_Ensure function. -- http://mail.python.org/mailman/listinfo/python-list
Re: Threading and GIL
On May 7, 12:20 am, googler.1.webmas...@spamgourmet.com wrote:
thats the reason why its not working. Imagine the end() method of the
thread object is called so the C++ Function is opened where the code
for this method is in.
You're going to have to post some code if you want better help; this
description is unintelligible. I don't know what you mean by end()
method, nor whether it's a Python method or C++ method, nor what
exactly you mean by thread object (C++ or Python object?) or C++
Function.
At a line the Code ...-End() is called which waits that the C++
Thread class
is finished. BUT here is the problem: In the Method of the C++ class
which is in threaded mode can't run because its still waiting that the
GIL
is released by the thread which executed the -End() command.
So the app has a deadlock when it arrives at -End() and
PyGILState_Ensure
function.
So you have to release the GIL before calling End(). Just surround End
() by Py_BEGIN_ALLOW_THREADS and Py_END_ALLOW_THREADS. (Presumably
you know the thread state when you call End(); if you don't then
surround the calls to Py_{BEGIN,END}_ALLOW_THREADS with calls to
PyGILState_{Ensure,Release}. Yes, that means you acquire the GIL just
so you can be sure that you've released it. I know of no other way to
be sure you don't have the GIL.)
If you are trying to kill a different thread, and I can't quite tell
if that's what you're doing, then be aware that it is very tricky to
do right and most think it to be a bad idea. If you don't allow the
thread you're killing to clean up it can deadlock, and even if you do,
you have to be careful to clean up properly and you have to be
constantly on guard for what might happen in a thread is killed in the
middle of something.
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
Re: Threading and GIL
hey, thanks, that works fine. I wrapped it around, done a lot of tests and it works fine. Just had done a few other things to make it stable. cheers. -- http://mail.python.org/mailman/listinfo/python-list
Threading and GIL
Hi! I have a big problem I can't solve and I hope anyone of you can help me. I use the Python C API and in C++ I have a class which represets a thread object, similiar to the thread class of the known Python Thread class but with some needed additions so thats the reason why I have to built my own. Well, this is the problem. There is a method called Thread::End() which I can call in Python. But now the End() Function waits until the Main Function of my C++ class is done, but in this method I want to ensure the Global Interpreter Lock but this is already locked by the Thread which executes the End() command. So both is waiting and stops. The thread which calls the End () method is waiting for the finish of the Main() method of the Thread Class and the Main-Method in the other thread waits for the thread of the End() command that this is done - welcome Deadlock. Any suggestions what I have to do? Thank you veeery much for you help, otherwise I become really crazy here because this is the first time I have such a problem. Bye :) -- http://mail.python.org/mailman/listinfo/python-list
Re: Threading and GIL
On May 6, 5:13 pm, googler.1.webmas...@spamgourmet.com wrote: Hi! I have a big problem I can't solve and I hope anyone of you can help me. I use the Python C API and in C++ I have a class which represets a thread object, similiar to the thread class of the known Python Thread class but with some needed additions so thats the reason why I have to built my own. Well, this is the problem. There is a method called Thread::End() which I can call in Python. But now the End() Function waits until the Main Function of my C++ class is done, but in this method I want to ensure the Global Interpreter Lock but this is already locked by the Thread which executes the End() command. So both is waiting and stops. The thread which calls the End () method is waiting for the finish of the Main() method of the Thread Class and the Main-Method in the other thread waits for the thread of the End() command that this is done - welcome Deadlock. Any suggestions what I have to do? Thank you veeery much for you help, otherwise I become really crazy here because this is the first time I have such a problem. Bye :) You can try the PyGILState_Ensure and PyGILState_Release macros (see PEP 311, http://www.python.org/dev/peps/pep-0311/ for more information). Make sure you have the GIL whenever you make any calls into Python (with a couple exceptions) and make sure you DON'T have the GIL when creating or deleting threads. In fact, I can't think of any reason why it wouldn't work to ensure a GIL state first thing after the thread starts and to release it right before the thread ends. Carl Banks -- http://mail.python.org/mailman/listinfo/python-list
