Re: [Python-Dev] GIL, Python 3, and MP vs. UP (was Re: Variant of removing GIL.)
On Sun, 18 Sep 2005, Guido van Rossum wrote: On 9/17/05, John J Lee [EMAIL PROTECTED] wrote: [...snip...] [guido] If my hunch is right, I expect that instead of writing massively parallel applications, we will continue to write single-threaded applications that are tied together at the process level rather than at the thread level. I tend to agree. [...] I realize that not all algorithms (nor all computational problems) scale well to MP hardware. Is it feasible to usefully compile both MP and a UP binaries from one Python source code base? That's an understatement. I expect that *most* problems (even most problems that we will be programming 10-20 years from now) get little benefit out of MP. Perhaps, but I suspect we'll also get better at thinking up multiprocessor algorithms when better motivated by lack of exponential uniprocessor speed increases. ducks, fearing barrage of theorems... [...] Of course, it still takes a (anti-)hero to step forward and do the work... Be my guest. Prove me wrong. Talk is cheap; instead of arguing my points (all of which can be argued ad infinitum), come back when you've got a working GIL-free Python. Doesn't have to be CPython-based -- C# would be fine too. I don't actively want a GIL-free Python. I was just making some arguments in favour of GIL-removal that I hadn't seen made on a public list before. (In particular, removal now, since now is a special time.) John ___ 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] GIL, Python 3, and MP vs. UP (was Re: Variant of removing GIL.)
On Tue, 20 Sep 2005, John J Lee wrote: [...] I don't actively want a GIL-free Python. I was just making some arguments [...] Actually, FWIW, I don't know if I even *passively* want a GIL-free Python, if it encourages threaded code (though I'd like to have that option for my occasional personal use, it seems to be an attractive nuisance for many other programmers). John ___ 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] GIL, Python 3, and MP vs. UP (was Re: Variant of removing GIL.)
On 9/18/05, Guido van Rossum [EMAIL PROTECTED] wrote: On 9/17/05, John J Lee [EMAIL PROTECTED] wrote: c. Since time is needed to iron out bugs (and perhaps also to reimplememt some pieces of code from scratch), very early in the life of Python 3 seems like the least-worst time to begin work on such a change. I realize that not all algorithms (nor all computational problems) scale well to MP hardware. Is it feasible to usefully compile both MP and a UP binaries from one Python source code base? That's an understatement. I expect that *most* problems (even most problems that we will be programming 10-20 years from now) get little benefit out of MP. Some are saying it won't be a matter of choice if we want to get the software to run faster (you know, that MORE MORE MORE! thing we all seem to suffer from): http://www.gotw.ca/publications/concurrency-ddj.htm The Free Lunch Is Over: A Fundamental Turn Toward Concurrency in Software Herb Sutter March 2005 ___ 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
[Python-Dev] GIL, Python 3, and MP vs. UP (was Re: Variant of removing GIL.)
On Fri, 16 Sep 2005, Martin v. Löwis wrote: Sokolov Yura wrote: I think I know how to remove GIL Obviously I am an idiot. Not an idiot, just lazy :-) Please try to implement your ideas, and I predict that you will find: 1. it is a lot of work to implement 2. it requires changes to all C files, in particular to extension modules outside the Python source tree proper. 3. performing the conversion, even in a semi-mechanical way, will introduce many new bugs, in the form of race conditions because of missing locks. Optionally, you may also find that the performance of the interpreter will decrease. [...] Given the points you make, and the facts that both Python 3 and real problems with continuing to scale down semiconductor chip feature sizes are on the horizon, it seems that now would be an excellent time to start work on this, with the goal of introducing it at the same time as Python 3. a. Python 3.0 will break lots of code anyway, so the extension module issue becomes far less significant. b. In x years time (x 10?) it seems likely multiprocessor (MP) users will be in the majority. (As a result, the uniprocessor (UP) slowdown becomes less important in practice, and also Python has the opportunity of avoiding the risk of being sidelined by a real or perceived lack of MP performance.) c. Since time is needed to iron out bugs (and perhaps also to reimplememt some pieces of code from scratch), very early in the life of Python 3 seems like the least-worst time to begin work on such a change. I realize that not all algorithms (nor all computational problems) scale well to MP hardware. Is it feasible to usefully compile both MP and a UP binaries from one Python source code base? (I'm also quite aware that the GIL does not prevent all means of achieving efficient use of multiprocessors. I'm just concious that different parellisation problems are presumably best expressed using different tools, and that Python 3 and increased prevalance of MP systems might tip the balance in favour of removing the GIL.) Of course, it still takes a (anti-)hero to step forward and do the work... John ___ 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
