Pyston v2: Faster Python
blog.pyston.org
blog.pyston.org
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-source while we iron out our business model."
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.
This has been discussed extensively: https://news.ycombinator.com/item?id=11125769
Pypy has done yeoman's work in improving performance while maintaining compatibility with an impressive amount of the ecosystem, and even still there are many important packages which aren't compatible with Pypy and for which Pypy-compatible analogs don't exist (or aren't supported/maintained). For example, the only Pypy-compatible Postgres drivers were unsupported last I checked.
Moreover, the Python community (or at least its leadership) seems to have very little energy around tackling these longstanding problems. Meanwhile, there are many other languages which are not only performant, but which are rapidly encroaching on Python's historically unique(ish) "easiness" (in the sense that Python is considered "easy", which is to say for people who don't have to manage build/deploy/packaging/etc or otherwise have performance issues). Further, many of these languages continue to improve at a remarkable pace, while Python is content to rest on the laurels of its scientific computing mindshare--and given the rather poor nature of the numeric computing package APIs and their somewhat low performance ceiling, I don't expect Python to be so dominant in this domain in another 5-10 years, especially as more companies need to figure out how to productionize scientific workloads.
https://commandcenter.blogspot.com/2012/06/less-is-exponenti...
If this version of generics finally makes it, then I care, otherwise only when dealing with Docker and Kubernetes eco-system.
Silence and distance seems to be a common echo of failed projects.
Don't forget Rob Pike created Sawzall at Google first (2005). [2]
[1] https://golang.org/doc/faq#history [2] https://research.google/pubs/pub61/
It doesn't really support or attack your claims. It's just a thing I wanted to share.
Google most certainly did not.
http://qinsb.blogspot.com/2011/03/unladen-swallow-retrospect...
And anytime you point this out, people will trot out a toy problem in Cython and try to prove you wrong, which has zero relevance to real world issues. Hell, Cython cannot even compile something as basic as Numpy FFTs, something that is absolutely critical in signal processing.
Google put some effort, not that much, into Unladen Swallow, and the people who worked on it admitted that it didn't achieve the goals they set. The Python community was well on their way to creating Python 3 before work started on Unladen Swallow (so it was not in any way "Python's response"). As other comments pointed out, Google did not hire Rob Pike to "do" Go. Go was initially a side project of a few people and had nothing whatsoever to do with Python. The Go team was surprised when Python users started migrating to it. Google never used Python for web development, with one major exception, Youtube, an acquisition. I also don't understand how Google has "moved on" from Python (this seems unlikely) and how what they use Python for internally has anything at all to do with the fate of Django and Python webdev.
I don't mean to pile on, but I kinda have to ask, what were you thinking when you wrote this comment? Do you believe all those statements, or were you taking huge liberties with facts and making guesses to tell a story that supports a statement you wanted to make? You seem like a valued member of the community and this kinda makes me distrust the accuracy of everything else you write. (And to be honest, makes me distrust more of what I read in general, which is probably good but sad.)
A couple references for history/dates:
https://en.wikipedia.org/wiki/CPython#Unladen_Swallow https://www.python.org/dev/peps/pep-3000/
WRT poor APIs, I'm talking about things like matplotlib or pandas or etc that take a whole slew of arguments and try to guess the caller's intent by inspecting the types of the arguments. The referent isn't "some other scientific computing API" (although I'm sure there are some sane scientific computing APIs), but rather "other APIs in general" since there's nothing inherent to any particular domain that demands this kind of 'magical' API.
WRT 'hardly anyone is CPU bound'--the context is numeric computing; what are people bound by if not CPU? I've seen several projects where web endpoints were timing out while grinding in Pandas, largely because there weren't good options for taking advantage of multiple processors. Based on prototypes I did, I'm confident that other languages could serve those requests in single-digit seconds if not sub-second.
> Nowadays, my rule of thumb for pandas is that you should have 5 to 10 times as much RAM as the size of your dataset
[1] https://wesmckinney.com/blog/apache-arrow-pandas-internals/
Web application using Pandas and "highly optimized web application" would seem to be nearly disjoint sets...
Also, if an endpoint is spending minutes to respond, then I would think actually profiling the application would be a good start. Maybe researching prior art in the problem domain would be good too. If nobody can be bothered to explore the several solutions to distributing pandas computations over multiple cores, like Dask, and get the NPV of just buying more or faster cores, then “Python sucks” isn’t your problem.
“My application is slow, the language sucks!” Doesn’t indicate a very serious investigation into the problem.
HTTP is pretty complex, but that's neither here nor there. The relevant bit is that there is no domain for which guessing caller intent based on reflection over argument types is appropriate.
> “My application is slow, the language sucks!” Doesn’t indicate a very serious investigation into the problem.
I was pretty explicit above and elsewhere in this thread about why Python's performance is miserable; I'm not sure why you would invoke such a poorly constructed straw man when everyone can look upthread and see my actual arguments.
But once you've done the cleaning/exploration, you should move any heavy computing to a high-performance library like numpy.
Plotting seems to tend towards magic because plots are basically art, with all the desire for aesthetic customization that applies, and it's a very common task so users also want brevity (magic). The result is a plot() function with a gazillion options hidden behind keyword arguments.
I agree that matplotlib has a sprawling interface, and this can be annoying, but I'm still not sure what "guess the caller's intent by inspecting the types of the arguments" means. Sure, the functions have multiple call signatures, but that's not exactly unusual in libraries or languages. I don't understand the context that brings guesswork into the picture. Skimming the manual—are you using the data keyword argument and hitting the `plot('n', 'o', data=obj)` ambiguity [0]? Or calling plot through `pyplot.plot` &c. (which rely on state) instead of `Axes.plot` &c.?
Asking because if there's an interface trap I'm unaware of I'd like to learn about it before walking into it blindly.
Pandas I sort of agree with; I personally find it harder to remember how to use pandas than dplyr, despite using pandas more often and spending more time reading the pandas documentation. I also find it inconvenient to represent missing values in Pandas (`None` and `NaN` are overloaded, and `None` forces the `object` dtype). But maybe the problem is on my end.
[0] https://matplotlib.org/3.3.2/api/_as_gen/matplotlib.pyplot.p...
R provides an interface to dataframes and matrices, whereas numpy is just for matrices (and their generalisations, arrrays). I think the appropriate comparison is between base R and Numpy + pandas. (FWIW, I agree with your major point, but then I learned R first so that may be biasing me).
I will say that the differences between python and R syntax are almost trivial; I've taught classes with python and R example scripts that are almost _exactly_ the same, and run in both languages
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.
I strongly recommend Go as a better Python. Personally, I think it's easier to write than Python (although people who care very little about correctness will be bothered a bit by the type checker), and the tooling is many times better (single-binary deployments, great dependency management, etc are awesome). Also, the performance is about 100-1000 times better for serial execution, and Go's goroutines allow you to take advantage of multiple cores much more easily than with Python.
JavaScript and TypeScript are similarly easy-to-use, performant languages with a better-than-Python tooling story. I've also heard similar things about Elixir, Closure, and Kotlin.
I've heard Go described this way several times, but I've found it to be a significantly lower-level language than Python.
For example, it's much more verbose. In this recent blog post [0], the author converts some C++ code to Go - and it gets longer. 57 lines of C++ become 65 lines of Go. The same code in Python is about 20 lines.
In particular, the author's Go code requires five lines to do the equivalent of Python's `with open(path) as f` and four lines for the equivalent of `word_array = list(word_counts.items())`:
f, err := os.Open(path)
if err != nil {
return err
}
defer f.Close()
// [...]
wordArray := make([]WordCount, 0, len(wordCounts))
for word, count := range wordCounts {
wordArray = append(wordArray, WordCount{word: word, count: count})
}
This is crazy. Many of those lines are closing brackets or whitespace. But moreover, optimizing for characters or LOC is absurd. Optimize for maintainability or readability, at which point Go is at least as good as Python (I would argue better). Optimize for tooling, especially package management and build tooling--Go is many times better than Python here. Optimize for performance--Go is literally hundreds or thousands of times better here. Optimize for breadth and quality of ecosystem. Optimize for deployment story (single small artifact vs hundreds of megabytes of dependencies). These are the things that matter, not lines of code.
The type-assertion escape hatch has always been largely sufficient for all but the most performance-critical projects (of which I have exactly 1, and it was a side project), and runtime panics due to failed assertions are quite easy to eliminate via wrapper types.
My advice: just go for it. You almost certainly won't miss generics.
(Edit: I've broken my own rule and given advice without first asking what kind of programming you do. My assertion holds for most run-of-the-mill stuff, e.g. writing REST interfaces, network servers, etc. If you're within 2-sigma of the industry, you won't miss generics.)
Dynamic languages do that implicitly.
Implement max in Go with interface{} without casts and reflection:
def max(a, b):
if a >= b:
a
else:
b1. The abstract idea of writing an algorithm that supports a variety of types. This allows for casting, reflection, dynamic typing, etc.
2. The specific idea of a type system that allows for parameterized types (aka "typesafe generics"). This definition excludes castng, reflection, and dynamic typing.
Typically "typesafe generics" is what people talk about when they discuss "generics", but since you chose to pick the "dynamically typed languages are generic" nit, I assumed you were talking about (1).
Some of Python's strengths that I work with regularly are dynamism, easy data exploration, visualizations, succinct & customizable syntax, extremely strong data science libraries, REPL/Jupyter, C bindings, easy to use packaging solution via PyPi (bet some people are going to disagree with that one), quick to prototype code. If you really need performance in Python, you can probably get it out of the box (if you can run deep learning with Python, performance isn't a limitation).
I love Go and use it for a bunch of projects, but I've only once wanted to move a project from Python to Go and that was a performance-centric CLI that was only written in Python originally because of how quickly it let us prototype in comparison to Go.
From my perspective Julia is sacrifising some amount of "duct tape UX" to gain speed, and that's the wrong direction.
Whenever we need more speed, we just pull the slow bits down into compiled languages, and scale them out to many cores with solutions like MPI.
R is another language that is mainly duct tape for stringing pieces of compiled code together. If it had a better UX for developers than Python, I think we would see it dominating much more today, without having any speed advantage.
This only works sometimes--for problems that allow you to do a relatively large amount of computation in the compiled language to justify the cost of marshalling Python data structures into native data structures. For matrices of scalar values, this works well. For many other problems (consider large graphs of arbitrarily-typed Python objects, or even a dataframe on which you need to invoke a Python callback on each element). If you rewrite a big enough piece of your Python codebase in the compiled language, then it will work, but now you're maintaining a significant C/C++/etc code base and the bindings and the build/packaging system that knows how to integrate the two on all of your target platforms. Python really doesn't have a good answer for these kinds of problems, and these are by far the more common case (though perhaps not more common in data science specifically).
Interestingly, R is probably a better UX for statisticians/data scientists than Python is (almost all the good parts of Numpy/Pandas were in R first), but it really suffers from not being well known by developers.
To be fair to R though, it's much, much easier to deploy than Python, which is a shocking indictment of the current Python packaging ecosystem.
What particular language features of Julia make that trade-off? (Not a rhetorical question, I'm not disagreeing with you, just curious; I'm familiar with Python, not really familiar with Julia.)
These aren't fundamental issues with the language and will be solved by tiered compilation (there's already an interpreter mode, just have to integrate that with normal use), separate compilation and incremental sysimage creation which works with the package manager.
More than performance (pure Python can be too slow, but NumPy is usually fast enough), this is what I miss when using Python.
There's currently no good solution for bundling Python code and the interpreter into a single binary. PyInstaller works, but the resulting binaries write lots of files to `/tmp` every time they run, which is a hack that leads to long startup times. PyOxidizer avoids this, but includes the entire standard library in every binary, making them too large by an order of magnitude.
It's still a little too wild-west for my tastes right now, but I want it to improve as I think it's got real potential.
Data science may be at the heart of Python's strengths, but it's simply not accurate to suggest Python (whoever that is!) is resting on its laurels, as evidenced by the very active, albeit sprawling, package ecosystem. And while the CPython devs seem to have found their stride in 3.x releases.
It's also inaccurate to suggest numeric computing in Python has a "low performance ceiling," considering you can get near-C performance via JIT or AOT using a package like Numba, and in most cases it's not even necessary because of Numpy and the many other highly optimized compute packages that can do most of the heavy lifting.
I think the main draw of Python is not just that the syntax and language features are approachable, but that the package ecosystem is so broad and active, you are likely to make lighter work of the same job done in another language. I think to displace Python you would have to displace the package ecosystem, which seems as big and broad as it's ever been.
As far as I'm concerned, CPython as an interpreter technology has not advanced in the past decade - and Python has grown thanks to the data science community efforts and excellent library ecosystem you mention, not due to PSF. PSF can only miss so many opportunities before something comprehensively better starts to eclipse it.
I agree performance is important, and I think we have reason to be optimistic, but with the understanding that that level of improvement, even if currently underway, will just take a lot of effort and time. Meanwhile, as someone fairly new to Python and working on several performance critical pieces, I've been pretty impressed with what you can do with the current compute packages (after taking months to work my way through most of them).
In a recent post linked on HN, Steve Yegge basically nailed it:
> How much new software was written in something other than Python, which might have been written in Python if Guido hadn’t burned everyone’s house down? It’s hard to say, but I can tell you, it hasn’t been good for Python. It’s a huge mess and everyone is miserable.
Note to future language maintainers: don't burn everyone's house down.
The main problem I have with Python is its maintainability, especially when you have multiple developers working in the same code base. I would never choose a dynamically typed language again to build something that is going to be more than several thousand lines of code, especially because of how it cripples your IDE which is essential for helping junior developers understand the existing codebase. Type hints help to an extent, but they're just a small bandaid over an oozing sore. Languages like Go are significantly better if you're going to build large codebases that need to survive for a long period of time.
For example, I do a bit of Swift in addition to Python, and sometimes I've heard people try to compare the two. But I vastly prefer Python to Swift when I can afford to.
I also will say that a lot of the complexity of making a Python JIT is all the weird edge cases and special interpreter functionality. To a VM engineer, CPython is a very bizarre codebase; all the complexity is tucked away in corners other than its C codebase.
Your complexity has to go somewhere.
Ironically this also makes CPython less interesting as a reference language - which keeps PyPy and co insignificant in adoption...
https://github.com/python/cpython/blob/master/Python/ceval.c...
CPython does use threads (on Linux, it spawns one pthread per Python thread). However it also has a lock (the infamous GIL) that prevents those threads from interpreting Python code simultaneously.
It's an interpreter implementation technique.
The plan looks very high level at this point, but it looks like Mark is an expert in interpreter VM and JIT technologies. All I can hope for is that he doesn't get blocked by the "keep cpython simple" obstructionism.
There's new boss(es) over the Python project, and things might be changing in the near future.
- 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.
There are a lot of reasons actually
- Performance limited by old CPython design. If you fork it you have to deal with all the legacy code.
- CPython is limited to 1 thread because of the GIL.
- Specific memory allocators, C structures, reference counting, specific garbage collector etc.
You can find that video in here: https://youtu.be/TXRPCZ7Nmh4
It took me some clicks to see it's supposed to be a drop-in replacement, so that's good.
Also 20% is huge, I look forward to trying it!
That being said, those libraries are already highly optimized and all the heavy stuff running on C anyways, so making the Python itself faster won't make that much of a difference in those workflows.
The Python language is already 30 years old, and it wasn’t even the cutting-edge in imperative language design (<koff>Smalltalk, Lisp</koff>) 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.
And I say this as a 20-year Python user myself, ’cos while it has scratched many itches and continues to do so, I am not the least bit sentimental about it. The best compliment would be to kill it with something far better, that steals all its good parts and replaces the rest.
Well, I, for one, use Python because "the actual language is appealing compared to modern languages".
I think you are confusing ecosystem and other established advantages with sunk costs, they are different things. It's true that (from the perspective of the people who built them), those advantages are the products of sunk costs, but the argument is about the ongoing value delivered, not the sunk cost involved in delivering it.
> Not much about the actual language is appealing compared to modern languages.
Even if that was true, many of the actual languages competing with Python are less modern by any measure, and in any case so what? Does it matter when choosing a langauge if an advantage is produced by the abstract design of a language, it's ecosystem, or the peculiarities of the available implementations? Advantages are advantages, value is value.
Sure, if you are considering how to promote a “modern” language against Python, it's important to distinguish whether your current barrier is the design of your language or Python’s ecosystem to know how to direct your efforts, but if you aren't a tool evangelist and instead are choosing a language for a project, I don't see that it matters why Python is a net advantage, as long as it is.
Which is an admirable sentiment… but the title of this thread is not “Python: still doing useful work” but “Python: now 20% faster”, and being ridiculously self-congratulatory about this when the correct response is to laugh at the silly pointless frivolity of it.
Trying to make Python fast is a fool’s errand, because Python is slow by design.
A useful argument would be that Python is faster overall at solving various real-world problems than current alternatives; but that’s not the popular argument being made, because the population fixates on minutiae instead of overall perspective.
No, it's actually, “Pyston v2: 20% faster Python". But...so what?
> and being ridiculously self-congratulatory about this when the correct response is to laugh at the silly pointless frivolity of it
For the same reasons Python is often a valuable choice, a faster Python is a valuable option.
> Trying to make Python fast is a fool’s errand, because Python is slow by design.
Python is not slow by design, though it's slow because it's not fast by design. But that doesn't mean it's not useful to have a faster Python, only that there are likely to be limits and trade-offs involved in doing that.
> A useful argument would be that Python is faster overall at solving various real-world problems than current alternatives; but that’s not the popular argument being made
Yes, actually, it is. It's not the message of the Pyston v2 release blog entry, but then that blog entry isn't making an argument in the debate that you seem to want everything to be about.
Everything in Python is late-bound, untyped, and mutable by default. Straight off the bat that’s three key design decisions that make for a slow interpreter. Defining numbers as heap objects, implementing structures as hash tables, and poor parallelization (<koff>GIL, dumb POSIX threading) are three more.
Sure, you can throw huge amounts of brains and resources at code analysis, opportunistic JIT, and the rest a-la V8, but at some point you have to say “Is this an effective use of those valuable resources?” Especially when every such optimization could potentially break existing, stable user code running in production.
..
But, let’s get back to larger perspective:
Faster overall takes into account not just the time it takes to run a user program, but also the time it takes to learn, implement, debug, and deploy. Only one of these is machine time, which these days is cheap as chips and nearly inexhaustable; all the rest are human labor, which is both expensive and limited.
Which is not to say that Python is faster at all those human tasks than other languages. To determine that would require real-world practical testing, plus a willingness to accept what those tests tell you (which might not be what you wanted to hear). But I’m willing to bet that the time spent on all those manual tasks vastly outweighs the time saved by 20% faster runtime for the vast majority of use cases.
So at some point you have to stop and ask: Are these fundamental changes adding genuine, measurable value for real-world users solving real-world problems? Or is it just code masturbation basement nerds whose idea of productivity is playing with internal guts in pursuit of some trivial abstract benchmarks?
Because, honestly, “20% faster” is an absolute joke. If I can’t make my program 200% faster just by adding a second hardware box, then I’ll want to know why. And if the answer is no more complex than “because the language isn’t very good at parallelism”, then all other arguments are completely moot.
..
Look, I’ve written slow interpreters. Implemented in Python, no less. A not-very-complex program might take 2 minutes to run. But then, 80% of that painfully long run-time is actually IO-bound operations, and even that is totally irrelevant when those 2 minutes of machine time have replaced 20 minutes of manual work.
That’s 20 minutes of paid human labor, eliminated by a really-slow custom interpreter written in pretty-slow CPython. You can easily put a dollar cost on that human time (salary, etc) and multiply it by the number of work units in a year, and you’ve calculated its real-world benefit.
Let us know when you can calculate the real-world benefit of a 20% quicker proprietary Python-like interpreter that may or may not execute user programs exactly the same as CPython. Otherwise, as I say, anything less than a magnitude’s improvement isn’t even worth getting out of bed for.
Doesn’t bother me; I’ve got points to spare.
What downvoters haven’t got, it seems, is any arguments.
Eh. If newer versions of cpython end up 20% faster, eventually most things will end up running on those newer versions. It may take years for almost everything to drift to newer versions, but there's a noticeable performance benefit we all realize over time.
> 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.
Python's great at running numpy, scikit, and tensorflow. It's not the bottleneck, because these are largely native libraries-- achieving something "much faster" and "more efficient" for this are doubtful.
The benefits of Python are that it A) has a huge ecosystem, B) it's relatively polished and expedient to write code in, and C) there's a ton of people who know it. These are not easy things to create somewhere else, and there's no guarantee that the set of tradeoffs you choose will leave you in a better place afterwards.
The biggest downside of Python is that if you want to get a lot of concurrency or performance for Python code (instead of things like numpy, scikit, and tensorflow), you get pushed into the edges of the Python ecosystem, where you only get a portion of A's advantage (but still largely realize B & C).
Right - but if you can get that with better performance that's good isn't it?
I don't get why people object to performance work on languages not intended for performance.
Presumably because they see it as effort that could be better applied elsewhere.
I don't know that I agree, but I can understand the viewpoint.
You're right, this objection is not relevant in general.
But in the situation we talk about, having 20 % more performance requires you to choose a fork that can came with it's own limitation. It's definitely not free.
This trade of makes the point about the language choice relevant.
My gut feeling is that Python is just not safe or static enough to ever be worth trying to compete with (say) C++ with. Python sure is easy but I think the asymptotic cost of using it for a big project (in my hands at least) is just not worth it.
I like Python's syntax quite a bit but I feel bad watching people learn to program using it - partly because it's an oddly low-level language (It's closer to being C than Haskell) and there's no compiler to stop you shooting yourself in the foot (If I write something fundamentally unsound I want to know about it now not when the process has been running all day)
It's simple, really. They're concerned about the trade-offs.
And more importantly, your original question isn't asking about forks, specifically. It was asking why someone might oppose performance work.
But it's compatible. It's a drop-in replacement.
Moreover, you continue to cherry pick, neglecting the other arguments you’ve been presented. It sounds like you’ve already made up your mind about this.
Well, anybody using Python for all its over benefits, still would very much like more speed.
Interesting. DynASM [1] is the template assembler used in LuaJIT, so it sounds like they might be JIT'ing CPython bytecode. IIRC this is also what the first version of Pyston did. I'm curious how this is working out, both implementation and performance-wise compared to LLVM (used in Pyston v1). That could mean there is a lot of performance still on the table, at least for some kinds of code, but also a big complexity jump to get further gains.
Copyright: 2020 The Pyston Team <support@pyston.org>
License: Closed source, all rights reserved.
> 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-source while we iron out our business model.
Since when does someone need to explicitly grant you permission to run a program on your own computer?
Those limitations existed since before the computer time, when the copyright law was passed. For example, even you own a book, there are certain things you can not do, like duplicate it and sell copies.
In case of software, here is how the law works [0]
> When you make a creative work (which includes code), the work is under exclusive copyright by default. Unless you include a license that specifies otherwise, nobody else can copy, distribute, or modify your work without being at risk of take-downs, shake-downs, or litigation.
There are "fair use" terms, which allow some things without permissions -- but things like "copying the binary to company-internal repo so CI runners can pick it" really need explicit permissions if you want to be above the board.
I wonder if he would be interested in optimizing for purely algorithmic tasks?
There are a lot active and successful CPython and PyPy users on https://atcoder.jp/. For example:
https://atcoder.jp/contests/practice2/submissions?f.Task=&f.... (the user "maspy" is rated at 2750 using only cpython!!!)
https://atcoder.jp/contests/practice2/submissions?f.Task=&f.... (though pypy is more practical)
I am linking to atcoder because their testing data is public so you can rerun contestants solutions using both pyston/cpython/pypy for benchmarking purposes: https://www.dropbox.com/sh/arnpe0ef5wds8cv/AAAk_SECQ2Nc6SVGi...
Right now, other than a handful of people who figured out how to make numba's jit work, only pypy is viable for competitive programming. I wonder if you can do better than pypy?
There are also a few red coders on codeforces.com who mostly use pypy (cpython is completely unviable there because numpy and numba is not installed)
https://codeforces.com/submissions/pajenegod
https://codeforces.com/submissions/conqueror_of_tourist
But codeforces' test cases aren't public anyway so it's not as relevant.
While we could certainly go in this direction, we're not planning to, because in our experience optimizations for different workloads are largely distinct, and this use case is already handled well by PyPy.
I think it's still a relatively low effort way (just need to write a scraper) to create a benchmark on a diverse set of algorithmic tasks that have clearcut criteria on AC/TLE/WA. PyPy is often 10x faster than cpython on these problems (and just 2x slower than equivalent C++ solution) so it will be a much nicer headline too if you can achieve similar performances!
Though I can also see how it can be completely irrelevant for server workloads. Pypy's unicode is so slow, some people on codeforces still use pypy2 over pypy3 just to avoid it. And c extensions is so bad on pypy, you can often get better performance on cpython if you need to use numpy.
So I would not call this "scientific computing". Personally I consider competitive programming to be it's own use case.
And as much as we want to improve scientific computing in Python, it's very hard since the work is done in C. Our current hope is to help mixed workloads, such as doing a decent amount of data-preprocessing in Python before handing off to C code.
I didn't know the Pyston team had split off to form their own company! Anyone know who's involved, or if they've raised money for it?
In some cases a rewrite may save more money than moving to a 20% faster python.
Rewriting in a more efficient language might seem even cheaper, but you have to factor in risk and opportunity cost. At some point it does become smarter to rewrite, but your app needs to be pretty simple or your server bill pretty huge before it’s actually the best option.
The V8 Javascript interpreter can generate machine code dinamically targetting the host arch for each bytecode instruction..
You can define the target assembly directly in C++ without resorting to any specific machine code.
Maybe complexity or because they wanted to stick to C?
Because that's a long term risk on subtle differences that may crop up.
> 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-source while we iron out our business model.
Maybe someone has something newer.
At Oct 28 kevmod deleted all the history.
As others have been pouring out before, the new load attr opcache is maybe the most interesting recent performance improvement that was merged.
(only kinda joking)
Going from a 230mb Flask app down to 55mb is huge if it's really a drop in replacement. If you factor in gunicorn process count, the wins are even higher because if you had 4 gunicorn processes each using 230mb but now they use 55mb, you're really going from 920mb down to 220mb of RAM.
Edit: This isn't true in the end, a brain malfunction mis-read the table thinking PyPy was actually the regular Python interpreter. It would be interesting to see how it compares to the default Python implementation for memory usage tho.
I don't know why but I read PyPy 7.3.2 as Python 3.7 in the table. Talk about a brain auto-complete failure haha.
Looks like inline caching of some specific ops with certain types. Some arith and call ops are optimized this way.
It also looks like dynasm was later replaced by the much slower llvm, so it needs heavy warmup.
Like, if you wanted to create a confusing name, I can't think of worse ideas than naming it "v2" for a runtime that is Python 3 compatible, particularly for a project that has traditionally been Python 2 compatible...
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.
Should there be a "language spec", competing implementation would make the language stronger not weaker. Examples include gccgo, various Java vm, C++ compilers.
This, and combined with https://www.hyrumslaw.com/, makes this "Python Language Reference" a "CPython Language Reference".