Michael Sparks wrote: >Steve Jorgensen wrote: > > > >>On 05 Sep 2005 10:29:48 GMT, Nick Craig-Wood <[EMAIL PROTECTED]> wrote: >> >> >> >>>Jeremy Jones <[EMAIL PROTECTED]> wrote: >>> >>> >>>> One Python process will only saturate one CPU (at a time) because >>>> of the GIL (global interpreter lock). >>>> >>>> >>>I'm hoping python won't always be like this. >>> >>> >>I don't get that. Python was never designed to be a high performance >>language, so why add complexity to its implementation by giving it >>high-performance capabilities like SMP? >> >> > >It depends on personal perspective. > Ummmm....not totally. It depends on what you're doing. If what you're doing is not going to be helped by scaling across a bunch of CPUs, then you're just as well off if Python still has the GIL. Sort of. Steve brings up an interesting argument of making the language do some of your thinking for you. Maybe I'll address that momentarily....
I'm not saying I wish the GIL would stay around. I wish it would go. As the price of computers goes down, the number of CPUs per computer goes up, and the price per CPU in a single system goes down, the ability to utilize a bunch of CPUs is going to become more important. And maybe Steve's magical thinking programming language will have a ton of merit. >If in a few years time we all have >machines with multiple cores (eg the CELL with effective 9 CPUs on a chip, >albeit 8 more specialised ones), would you prefer that your code *could* >utilise your hardware sensibly rather than not. > > I'm not picking on you. Trust me. But let me play devil's advocate for a sec. Let's say we *could* fully utilize a multi CPU today with Python. What has that bought us (as the amorphous "we" of the Python community)? I would almost bet money that the majority of code would not be helped by that at all. I'd almost bet that the vast majority of Python code out there runs single threaded and would see no performance boost whatsoever. Who knows, maybe that's why we still have the GIL. >Or put another way - would you prefer to write your code mainly in a >language like python, or mainly in a language like C or Java? > There are benefits to writing code in C and Java apart from concurrency. Most of them are massochistic, but there are benefits nonetheless. For my programming buck, Python wins hands down. But I agree with you. Python really should start addressing solutions for concurrent tasks that will benefit from simultaneously utilizing multiple CPUs. >If python, >it's worth worrying about! > >If it was python (or similar) you might "only" have to worry about >concurrency issues. If it's a language like C you might have to worry >about memory management, typing AND concurrency (oh my!). >(Let alone C++'s TMP :-) > >Regards, > > >Michael > > JMJ -- http://mail.python.org/mailman/listinfo/python-list
