Will Python 3.0 remove the global interpreter lock (GIL)

[Paul Rubin]

TheFlyingDutchman <zzbbaadd at aol.com> writes:
> The very fastest Intel processor of the last 1990's that I found came
> out in October 1999 and had a speed around 783Mhz. Current fastest
> processors are something like 3.74 Ghz, with larger caches. Memory is
> also faster and larger. It appears that someone running a non-GIL
> implementation of CPython today would have significantly faster
> performance than a GIL CPython implementation of the late 1990's.
> Correct me if I am wrong, but it seems that saying non-GIL CPython is
> too slow, while once valid, has become invalid due to the increase in
> computing power that has taken place.

This reasoning is invalid.  For one thing, disk and memory sizes and
network bandwith have increased by a much larger factor than CPU speed
since the late 1990's.  A big disk drive in 1999 was maybe 20gb; today
it's 750gb, almost 40x larger, way outstripping the 5x cpu mhz
increase.  A fast business network connection was a 1.4 mbit/sec T-1
line, today it's often 100 mbit or more, again far oustripping CPU
mhz.  If Python was just fast enough to firewall your T1 net
connection or index your 20gb hard drive in 1999, it's way too slow to
do the same with today's net connections and hard drives, just because
of that change in the hardware landscape.  We have just about stopped
seeing increases in cpu mhz: that 3.74ghz speed was probably reached a
couple years ago.  We get cpu speed increases now through parallelism,
not mhz.  Intel and AMD both have 4-core cpu's now and Intel has a
16-core chip coming.  Python is at a serious disadvantage compared
with other languages if the other languages keep up with developments
and Python does not.

Also, Python in the late 90's was pitched as a "scripting language",
intended for small throwaway tasks, while today it's used for complex
applications, and the language has evolved accordingly.  CPython is
way behind the times, not only from the GIL, but because its slow
bytecode interpreter, its non-compacting GC, etc.  The platitude that
performance doesn't matter, that programmer time is more valuable than
machine time, etc. is at best an excuse for laziness.  And more and
more often, in the application areas where Python is deployed, it's
just plain wrong.  Take web servers: a big site like Google has
something like a half million of them.  Even the comparatively wimpy
site where I work has a couple thousand.  If each server uses 150
watts of power (plus air conditioning), then if making the software 2x
faster lets us shut down 1000 of them, the savings in electricity
bills alone is larger than my salary.  Of course that doesn't include
environmental benefits, hardware and hosting costs, the costs and
headaches of administering that many boxes, etc.  For a lot of Python
users, significant speedups are a huge win.

However, I don't think fixing CPython (through GIL removal or anything
else) is the answer, and Jython isn't the answer either.  Python's
future is in PyPy, or should be.  Why would a self-respecting Python
implementation be written in (yikes) C or (yucch) Java, if it can be
written in Python?  So I hope that PyPy's future directions include
true parallelism.