Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Pyston v2: Faster Python

blog.pyston.org

Post reply on HN
Print view View original

41–50 of 211 posts

Re: Pyston v2: Faster Python

#41

Post by JoeAltmaier »

SoSoRoCoCo wrote: post #39

Ugh. At some point we need to stop using side-forks/-projects like this because then they become competing standards that pull resources away from the main projects and evolve into their own incompatible beasts. I hope they instead contribute to the main branch, instead of wandering off into NIH land.

An issue. But isn't that forking fundamental to the principle of Open Source? The market will choose what it wants, like some Genetic Algorithm where the fittest thrives and the rest go extinct. Else how does a project evolve at all?

Re: Pyston v2: Faster Python

#42

Post by WesolyKubeczek »

SoSoRoCoCo wrote: post #39

Ugh. At some point we need to stop using side-forks/-projects like this because then they become competing standards that pull resources away from the main projects and evolve into their own incompatible beasts. I hope they instead contribute to the main branch, instead of wandering off into NIH land.

Disagree. Currently, many people have "Python" projects which only CPython can run, for some reason or other. Having a lot of competing interpreters/compilers helps define what the core of the language actually is, and which of your assumptions are hinged on that single implementation.

Re: Pyston v2: Faster Python

#43

Post by Foober223 »

sjansen wrote: post #35
beervirus wrote: post #19

20% isn't nothing... but is it really worth switching to a non-standard, closed-source version of the interpreter?

Depends on your scale. If each of your web servers has a hand picked name, definitely not. But if you stopped naming servers a long time ago, and if the pricing structure is favorable, it could mean a huge cost saving without an expensive rewrite.

Electricity costs can far outweigh developer salaries.

In some cases a rewrite may save more money than moving to a 20% faster python.

Re: Pyston v2: Faster Python

#44

Post by sk2020 »

throwaway894345 wrote: post #29
rrdharan wrote: post #17

Earlier quoted context omitted.

Python is a welcoming community, but they are decidedly not welcoming of contributions that significantly increase the complexity of the CPython reference implementation. This has been discussed extensively: https://news.ycombinator.com/item?id=11125769

This is why I see little hope for Python, which is to say that while I'm sure it will continue to have a large following for many years a la C, C++, etc, I don't have hope for it being an exciting language or one that is particularly productive. Python already has performance and packaging problems which don't seem to be easily divorced from CPython, since virtually the whole reference implementation is depended upon…

Scipy has a poor performance ceiling? Numpy has a poor API? Compared to what? Eigen? Whatever the Scala guys use? That sounds kind of silly to me, especially when hardly anyone is actually CPU-bound, anyway.

Re: Pyston v2: Faster Python

#45

Post by hhas01 »

qorrect wrote: post #6
pwinnski wrote: post #3

I feel like anybody really searching for speed is using something other than Python. I don't use Python for speed, but for ease-of-use. It took me some clicks to see it's supposed to be a drop-in replacement, so that's good.

I use python because of Numpy, Scikit and Tensorflow. I don't know of any other languages with libraries as productive as these, so speeding these apps up is a big win for a lot of people. Also 20% is huge, I look forward to trying it!

20% faster is nothing. You want at least a magnitude faster to justify the cost and risk of switching.

The Python language is already 30 years old, and it wasn’t even the cutting-edge in imperative language design (Smalltalk, Lisp) back then. It’s positively antiquated now.

I’ve never understood this tunnel-vision obsession with endlessly chasing ever-diminishing returns. It’s Zawinski's Law of Software by way of Greenspun’s Tenth Rule, and a fundamental failure of courage.

Learn the lessons from both the good and bad of what’s been done before, and move on. A better long-term answer would be to design a much faster, more efficient language for running Numpy, Scikit, and Tensorflow, then port those libraries over to that. If that language turns out to be good for other things too, then great. If not, let a thousand flowers bloom.

There is a much larger learning opportunity here, to get a whole lot better at migrating extant code bases from an old, popular, dead-ended language to a new, upcoming one. But it’s like finding your way to Carnegie Hall: it takes practise, practise, practise.

Re: Pyston v2: Faster Python

#46

Post by uranusjr »

saurik wrote: post #38
throwaway894345 wrote: post #29

Earlier quoted context omitted.

This is why I see little hope for Python, which is to say that while I'm sure it will continue to have a large following for many years a la C, C++, etc, I don't have hope for it being an exciting language or one that is particularly productive. Python already has performance and packaging problems which don't seem to be easily divorced from CPython, since virtually the whole reference implementation is depended upon…

100% agree. To a very real extent, Go probably only exists at all because Google poured an infinite amount of effort into Unladen Swallow--a project designed to remove the GIL from Python 2 to make it more usable for concurrent programs and add an LLVM-based JIT compiler to improve performance--and Python's response was to not only not merge it, but to break the entire Python ecosystem for a decade by forking the lan…

