4 ms·

In my experience, CPython is 100 to 1000 times slower than C (or C++, Rust, Fortran, etc...). CPython would be better off fixing the speed (perhaps by embracin

In my experience, CPython is 100 to 1000 times slower than C (or C++, Rust, Fortran, etc...). CPython would be better off fixing the speed (perhaps by embracing PyPy) and staying single threaded than removing the GIL. At least if you're choosing threads for performance gains. Think of it this way: A single threaded C++ or Rust program can do more work per second than a hypothetical GIL-free CPython with 64 cores...

viraptor 8y ago
> CPython is 100 to 1000 times slower than C That's very context dependant. With annotations, typical calculations compile to C code roughly equivalent to native. The more of the actual runtime you use, the more you call into cpython which can't be sped up this way. Cython compiled code will be somewhere between C and cpython in terms of speed, but putting a single number to it will be always misleading.
- weberc2 8y ago
  >> CPython is 100 to 1000 times slower than C > That's very context dependant. With annotations, typical calculations compile to C code roughly equivalent to native. The more of the actual runtime you use, the more you call into cpython which can't be sped up this way. Cython compiled code will be somewhere between C and cpython in terms of speed, but putting a single number to it will be always misleading. OP said "CPython", not "Cython". CPython is pretty reliably 100X to 1000X slower than C.
  - viraptor 8y ago
    Oops, you're right. One day I'll learn to read :-)
    - weberc2 8y ago
      No worries. I suspect many of your downvoters were confused as I was that you appeared to be arguing that CPython could compile your Python code to efficient C! Took me a few passes to spot the misunderstanding.
Stubb 8y ago
I'm using compiled libraries for all my heavy lifting—the Python code is there to glue those libraries together in convenient manner that allows for exploratory programming. GIL-free CPython would let me distribute computations across multiple cores without having to deal with the overhead of multiprocessing (serializing objects across process boundaries, etc.).
- civility 8y ago
  If your compiled code is thread safe, you can releae the GIL in your library and achieve parallelism with current CPython. If your compiled libraries are not thread safe, you can't get parallelism anyway. Maybe, if your heavy lifting functions are very short lived, releasing and acquiring the GIL is holding you back... Btw, I'm not defending the GIL. Python has enough visibility and significance to deserve a good implementation. It's just that most people don't realize the slowness of CPython itself is a bigger impediment to performance than the GIL. Python should be in the same speed league as JavaScript, but there are too many things hindering progress.

viraptor 8y ago

> CPython is 100 to 1000 times slower than C That's very context dependant. With annotations, typical calculations compile to C code roughly equivalent to native. The more of the actual runtime you use, the more you call into cpython which can't be sped up this way. Cython compiled code will be somewhere between C and cpython in terms of speed, but putting a single number to it will be always misleading.

weberc2 8y ago
>> CPython is 100 to 1000 times slower than C > That's very context dependant. With annotations, typical calculations compile to C code roughly equivalent to native. The more of the actual runtime you use, the more you call into cpython which can't be sped up this way. Cython compiled code will be somewhere between C and cpython in terms of speed, but putting a single number to it will be always misleading. OP said "CPython", not "Cython". CPython is pretty reliably 100X to 1000X slower than C.
- viraptor 8y ago
  Oops, you're right. One day I'll learn to read :-)
  - weberc2 8y ago
    No worries. I suspect many of your downvoters were confused as I was that you appeared to be arguing that CPython could compile your Python code to efficient C! Took me a few passes to spot the misunderstanding.

Stubb 8y ago

I'm using compiled libraries for all my heavy lifting—the Python code is there to glue those libraries together in convenient manner that allows for exploratory programming. GIL-free CPython would let me distribute computations across multiple cores without having to deal with the overhead of multiprocessing (serializing objects across process boundaries, etc.).

civility 8y ago
If your compiled code is thread safe, you can releae the GIL in your library and achieve parallelism with current CPython. If your compiled libraries are not thread safe, you can't get parallelism anyway. Maybe, if your heavy lifting functions are very short lived, releasing and acquiring the GIL is holding you back... Btw, I'm not defending the GIL. Python has enough visibility and significance to deserve a good implementation. It's just that most people don't realize the slowness of CPython itself is a bigger impediment to performance than the GIL. Python should be in the same speed league as JavaScript, but there are too many things hindering progress.