6 ms·

> And think about how the 3.X changes totally screwed the Jython and PyPy (and Cython, and IronPython, and...) teams. We were headed towards much higher-perform

by sho_hn 14y ago

> And think about how the 3.X changes totally screwed the Jython and PyPy (and Cython, and IronPython, and...) teams. We were headed towards much higher-performance implementations of the language, with additional powerful features like sandboxing and JIT, and it was set back years by the 3.X schism. I don't see how the 3.x changes have set back PyPy "by years". PyPy was focussing exclusively on 2.x until very recently, and made its last big steps towards production-readyness entirely undisturbed by the 3.x transition. As of a couple of months ago they now have a small team working on 3.x support, which has made huge progress in a short time frame and doesn't seem to have detracted from progress in the core and further 2.x release at all as far as I can see. > Furthermore, the continued complication of the language makes it ever less likely that core problems like the GIL will ever be fixed. Ironically, specifically the oh-so-handicapped PyPy is currently working on a new approach to address the GIL with their transactional memory work. And the language has gotten less complicated with 3.x, not more. > I still hope against hope that there will be a Python 4 that brings backward compatibility and GIL removal. But since none of the overlords seem to care about either of these goals [...] Right, that's why 3.3 just added back support for u'' for increased backwards compat and ease of porting. You're making a lot claims that simply seem to have no basis in reality.