Didn’t the original Go creators mention on multiple occasions they intended to build a replacement to C, only accidentally produced an application language? Assuming that’s true, Go would have happened regardless. Google couldn’t have pulled out of Unladen Swallow before Go is usable, since they could not have known it’s actually an alternative at the time.

Re: Pyston v2: Faster Python

#47

Post by orf »

rrdharan wrote: post #17
dwheeler wrote: post #13

Earlier quoted context omitted.

As far as I know CPython is quite welcoming. However, per the blog post, this version of Pyston is closed source. So CPython won't be interested, and many others won't be interested either.

Python is a welcoming community, but they are decidedly not welcoming of contributions that significantly increase the complexity of the CPython reference implementation. This has been discussed extensively: https://news.ycombinator.com/item?id=11125769

I might have to eat those old words as there is some form of runtime code specialisation being considered for inclusion in CPython. It doesn’t sound like a fully-fledged JIT, but that might be a distinction without a difference.

Re: Pyston v2: Faster Python

#48

Post by rudi-c »

SoSoRoCoCo wrote: post #39

Ugh. At some point we need to stop using side-forks/-projects like this because then they become competing standards that pull resources away from the main projects and evolve into their own incompatible beasts. I hope they instead contribute to the main branch, instead of wandering off into NIH land.

That's not how progress happens in practice. First of all, it's not a known fact that a Python JIT implementation with reasonable maintenance cost, functionality, and performance can exist. Pyston is trying to prove that it is possible, but it's not exactly a weekend project.

Even if you solved all the political issues around getting CPython maintainers to accept performance contributions (discussed already in this thread), adding a JIT to the main CPython codebase would surely slow the pace of development of other Python features. If the effort were to fail, then CPython's primary maintainers will have wasted a whole bunch of time coordinating with the JIT effort. I'm personally rooting for Pyston to succeed but it's admittedly an ambitious project.

So forking off an experiment is the right move here. Pyston's existence as a side-project is pulling no resources away from the main project -- but it would if it was trying to send changes upstream.

Hypothetically the Pyston developers could be making non-JIT contributions to CPython instead, but developers aren't interchangeable commodities. Pyston's engineers have expertise in optimizations -- they may not be as skilled or interested in language development.

Re: Pyston v2: Faster Python

#49

Post by mrtranscendence »

throwaway894345 wrote: post #29
rrdharan wrote: post #17

Earlier quoted context omitted.

Python is a welcoming community, but they are decidedly not welcoming of contributions that significantly increase the complexity of the CPython reference implementation. This has been discussed extensively: https://news.ycombinator.com/item?id=11125769

This is why I see little hope for Python, which is to say that while I'm sure it will continue to have a large following for many years a la C, C++, etc, I don't have hope for it being an exciting language or one that is particularly productive. Python already has performance and packaging problems which don't seem to be easily divorced from CPython, since virtually the whole reference implementation is depended upon…

> Meanwhile, there are many other languages which are not only performant, but which are rapidly encroaching on Python's historically unique(ish) "easiness"

What are those languages? I may have a blindspot, but the languages that get enough buzz for me to notice are either not competing with Python in important dimensions (e.g. Rust) or have a narrower focus (e.g. Julia). Elixir maybe? JavaScript and its derivatives? But these lack the scientific programming ecosystem that's helped drive Python recently.

I have no doubt that languages exist that might fit the bill of being both as easy as and more performant than Python -- there are a lot of languages out there. But I'm unaware of any whose mindshare has been sufficiently growing that it threatens Python in the mid-term.

If I'm off base please let me know. I'd love to find a viable competitor to Python that's strictly better than it.

Re: Pyston v2: Faster Python

#50

Post by kmod »

jedberg wrote: post #10

I'm not versed in the details of the politics of CPython, but why did this project fork instead of just contributing to CPython? Is CPython really slow in integrating community contributions? Edit: I read the blog post closer, and found this: "Our plan is to open-source the code in the future, but since compiler projects are expensive and we no longer have benevolent corporate sponsorship, it is currently closed-sour…

I would say there's a small minority of our changes that we can upstream, and eventually we'd like to upstream them. For the rest, I would say the different set of priorities for the two projects means they probably will stay separate:

- In the blog post I linked to an issue of someone trying to upstream a quickening implementation and meeting resistance due to the added complexity

- CPython prefers portability over performance, and we added a number of big build dependencies that may not work on all the platforms that CPython supports, though from our perspective it works on all the important ones

- CPython has included a number of performance-degrading features over the years and we plan to start cutting out some that are only used for debugging but still hurt release mode. I don't know for sure but I would expect resistance to backing out those changes.

There are more, but the general idea is that the two projects will make different tradeoffs. Maybe there is a world where the code all lives in the same repository but is gated between different behaviors, but the CPython maintainers have already rejected a proposal like that.

Post reply on HN