Using python as primary language

[Hrvoje Niksic]

"Martin Vilcans" <martin at librador.com> 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