So do the new changes(to the GIL) nullify concerns raised by David
Beazely here http://dabeaz.com/python/UnderstandingGIL.pdf
Ah, good catch. I had watched the recorded presentation some time ago.
Yes, the rewritten GIL should alleviate those problems. Instead of
simply releasing and re-acquiring the GIL, it releases, then determines
thread scheduling using the brainfuck algorithm instead of leaving it
up to the kernel in the brief instant the GIL is unassigned (which
often doesn't context switch to another thread, thus the performance
penalty).
(I beleive that algorithm, whose name -is- accurate, was the winner of
the long, long discussion on the Python ticket.)
Some projects have been using and requiring psyco to gain speed
improvements in python http://psyco.sourceforge.net/introduction.html
however it seems that the developer is not active on this project
anymore and is more active on PyPy
http://codespeak.net/pypy/dist/pypy/doc/
I've never really attempted to use JIT optimizers due to the fact that
all of my development and production environments are 64-bit, and I
haven't found one yet that supports 64-bit properly. Relying on dead
projects, however, is an issue of larger scope than mere portability.
;)
A program such as AVSP http://avisynth.org/qwerpoi/ which relies on
psyco what would be a good proposition to use when taking the project
to python 3.0 if psyco will remain unavailable?
I'd take the same approach Python 3 itself did; rewrite it for Python 3
and take the opportunity to remove excessive backwards compatibility
cruft, streamline algorithms, etc. With a suite of existing
unit/functional tests, that possibility is the ultimate in test-driven
development. ;) It would also follow the write clean code, then
profile and optimize where actually needed philosophy.
Obviously that recommendation won't be the "best" solution for every project.
With all of the FOSS projects I really, really care about I'm writing
from near-scratch (the code, if not the algorithms) with 2.6+ and 3.1+
polygot (no conversion tools like 2to3, and no split packaging)
compatibility as a primary design goal. So far it's working out quite
well.
- Alice
--
http://mail.python.org/mailman/listinfo/python-list
