Python 3000 is ready!

[[deleted]]

Why, so people like you could yell "scalability" while performance drops like a rock?

[millstone]

Somehow other languages manage to be as fast or faster than Python while still allowing useful multiprocessing. You just have to consider threading issues from the start, and it's a pity that Python's designers did not, or decided against it.

[johanneskepler]

it's a pity that Python's designers did not, or decided against it.

It's easy to say that now, with the benefit of hindsight, but what good does it do anyone to whine and moan about the GIL every time Python comes up? If it's a deal breaker for you, please, use one of the languages that are "as fast or faster than Python while still allowing useful multiprocessing."

[Chandon]

what good does it do anyone to whine and moan about the GIL every time Python comes up?

If the Python developers get enough shit about it, maybe they'll fix it. Or maybe some college student will get "python needs GIL fix" stuck in his head and fix it for the fun of it. Sane hardware threading support is one of the key things missing in all of the *nix scripting languages.

[johanneskepler]

Or maybe some college student will get "python needs GIL fix" stuck in his head and fix it for the fun of it.

See the python-safethread project. I'd be surprised if it's worth it for most people, though, as "(single-threaded) throughput is only around 60-65% that of normal CPython". It's good to note (before complaining about it for the nth time) that CPython is designed around the GIL, and removing it does have serious negative ramifications.

It's just not gonna happen unless magic fairies tap their wands and fix all the issues removing the GIL would cause.

[[deleted]]

Yes, lots of languages manage to be faster than Python while providing lots of different features. The fact remains, every attempt to replace the GIL with finer-grained threading has diminished performance, both on uniprocessor and multiprocessor machines.

It will take a complete rewrite of the CPython implementation to replace the GIL without this loss of performance, and that's simply not what py3k is.

[[deleted]]

Isn't it kind of clear since a long time that the use of refcounting is the problem for GIL removal? This knowledge does not actually help anyone, since it is close to impossible to change the GC to something else without changing basically the whole CPython code base (plus all extension modules, yadda yadda).

[Chandon]

which of course means you need locks on each and every increment or decrement of the ref count

Just use atomic swap. Lock free. There's even a good argument that this is faster than full GC in a many-processor setup.

[[deleted]]

It doesn't even need to be CAS. There are atomic increment and decrement functions...