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

Python-based compiler achieves orders-of-magnitude speedups

news.mit.edu

Post reply on HN
Print view View original

51–60 of 193 posts

Re: Python-based compiler achieves orders-of-magnitude speedups

#51

Post by RayVR »

netbioserror wrote: post #48

Preface: I don't just want to crap on Python here and sell Nim. I like Python, and still use it. But it still shocks me just how much money and manpower is thrown at trying to bikeshed and optimize and compile Python and its libraries, while the Nim compiler is essentially a community hobby project that has made the concept of a "compiled Python" a reality already. The orders of magnitude in scale difference, and the…

A lot of effort is dedicated to trying to improve the speed because python is so widely used that improving performance could have a massive beneficial impact.

Migrating to a new language is not easy when you have millions of lines of code.

Re: Python-based compiler achieves orders-of-magnitude speedups

#53

Post by v3ss0n »

nerdponx wrote: post #34
pgt wrote: post #31

Earlier quoted context omitted.

Hardly a nitpick. It's key to the claim.

It's a little sad because PyPy literally is written in (a restricted subset of) Python, hence the name.

And it is severely underrated. Even though performance gain is aevrate around 4x-20x. Used in production and memory usage is also about 1/6th of CPython. Can get 10x perfromance easily in many cases.

Re: Python-based compiler achieves orders-of-magnitude speedups

#55

Post by vlovich123 »

CJefferson wrote: post #6
wageslave99 wrote: post #5

I have no idea about compilers, so bear with me with this question: Can't we have a faster compiler for a subset of Python? I mean AFAIK the hard part of Python is that the language allows dynamic overwriting of attributes (or something like that). Is that feature actually needed for projects like Django, FastAPI, numpy, etc? Maybe I'm wrong, but the main idea I'd like to ask is, can we make a compiler for a subset o…

The problem turns out to be that it's maintaining the C-API compatibility which is the main thing which makes it hard to make Python fast, not the other stuff -- Javascript has most of the nasty things Python does, and it's plenty fast on browsers. However, maintaining C-API compatibility means you need to set up lots of data structures exactly how the C API requires, and maintaining and updating those ends up losing…

I really try hard to understand this argument and I must be missing something and must be super stupid. Don’t languages like JavaScript have this and yet they can still do JIT and the base runtime is still in C++? Java itself has an official way to invoke C programs from Java applications and still has a JIT. And Java also has AOT compilers.

Sure. Crossing that FFI boundary is going to be expensive. But there’s lots of techniques to mitigate it or even in the limit eliminate it. if I recall correctly you can JIT a fast call that knows how to invoke the FFI directly without the extra indirection layer. Basically a fancy runtime LTO.

I think a huge part of it is CPython’s interest in keeping the core codebase as simple as possible which seems to be the overriding reason for why the global lock still hasn’t been removed (which iirc even Ruby pulled off at some point). Also the reason there’s no JIT afaict and why Pypy got started to prove it is possible to JIT (and frequently sees substantial gains vs cpython). The problem they’ve had is that CPython is a moving target and it’s hard to keep a parallel runtime up to date on a shoestring amount of funding. That’s why you see alternate approaches like numba (JIT’ed Python) which are less of a departure and Cinder (better budget). To me this seems like a CPython project actively hostile to JIT than C data structures meaning you lose some benefit to FFI overhead. Performance is a virtuous cycle too - when there’s enthusiasm about a language you get more and more people paid to make your language fast. For a while companies tried. Google gave up. Facebook only has it as a fork with a public plea for the maintainers of CPython to mainline literally anything.

The CPython maintainers feel like the biggest obstacle. No?

Re: Python-based compiler achieves orders-of-magnitude speedups

#56

Post by _gtly »

Paper here: "Codon: A Compiler for High-Performance Pythonic Applications and DSLs": https://dl.acm.org/doi/pdf/10.1145/3578360.3580275

"Currently, there are several Python features that Codon does not support. They mainly consist of runtime polymorphism, runtime reflection and type manipulation (e.g., dynamic method table modification, dynamic addition of class members, metaclasses, and class decorators). There are also gaps in the standard Python library coverage. While Codon ships with Python interoperability as a workaround to some of these limitations, future work is planned to expand the amount of Pythonic code immediately compatible with the framework by adding features such as runtime polymorphism and by implementing better interoperability with the existing Python libraries. Finally, we plan to increase the standard library coverage, as well as extend syntax configurability for custom DSLs."

Re: Python-based compiler achieves orders-of-magnitude speedups

#57

Post by ddorian43 »

v3ss0n wrote: post #53
nerdponx wrote: post #34

Earlier quoted context omitted.

It's a little sad because PyPy literally is written in (a restricted subset of) Python, hence the name.

And it is severely underrated. Even though performance gain is aevrate around 4x-20x. Used in production and memory usage is also about 1/6th of CPython. Can get 10x perfromance easily in many cases.

> Used in production and memory usage is also about 1/6th of CPython

I thought it would have higher memory usage? (based only on reading)

Re: Python-based compiler achieves orders-of-magnitude speedups

#58

Post by geysersam »

ptx wrote: post #42
t43562 wrote: post #3

So the differences: https://docs.exaloop.io/codon/general/differences So more limited types (integers) and more type checking and collections have to have one kind of thing in them. There are other python compilers though, like https://github.com/Nuitka/Nuitka I wonder really what the advantages/disadvantages of these are?

"While Codon's syntax and semantics are virtually identical to Python's, [...] Codon currently uses ASCII strings unlike Python's unicode strings." So aside from that tiny issue at the center of the decade-long Python 2 to 3 migration debacle, it's virtually identical!

It also uses 64-bit ints instead of the infinite size ints in CPython.

Sounds like an issue that could easily bite someone in the behind and cause quite nasty bugs.

Re: Python-based compiler achieves orders-of-magnitude speedups

#59

Post by netbioserror »

RayVR wrote: post #51
netbioserror wrote: post #48

Preface: I don't just want to crap on Python here and sell Nim. I like Python, and still use it. But it still shocks me just how much money and manpower is thrown at trying to bikeshed and optimize and compile Python and its libraries, while the Nim compiler is essentially a community hobby project that has made the concept of a "compiled Python" a reality already. The orders of magnitude in scale difference, and the…

A lot of effort is dedicated to trying to improve the speed because python is so widely used that improving performance could have a massive beneficial impact. Migrating to a new language is not easy when you have millions of lines of code.

I didn't say that anyone should switch (see my preface), and I perfectly well understand this point. Having to retread this point over and over just serves to make our comments long and redundant and full of qualifiers, but I guess here we are again.

Re: Python-based compiler achieves orders-of-magnitude speedups

#60

Post by coldtea »

rpep wrote: post #23
DeathArrow wrote: post #19

Earlier quoted context omitted.

Can you use Django with those optimisations or are they good mainly for scientific computing?

You can certainly use it, but whether you see any benefit is going to strongly depend on your workload. If you're doing significant calculations in the API then it might be considerably more performant, but if your API is primarily retrieving things from the database and transforming it to JSON then you're going to be limited mostly by the database latency and so I wouldn't expect major improvements.

And yet the same supposedly "io bound" workloads (like "parse request, fetch something from DB, return it as JSON") still have widely difference performance characteristics in some languages vs others, with 10x to 100x requests handled per second...
Post reply on HN