4 ms·

That's not an insurmountable problem. As long as all the data structures stay the same, all you really need to do is flush out all the non-GIL bytecode and loa

by phire 3y ago

That's not an insurmountable problem. As long as all the data structures stay the same, all you really need to do is flush out all the non-GIL bytecode and load in (or generate) GIL bytecode. Sure, there might be a stutter when this happens. You will also want a way to either start in GIL mode, or force it to stay in non-GIL mode, throwing errors. But it's a very solvable problem.

Karellen 3y ago
> all you really need to do is [SMOP]. But it's a very solvable problem. Awesome! I look forward to seeing your PR shortly. ;-)
- throwaway2037 3y ago
  I too enjoyed the parent comment. It's right up there with "as soon as we have sufficiently smart enough compilers, that won't be an issue anymore". I needed to Google SMOP, which tells me: "small matter of programming". Correct?
  - phire 3y ago
    I'm confused. Why do people think my suggested solution is difficult enough to be comparable to the halting problem or "a smart enough compiler"? We are talking about a scenario where cpython has already been modified to support both GIL and non-GIL operating modes, and a set of libraries that support the new non-GIL mode have been manually annotated by programmers. All I'm suggesting is that on top of this, we modify the "load library" code to detect at runtime when we are loading a library that doesn't support the new non-GIL mode and switch modes.
    - throwaway2037 3y ago
      This simplest solution is to get a patch accepted by Python team. Good luck with that.
  - Karellen 3y ago
    > I needed to Google SMOP, which tells me: "small matter of programming". Correct? Yes, it can mean either "small..." or "simple matter of programming", which is more the meaning I had in mind. But either fit.
gnulinux 3y ago
There is no programming language problem related to concurrency and C-level APIs that change the amount of code Python represents that is NOT insurmountable. This is like linux "we don't break userspace" motto. There is conceivably no possibility of removing GIL without breaking the userspace. Programs will be buggy, some will stop working. Worse, until someone works around the halting problem, we can't just crawl python code and decide if it uses GIL. People will have to be paid to inspect one function at a time to determine where GIL is needed.
- phire 3y ago
  Removing the GIL is easy. It's already been done with Jython and IronPython. No changes to python code is needed. You do still need locks for concurrency, it's just that instead of a corse-grained global lock, you replace it with a bunch of fine-grained locks. Which is actually one of the sticking points with the proposal to remove the GIL. All those fine-grained locks actually impact performance for a single-threadded python programs. The impossible problem is removing the GIL without breaking compatibility with the cpython API; There is a bunch of non-python code (mostly c/c++) that interfaces to python code with the cpython API and it's that code which breaks when you remove the GIL. The proposals floating around don't actually fix that issue, it's more of a "let's break API compatibility anyway", allowing libraries to be updated the new API incrementally. There are no issues with the halting problem here. It's really easy to detect at runtime if python code is interacting with c/c++ code via the old cpython API. Remember, the halting problem only applies to static analysis, not dynamic runtime checks.
  - gnulinux 3y ago
    This is extremely naive, and you answer your own question: > [Par 2] ["Removing GIL creates performance costs that people don't want"] > [Par 3] ["Removing GIL breaks CPython API which tons of codebases rely on and people will have to be paid to fix all that code"] In short, it's not possible to remove GIL without requiring code change. > There are no issues with the halting problem here. It's really easy to detect at runtime if python code is interacting with c/c++ code via the old cpython API. Remember, the halting problem only applies to static analysis, not dynamic runtime checks. This is not true and you're thinking of this wrong. When presented with a "will my code work after GIL removal" type of problem, the question becomes "will my code run C/C++ API". Whether it's detected at runtime is irrelevant because the question you want to answer is "does this piece of software require any change at all to work without GIL". To do that, you need a tool that statically analyzes whether known-bad functions (those that run C/C++ functions trivially/deterministically) are called from the rest of the codebase. Imagine you work for a company that has a package "xyz" written in C/C++ called in Python. Now that GIL is removed in an imaginary Python 4, my boss comes to me and asks "how much code needs to be changed for us to port to Python 4". Now, you can apply heuristics such as "how many modules import xyz". But since the correctness implications are co-infective, any module that doesn't import xyz but imports a module that import xyz will be affected as well. You can be more granular and verify whether individual functions use objects in xyz. Which brings me to my original point that there are two cases, either this is a static analysis problem (which we lack) or it's work someone has to crawl the entire codebase, inspect function by function, run unittest by unittest to determine if GIL removal breaks anything. I know because people did exactly this in 2 -> 3 change and it's an extraordinarily expensive ($$$) transition. Your view is naive beyond comprehension and it's hard to think of GIL removal as anything easier than the 2 -> 3 transition which was a shitshow of the magnitude software industry hasn't seen before.