dmbaggett 14y ago
The reality is self-evident from the PyPy home page: "PyPy is a fast, compliant alternative implementation of the Python language (2.7.2)." Why not 3.3? Oh, right, because when the PyPy team started, Python 2.X was the Python language. Now it's not. This has been the case (PyPy has existed and supported 2.X code) since 3.0 was released. I.e., for years. As for PyPy STM, you trot that out like it's a real solution. It is not. It's 5 times slower and doesn't support Python 3.X. Which, of course, is the whole point. But, yes! Thank goodness I can type u'...' again! That will save me years of work! FAIL.
- sho_hn 14y ago
  > As for PyPy STM, you trot that out like it's a real solution. It is not. It's 5 times slower and doesn't support Python 3.X. This sort of comment doesn't really make me feel like you're qualified to comment on the subtleties of killing the GIL, to be honest. When it comes to removing the GIL, any form of "it's slower" is usually going to refer to single-threaded workloads, and avoiding to be slower for those is going to be nigh on impossible. The idea is that it's an investment to be recouped for various workloads due to the improved ability to exploit concurrency over a GIL-ful interpreter. And really, it's at the proof of concept stage right now, hardly optimized. And there's new CPU hardware with hardware support for transactional memory coming down the pipe.
  - masklinn 14y ago
    > The idea is that it's an investment to be recouped for various workloads due to the improved ability to exploit concurrency over a GIL-ful interpreter. This idea has been rejected by the core team though, getting rid of the gil with a major performance hit is not considered acceptable when most existing Python code is not significantly affected by the GIL.
    - sho_hn 14y ago
      Aye, which I think is reasonable, especially in the context of the GIL-removal approaches that were on the table at the time and the effort needed to implement them in CPython. I think the PyPy folks want to get to a place where you can run PyPy in modes tuned for either single-threaded or concurrent workloads.
  - dmbaggett 14y ago
    You are making excuses. It should require neither new hardware nor Herculean effort to realize acceptable multicore performance on CPU-bound tasks. And your badgering and down voting people here who disagree with you position doesn't make your argument any more persuasive.
    - sho_hn 14y ago
      Just to come to your aid and make your last sentence not a baseless accusation: Yes, I've been downvoting you. However, it's not because I'm disagreeing with your position, it's because I consider the way you conduct yourself in the debate, well, crappy, because: - First and foremost, your frequent use of ridicule and hyperbole is escalating the tone of the debate. - You prefer to move goal posts instead of addressing arguments (e.g. you still haven't actually gotten around to explaining how the 3.x transition has supposedly set back PyPy by years). - You're not beneath skewing things to fit your narrative, even if it doesn't really make any sense (e.g. pointing out that PyPy's STM tinkering doesn't yet support Python 3.x yet - yeah, duh, given that both are WIP branches that aren't merged into PyPy proper yet, and nevermind that the STM work doesn't really impact the same area of the codebase that adding Python 3.x support does, so there is no cause to anticipate problems with eventually integrating both). - You make bold claims and leave them unsubstantiated (e.g. "It should require neither new hardware nor Herculean effort to realize acceptable multicore performance on CPU-bound tasks." just now - if you've got it all figured out, where's your proposal to eliminate the GIL?). - Those bold claims even miss their mark in the context of the debate (I pointed out that "it's slower" refers to single-threaded workloads; when it comes to multicore performance the STM proof of concept is already showing some benefits). And so on and so on. Simply put, your posts are low quality, that's why I'm hitting that downward arrow.

by sho_hn 14y ago

dmbaggett 14y ago

The reality is self-evident from the PyPy home page: "PyPy is a fast, compliant alternative implementation of the Python language (2.7.2)." Why not 3.3? Oh, right, because when the PyPy team started, Python 2.X was the Python language. Now it's not. This has been the case (PyPy has existed and supported 2.X code) since 3.0 was released. I.e., for years. As for PyPy STM, you trot that out like it's a real solution. It is not. It's 5 times slower and doesn't support Python 3.X. Which, of course, is the whole point. But, yes! Thank goodness I can type u'...' again! That will save me years of work! FAIL.

sho_hn 14y ago
> As for PyPy STM, you trot that out like it's a real solution. It is not. It's 5 times slower and doesn't support Python 3.X. This sort of comment doesn't really make me feel like you're qualified to comment on the subtleties of killing the GIL, to be honest. When it comes to removing the GIL, any form of "it's slower" is usually going to refer to single-threaded workloads, and avoiding to be slower for those is going to be nigh on impossible. The idea is that it's an investment to be recouped for various workloads due to the improved ability to exploit concurrency over a GIL-ful interpreter. And really, it's at the proof of concept stage right now, hardly optimized. And there's new CPU hardware with hardware support for transactional memory coming down the pipe.
- masklinn 14y ago
  > The idea is that it's an investment to be recouped for various workloads due to the improved ability to exploit concurrency over a GIL-ful interpreter. This idea has been rejected by the core team though, getting rid of the gil with a major performance hit is not considered acceptable when most existing Python code is not significantly affected by the GIL.
  - sho_hn 14y ago
    Aye, which I think is reasonable, especially in the context of the GIL-removal approaches that were on the table at the time and the effort needed to implement them in CPython. I think the PyPy folks want to get to a place where you can run PyPy in modes tuned for either single-threaded or concurrent workloads.
- dmbaggett 14y ago
  You are making excuses. It should require neither new hardware nor Herculean effort to realize acceptable multicore performance on CPU-bound tasks. And your badgering and down voting people here who disagree with you position doesn't make your argument any more persuasive.
  - sho_hn 14y ago
    Just to come to your aid and make your last sentence not a baseless accusation: Yes, I've been downvoting you. However, it's not because I'm disagreeing with your position, it's because I consider the way you conduct yourself in the debate, well, crappy, because: - First and foremost, your frequent use of ridicule and hyperbole is escalating the tone of the debate. - You prefer to move goal posts instead of addressing arguments (e.g. you still haven't actually gotten around to explaining how the 3.x transition has supposedly set back PyPy by years). - You're not beneath skewing things to fit your narrative, even if it doesn't really make any sense (e.g. pointing out that PyPy's STM tinkering doesn't yet support Python 3.x yet - yeah, duh, given that both are WIP branches that aren't merged into PyPy proper yet, and nevermind that the STM work doesn't really impact the same area of the codebase that adding Python 3.x support does, so there is no cause to anticipate problems with eventually integrating both). - You make bold claims and leave them unsubstantiated (e.g. "It should require neither new hardware nor Herculean effort to realize acceptable multicore performance on CPU-bound tasks." just now - if you've got it all figured out, where's your proposal to eliminate the GIL?). - Those bold claims even miss their mark in the context of the debate (I pointed out that "it's slower" refers to single-threaded workloads; when it comes to multicore performance the STM proof of concept is already showing some benefits). And so on and so on. Simply put, your posts are low quality, that's why I'm hitting that downward arrow.