"Martin Vilcans" <[EMAIL PROTECTED]> writes: > But if Python gets slow when you add fine-grained locks, then most > certainly it wouldn't get so slow if the locks were very fast, > right?
Given the sheer number of increfs and decrefs happening, they should be impossibly fast (meaning: nonexistent). Even adding an additional test to those macros slows down Python, let alone adding a lock. > But that's not what my question was about. It was about whether it > would make sense to, on the same python installation, select between > the GIL and fine-grained locks at startup. Because even if the locks > slows down the interpreter, if they let you utilize a 32 core CPU, > it may not be so bad anymore. Unfortunately the selection must be done at compile time, not at run-time. Even taking into account the possibility of selection, so far no one has come up with a set of patches that remove the GIL that would come close to being accepted. This is a recent discussion about GIL removal that provides good reading: http://mail.python.org/pipermail/python-dev/2007-September/thread.html#74545 -- http://mail.python.org/mailman/listinfo/python-list
