On Mon, 05 Sep 2005 21:43:07 +0100, Michael Sparks <[EMAIL PROTECTED]> 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. 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. > >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? 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 That argument makes some sense, but I'm still not sure I agree. Rather than make Python programmers have to deal with concurrentcy issues in every app to get it to make good use of the hardware it's on, why not have many of the common libraries that Python uses to do processing take advantage of SMP when you use them. A database server is a good example of a way we can already do some of that today. Also, what if things like hash table updates were made lazy (if they aren't already) and could be processed as background operations to have the table more likely to be ready when the next hash lookup occurs. -- http://mail.python.org/mailman/listinfo/python-list
