4 ms·

Unrelated: You do know that pypy also uses GIL. CFFI is to call C functions from Python. It won't allow you to run C extensions for CPython (something should

by d0mine 13y ago

Unrelated: You do know that pypy also uses GIL. CFFI is to call C functions from Python. It won't allow you to run C extensions for CPython (something should implement Python C API).

overgard 13y ago
I do know that; although they've done some interesting work with STM recently and hopefully that works out. I remember in the past hearing about someone actually submitting a patch to cpython remove the GIL about 10 years ago, but it was rejected because it made the language about 2-10x slower. IMO, that decision was INSANE. I have a 16 core machine right now and it can only really use 1/16th of it. Nobody uses python for it's speed, and people that need it are probably using C extension libraries like numpy, so if you were to cut the language's speed in half for a short term I'm going to say that pretty much nobody would care, especially if it were to solve a problem that everybody hates. Ruby is already about 10x slower than python on most of tasks, and it's just not a big deal. GVR is optimizing for the wrong thing.
- Freaky 13y ago
  > Ruby is already about 10x slower than python on most of tasks No it isn't - both are roughly in the same ballpark. Even before YARV it wasn't anywhere near an order of magnitude in the general case.
- dded 13y ago
  Not everyone's needs are the same. I'll not say that my concerns are better than anyone else's (of course), but they're certainly different than yours. If Python were 10x slower than it is, I'd use Perl. When I started using Python for real (2004), I'd have stuck with Perl if Python had been 2x slower. (Note that I very much dislike Perl, and thought of Python as a nicer Perl when I first learned it.) I care about speed, and I also care about convenience. Python has a very nice balance of the two for me. On the other hand, I only use threads in one script that I've ever written (and the GIL isn't a problem with it). So I just don't care about the GIL. (Edit: re-worded second paragraph)
- krakensden 13y ago
  Have you tried multiprocessing? My experience is that people seriously overestimate how expensive processes are, especially on Unixy operating systems.

by d0mine 13y ago

Unrelated: You do know that pypy also uses GIL. CFFI is to call C functions from Python. It won't allow you to run C extensions for CPython (something should implement Python C API).

overgard 13y ago

I do know that; although they've done some interesting work with STM recently and hopefully that works out. I remember in the past hearing about someone actually submitting a patch to cpython remove the GIL about 10 years ago, but it was rejected because it made the language about 2-10x slower. IMO, that decision was INSANE. I have a 16 core machine right now and it can only really use 1/16th of it. Nobody uses python for it's speed, and people that need it are probably using C extension libraries like numpy, so if you were to cut the language's speed in half for a short term I'm going to say that pretty much nobody would care, especially if it were to solve a problem that everybody hates. Ruby is already about 10x slower than python on most of tasks, and it's just not a big deal. GVR is optimizing for the wrong thing.

Freaky 13y ago
> Ruby is already about 10x slower than python on most of tasks No it isn't - both are roughly in the same ballpark. Even before YARV it wasn't anywhere near an order of magnitude in the general case.
dded 13y ago
Not everyone's needs are the same. I'll not say that my concerns are better than anyone else's (of course), but they're certainly different than yours. If Python were 10x slower than it is, I'd use Perl. When I started using Python for real (2004), I'd have stuck with Perl if Python had been 2x slower. (Note that I very much dislike Perl, and thought of Python as a nicer Perl when I first learned it.) I care about speed, and I also care about convenience. Python has a very nice balance of the two for me. On the other hand, I only use threads in one script that I've ever written (and the GIL isn't a problem with it). So I just don't care about the GIL. (Edit: re-worded second paragraph)
krakensden 13y ago
Have you tried multiprocessing? My experience is that people seriously overestimate how expensive processes are, especially on Unixy operating systems.