5 ms·

People who want to see backwards-incompatible changes, e.g. GIL removal, language & stdlib cleanups, or even mandatory static typing?

by pansa2 5y ago

d3ckard 5y ago
Why GIL removal would be necessarily breaking?
- m_mueller 5y ago
  I imagine it would likely introduce subtle behavior changes in how concurrency works.
  - rurban 5y ago
    Not behavior, but struct layouts. Since python (as well as most other such scripting toys) never thought about proper enhancement paths, their API works by exposing headers with the structs, and not many abstract types with functional interfaces, you cannot change much. With functions only it would have been easy
- pansa2 5y ago
  The only way to remove the GIL without breaking existing multithreaded code is to replace it with multiple smaller locks. That approach is considered unacceptable because the small locks introduce substantial overhead.
  - needusername 5y ago
    Why? Java has no GIL and runs faster than Python.
    - chrisseaton 5y ago
      Java has different semantics to Python. To make Python run fast without a GIL you'd have to change the semantics to be more like Java's, which would be a breaking change, which would mean Python 4.0, which is what they say we're unlikely to get.
      - dekhn 5y ago
        IronPython, based on CLR and .NET, was faster than Python and didn't have a GIL.
        deleted 5y ago
        [deleted]
        pansa2 5y ago
        IIRC it included a JIT compiler, which was fast enough to offset the overhead of fine-granularity locking.
        zerkten 5y ago
        You have to consider the use case in addition to the technology. The relatively simple implementation of CPython ensures you have fast startup, but trade-off other optimizations which affect long-running programs. Lots of Python scripts only run for a short time. Code in the REPL needs to return results really quickly. The .NET JIT added significant startup costs to the point where the IronPython team had to add an interpreted mode for first runs before handing off the JIT. This is complex and arguably takes time away from CPython compatibility work. It seems that the .NET team is coming around to the concerns around startup time, but I don't know if they have landed on an AOT solution. It probably will help executables running on .NET Core more than scripts running under IronPython. I've not kept up with JITs very much, but I don't think this pattern is limited to the .NET JIT, and is a general trade-off. I feel like JavaScript JITs may be closer to what IronPython would have wanted though.
        dagw 5y ago
        IronPython also wasn't compatible with any python library that used the C API. Essentially we're back to the point that removing the GIL is 'easy' as long as you don't care about backwards compatibility.
        dekhn 5y ago
        in many ways ironpython obviated the C API. It had a different approach to extension, based on CLR and .NET. Even the containers used .NET data types.
    - pansa2 5y ago
      AFAIK multithreaded Java code requires the user to explicitly acquire a lock before accessing a shared data structure. Multithreaded Python currently does not, and must remain that way to maintain compatibility.
      - needusername 5y ago
        > Multithreaded Python currently does not How do you prevent interleaving of different threads then? > and must remain that way to maintain compatibility. Why? Python 3 broke a whole lot of applications and libraries.
        pansa2 5y ago
        > How do you prevent interleaving of different threads then? The GIL. > Why? Python 3 broke a whole lot of applications and libraries. Sorry, I mean it must remain that way if it is to maintain compatibility. We’re assuming that breaking compatibility is unacceptable.
        needusername 5y ago
        > The GIL. How does the the GIL prevent interleaving? My understanding is that if an "operation" takes several steps, eg. reading from a dict then IO or a C extension and finally writing to a dict the GIL will not make this atomic.
        formerly_proven 5y ago
        Most Python 3 breakage was search-replace fixable (though I'd question the value of language changes falling in this category), although it is true that the text/bytes separation exposed unsound data models in some applications, which is of course nasty to deal with.
        needusername 5y ago
        Why did it take projects and Google so long to migrate?
- formerly_proven 5y ago
  The GIL is baked into the C API. There's the performance argument as well, though that doesn't seem as fundamental to me (i.e. a sufficiently smart team of engineers might find a way around that).
IgorPartola 5y ago
So people want Nim?
- pansa2 5y ago
  Is Nim particularly similar to Python? More than Go, which Guido recently described as being the new language that’s most Pythonic? https://www.youtube.com/watch?v=aYbNh3NS7jA&t=1472s https://www.youtube.com/watch?v=aYbNh3NS7jA&t=1472s
  - IgorPartola 5y ago
    Nim uses Python-like syntax but is statically typed. It explicitly lists Python as one of its main inspirations.
  - nimmer 5y ago
    Compared to Go it really feels way closer to Python.
monkeybutton 5y ago
I just want to be able to deploy a flask app that responds to a lot of CPU-intensive requests (making inference from ML models) that takes advantage of modern CPUs that have a stupid number of cores, without having to pay the memory overhead of duplicating the entire process' memory space N-times. Native threads would totally fix this inefficiency but the GIL breaks it. Java and .Net would be more appropriate in this production environment but they don't have the same eco-system of packages and we also don't want to pay the development cost of re-writing people's notebooks into another language and all the problems that entails. So instead, our server VMs consume a ton of unnecessary memory. /rant
- d0mine 5y ago
  Is the interpreter own memory size a real concern in ML application?
- andrepd 5y ago
  Then consider writing your application in something other than a scripting language. If you're too “lazy” to write in a lower-level language don't complain when you're application is several times slower and takes several times more memory than it could.

People who want to see backwards-incompatible changes, e.g. GIL removal, language & stdlib cleanups, or even mandatory static typing?

by pansa2 5y ago

People who want to see backwards-incompatible changes, e.g. GIL removal, language & stdlib cleanups, or even mandatory static typing?

d3ckard 5y ago

Why GIL removal would be necessarily breaking?

m_mueller 5y ago
I imagine it would likely introduce subtle behavior changes in how concurrency works.
- rurban 5y ago
  Not behavior, but struct layouts. Since python (as well as most other such scripting toys) never thought about proper enhancement paths, their API works by exposing headers with the structs, and not many abstract types with functional interfaces, you cannot change much. With functions only it would have been easy
pansa2 5y ago
The only way to remove the GIL without breaking existing multithreaded code is to replace it with multiple smaller locks. That approach is considered unacceptable because the small locks introduce substantial overhead.
- needusername 5y ago
  Why? Java has no GIL and runs faster than Python.
  - chrisseaton 5y ago
    Java has different semantics to Python. To make Python run fast without a GIL you'd have to change the semantics to be more like Java's, which would be a breaking change, which would mean Python 4.0, which is what they say we're unlikely to get.
    - dekhn 5y ago
      IronPython, based on CLR and .NET, was faster than Python and didn't have a GIL.
      - deleted 5y ago
        [deleted]
      - pansa2 5y ago
        IIRC it included a JIT compiler, which was fast enough to offset the overhead of fine-granularity locking.
        zerkten 5y ago
        You have to consider the use case in addition to the technology. The relatively simple implementation of CPython ensures you have fast startup, but trade-off other optimizations which affect long-running programs. Lots of Python scripts only run for a short time. Code in the REPL needs to return results really quickly. The .NET JIT added significant startup costs to the point where the IronPython team had to add an interpreted mode for first runs before handing off the JIT. This is complex and arguably takes time away from CPython compatibility work. It seems that the .NET team is coming around to the concerns around startup time, but I don't know if they have landed on an AOT solution. It probably will help executables running on .NET Core more than scripts running under IronPython. I've not kept up with JITs very much, but I don't think this pattern is limited to the .NET JIT, and is a general trade-off. I feel like JavaScript JITs may be closer to what IronPython would have wanted though.
      - dagw 5y ago
        IronPython also wasn't compatible with any python library that used the C API. Essentially we're back to the point that removing the GIL is 'easy' as long as you don't care about backwards compatibility.
        dekhn 5y ago
        in many ways ironpython obviated the C API. It had a different approach to extension, based on CLR and .NET. Even the containers used .NET data types.
  - pansa2 5y ago
    AFAIK multithreaded Java code requires the user to explicitly acquire a lock before accessing a shared data structure. Multithreaded Python currently does not, and must remain that way to maintain compatibility.
    - needusername 5y ago
      > Multithreaded Python currently does not How do you prevent interleaving of different threads then? > and must remain that way to maintain compatibility. Why? Python 3 broke a whole lot of applications and libraries.
      - pansa2 5y ago
        > How do you prevent interleaving of different threads then? The GIL. > Why? Python 3 broke a whole lot of applications and libraries. Sorry, I mean it must remain that way if it is to maintain compatibility. We’re assuming that breaking compatibility is unacceptable.
        needusername 5y ago
        > The GIL. How does the the GIL prevent interleaving? My understanding is that if an "operation" takes several steps, eg. reading from a dict then IO or a C extension and finally writing to a dict the GIL will not make this atomic.
        formerly_proven 5y ago
        Most Python 3 breakage was search-replace fixable (though I'd question the value of language changes falling in this category), although it is true that the text/bytes separation exposed unsound data models in some applications, which is of course nasty to deal with.
        needusername 5y ago
        Why did it take projects and Google so long to migrate?
formerly_proven 5y ago
The GIL is baked into the C API. There's the performance argument as well, though that doesn't seem as fundamental to me (i.e. a sufficiently smart team of engineers might find a way around that).

IgorPartola 5y ago

So people want Nim?

pansa2 5y ago
Is Nim particularly similar to Python? More than Go, which Guido recently described as being the new language that’s most Pythonic? https://www.youtube.com/watch?v=aYbNh3NS7jA&t=1472s https://www.youtube.com/watch?v=aYbNh3NS7jA&t=1472s
- IgorPartola 5y ago
  Nim uses Python-like syntax but is statically typed. It explicitly lists Python as one of its main inspirations.
- nimmer 5y ago
  Compared to Go it really feels way closer to Python.

monkeybutton 5y ago

I just want to be able to deploy a flask app that responds to a lot of CPU-intensive requests (making inference from ML models) that takes advantage of modern CPUs that have a stupid number of cores, without having to pay the memory overhead of duplicating the entire process' memory space N-times. Native threads would totally fix this inefficiency but the GIL breaks it. Java and .Net would be more appropriate in this production environment but they don't have the same eco-system of packages and we also don't want to pay the development cost of re-writing people's notebooks into another language and all the problems that entails. So instead, our server VMs consume a ton of unnecessary memory. /rant

d0mine 5y ago
Is the interpreter own memory size a real concern in ML application?
andrepd 5y ago
Then consider writing your application in something other than a scripting language. If you're too “lazy” to write in a lower-level language don't complain when you're application is several times slower and takes several times more memory than it could.