by phire 3y ago

Karellen 3y ago

> all you really need to do is [SMOP]. But it's a very solvable problem. Awesome! I look forward to seeing your PR shortly. ;-)

throwaway2037 3y ago
I too enjoyed the parent comment. It's right up there with "as soon as we have sufficiently smart enough compilers, that won't be an issue anymore". I needed to Google SMOP, which tells me: "small matter of programming". Correct?
- phire 3y ago
  I'm confused. Why do people think my suggested solution is difficult enough to be comparable to the halting problem or "a smart enough compiler"? We are talking about a scenario where cpython has already been modified to support both GIL and non-GIL operating modes, and a set of libraries that support the new non-GIL mode have been manually annotated by programmers. All I'm suggesting is that on top of this, we modify the "load library" code to detect at runtime when we are loading a library that doesn't support the new non-GIL mode and switch modes.
  - throwaway2037 3y ago
    This simplest solution is to get a patch accepted by Python team. Good luck with that.
- Karellen 3y ago
  > I needed to Google SMOP, which tells me: "small matter of programming". Correct? Yes, it can mean either "small..." or "simple matter of programming", which is more the meaning I had in mind. But either fit.

gnulinux 3y ago

There is no programming language problem related to concurrency and C-level APIs that change the amount of code Python represents that is NOT insurmountable. This is like linux "we don't break userspace" motto. There is conceivably no possibility of removing GIL without breaking the userspace. Programs will be buggy, some will stop working. Worse, until someone works around the halting problem, we can't just crawl python code and decide if it uses GIL. People will have to be paid to inspect one function at a time to determine where GIL is needed.

phire 3y ago
Removing the GIL is easy. It's already been done with Jython and IronPython. No changes to python code is needed. You do still need locks for concurrency, it's just that instead of a corse-grained global lock, you replace it with a bunch of fine-grained locks. Which is actually one of the sticking points with the proposal to remove the GIL. All those fine-grained locks actually impact performance for a single-threadded python programs. The impossible problem is removing the GIL without breaking compatibility with the cpython API; There is a bunch of non-python code (mostly c/c++) that interfaces to python code with the cpython API and it's that code which breaks when you remove the GIL. The proposals floating around don't actually fix that issue, it's more of a "let's break API compatibility anyway", allowing libraries to be updated the new API incrementally. There are no issues with the halting problem here. It's really easy to detect at runtime if python code is interacting with c/c++ code via the old cpython API. Remember, the halting problem only applies to static analysis, not dynamic runtime checks.
- gnulinux 3y ago
  This is extremely naive, and you answer your own question: > [Par 2] ["Removing GIL creates performance costs that people don't want"] > [Par 3] ["Removing GIL breaks CPython API which tons of codebases rely on and people will have to be paid to fix all that code"] In short, it's not possible to remove GIL without requiring code change. > There are no issues with the halting problem here. It's really easy to detect at runtime if python code is interacting with c/c++ code via the old cpython API. Remember, the halting problem only applies to static analysis, not dynamic runtime checks. This is not true and you're thinking of this wrong. When presented with a "will my code work after GIL removal" type of problem, the question becomes "will my code run C/C++ API". Whether it's detected at runtime is irrelevant because the question you want to answer is "does this piece of software require any change at all to work without GIL". To do that, you need a tool that statically analyzes whether known-bad functions (those that run C/C++ functions trivially/deterministically) are called from the rest of the codebase. Imagine you work for a company that has a package "xyz" written in C/C++ called in Python. Now that GIL is removed in an imaginary Python 4, my boss comes to me and asks "how much code needs to be changed for us to port to Python 4". Now, you can apply heuristics such as "how many modules import xyz". But since the correctness implications are co-infective, any module that doesn't import xyz but imports a module that import xyz will be affected as well. You can be more granular and verify whether individual functions use objects in xyz. Which brings me to my original point that there are two cases, either this is a static analysis problem (which we lack) or it's work someone has to crawl the entire codebase, inspect function by function, run unittest by unittest to determine if GIL removal breaks anything. I know because people did exactly this in 2 -> 3 change and it's an extraordinarily expensive ($$$) transition. Your view is naive beyond comprehension and it's hard to think of GIL removal as anything easier than the 2 -> 3 transition which was a shitshow of the magnitude software industry hasn't seen before.