4 ms·

This is an interesting point. The existence of GIL may even indirectly speed up numerical Python code. Numpy and cython are significantly faster than N pure py

This is an interesting point. The existence of GIL may even indirectly speed up numerical Python code. Numpy and cython are significantly faster than N pure python threads, and the GIL encourages their development.

cdavid 13y ago
I would not go as far as saying the GIL speeds things up :) Everything else being equal, I would rather not have a GIL. I don't know any efficient runtime which uses reference counting and has no GIL, and integrating C with garbage collection is generally hard. That's one of the main reason why integrating C/etc.. with JNI or Matlab is a nightmare. The only one that managed to reduce the impedence mismatch and that I am aware of is Lua.
- falcolas 13y ago
  Given that early efforts to remove the GIL in cPython resulted in slower single-threaded execution, I would say that yes, the GIL does speed some things up.
  - coldtea 13y ago
    That's not really a valid argument, because it depends on how they went about it. And, from the speed and design of CPython, we know that they are not V8-level or JVM-level competent interpreter/VM writers.
    - falcolas 13y ago
      > That's not really a valid argument, because it depends on how they went about it. They went about it by adding mutexes around the reference counters (as opposed to using a separate mark & sweep GC, which has it's own downsides, as displayed by the JVM). This resulted in somewhat increased performance of multi-threaded applications, at the cost of single threaded applications. > And, from the speed and design of CPython, we know that they are not V8-level or JVM-level competent interpreter/VM writers. The biggest problem that V8/JVM (i.e. JIT) style interpreters have, when interpreting the Python language, is that JIT compilation is not really possible (or rather, exceptionally difficult). It's simply not possible to say that any given object in Python will remain it's currently defined type, or that an underlying method will not change meaning as execution continues. one + two can (and does) change it's meaning dynamically during the execution of a Python script, and simply optimizing away the __add__ lookups will bite you in the ass. PyPy is currently trying to come up with a JIT compiler, and they're having remarkably good success. Rather than ragging on Python, try supporting them instead.
      - coldtea 13y ago
        >The biggest problem that V8/JVM (i.e. JIT) style interpreters have, when interpreting the Python language, is that JIT compilation is not really possible (or rather, exceptionally difficult). It's simply not possible to say that any given object in Python will remain it's currently defined type, or that an underlying method will not change meaning as execution continues. The same thing holds for JS. And yet, they have tons of heuristics to counter it. Not to mention that most objects really don't change anyway. >one + two can (and does) change it's meaning dynamically during the execution of a Python script, and simply optimizing away the __add__ lookups will bite you in the ass. That's not the case for over 90% of the code I've seen in Python. Even if it DOES use operator overloading.
  - cdavid 13y ago
    Removing the GIL is a different problem than designing python without a GIL from the start. Preserving C API semantics (in particular reference counting) without slowing things down is the tricky part. I could be wrong, but I am not aware of any efficient memory management that support multithread well without depending on a 'real' GC
- enupten 13y ago
  Does anybody know how good Common Lisp (one of SBCL, Allegro, Lispworks, CCL) is with multithreading whilst calling the FFI ?

cdavid 13y ago

I would not go as far as saying the GIL speeds things up :) Everything else being equal, I would rather not have a GIL. I don't know any efficient runtime which uses reference counting and has no GIL, and integrating C with garbage collection is generally hard. That's one of the main reason why integrating C/etc.. with JNI or Matlab is a nightmare. The only one that managed to reduce the impedence mismatch and that I am aware of is Lua.

falcolas 13y ago
Given that early efforts to remove the GIL in cPython resulted in slower single-threaded execution, I would say that yes, the GIL does speed some things up.
- coldtea 13y ago
  That's not really a valid argument, because it depends on how they went about it. And, from the speed and design of CPython, we know that they are not V8-level or JVM-level competent interpreter/VM writers.
  - falcolas 13y ago
    > That's not really a valid argument, because it depends on how they went about it. They went about it by adding mutexes around the reference counters (as opposed to using a separate mark & sweep GC, which has it's own downsides, as displayed by the JVM). This resulted in somewhat increased performance of multi-threaded applications, at the cost of single threaded applications. > And, from the speed and design of CPython, we know that they are not V8-level or JVM-level competent interpreter/VM writers. The biggest problem that V8/JVM (i.e. JIT) style interpreters have, when interpreting the Python language, is that JIT compilation is not really possible (or rather, exceptionally difficult). It's simply not possible to say that any given object in Python will remain it's currently defined type, or that an underlying method will not change meaning as execution continues. one + two can (and does) change it's meaning dynamically during the execution of a Python script, and simply optimizing away the __add__ lookups will bite you in the ass. PyPy is currently trying to come up with a JIT compiler, and they're having remarkably good success. Rather than ragging on Python, try supporting them instead.
    - coldtea 13y ago
      >The biggest problem that V8/JVM (i.e. JIT) style interpreters have, when interpreting the Python language, is that JIT compilation is not really possible (or rather, exceptionally difficult). It's simply not possible to say that any given object in Python will remain it's currently defined type, or that an underlying method will not change meaning as execution continues. The same thing holds for JS. And yet, they have tons of heuristics to counter it. Not to mention that most objects really don't change anyway. >one + two can (and does) change it's meaning dynamically during the execution of a Python script, and simply optimizing away the __add__ lookups will bite you in the ass. That's not the case for over 90% of the code I've seen in Python. Even if it DOES use operator overloading.
- cdavid 13y ago
  Removing the GIL is a different problem than designing python without a GIL from the start. Preserving C API semantics (in particular reference counting) without slowing things down is the tricky part. I could be wrong, but I am not aware of any efficient memory management that support multithread well without depending on a 'real' GC
enupten 13y ago
Does anybody know how good Common Lisp (one of SBCL, Allegro, Lispworks, CCL) is with multithreading whilst calling the FFI ?