31–40 of 105 posts
Why was PyPy abandoned and not embraced by Python? NIH?
I assume you might mean to ask "why wasn't PyPy adopted in some formal way into CPython" rather than a separate project, for which the answer is at least partially likely to be because it's a completely separate implementation.
Development hasn't been paused (with negative implications).
It's now considered significant enough that they've requested feature freeze in CPython main until governance/process questions are settled.
Earlier quoted context omitted.
Sure but best case 15% faster clearly isn't worth the complexity of a JIT. It really needs to be at least twice as fast. Pypy pretty much achieves that on average.
15% faster on top of a base interpreter that itself got 40%-50% faster on the same timeframe.
Of course the counterargument is that they'll improve it and maybe in future it will be 100% faster... But that seems pretty dubious given the progress so far.
>> While the intent is not to call for competing proposals, we believe that now is a good time to discuss and propose alternative proposals as well. lol >> For example, rather than proposing one single concrete JIT implementation, it may make more sense for the PEP to describe a JIT infrastructure that can support multiple implementation strategies. poison-pill requirement >> We are setting a window of six months for…
Duplicate of here: https://news.ycombinator.com/item?id=48421400
Don't bother clicking, that post got 0 attention. Not helpful, mate.
At the time I posted it, both were pretty lacking in attention, so it made sense to direct to the earlier of the two.
Editorialised title. Development hasn't been paused (with negative implications). It's now considered significant enough that they've requested feature freeze in CPython main until governance/process questions are settled.
Sounds reasonable given the recent YOLO GC debacle https://discuss.python.org/t/reverting-the-incremental-gc-in... .
Earlier quoted context omitted.
>The experimental JIT was reported to finally breaking even and surpassing the default interpreter just a couple of months ago[1]. Thank You. As someone who don't follow python closely I thought their JIT would be similar to what Ruby has. Not that Ruby YJIT or ZJIT is anywhere close to what JVM provides, but in this case it seems to be quite far ahead of Python. Which is surprising given how many major companies are…
Python software is to a large extent either doing things in not-python (c, c++, rust, etc.) or doing things that are not cpu bound (io bound, async, etc.). If you're cpu bound then you can either take a 2x jit improvement or take a 10x non-python improvement. There's few companies of a scale where the non-hot path cost of 2x cpu is so massive as to be worth caring about.
Earlier quoted context omitted.
>The experimental JIT was reported to finally breaking even and surpassing the default interpreter just a couple of months ago[1]. Thank You. As someone who don't follow python closely I thought their JIT would be similar to what Ruby has. Not that Ruby YJIT or ZJIT is anywhere close to what JVM provides, but in this case it seems to be quite far ahead of Python. Which is surprising given how many major companies are…
Python software is to a large extent either doing things in not-python (c, c++, rust, etc.) or doing things that are not cpu bound (io bound, async, etc.). If you're cpu bound then you can either take a 2x jit improvement or take a 10x non-python improvement. There's few companies of a scale where the non-hot path cost of 2x cpu is so massive as to be worth caring about.
That was kind of overdue. The project started five years ago while massively overpromising. They should perhaps have kept it in a separate branch back then, but now is the next best time. CPython's selling point was that it is simple, fast enough with C extensions and the code was accessible. Complicating the code base for occasional 50% speedups (and regressions ...) just isn't worth it. There are so many other lang…