14 ms·

Python-based compiler achieves orders-of-magnitude speedups

243 points by Stratoscope 4y ago

ac130kz 4y ago
Quite sad to know that the dynamic nature of Python is preventing the speedups in the first place. I really hope there'll be a built-in optimizing JIT compiler without the limitations of PyPy, Codon, Nuitka, Numba, etc.
- tlarkworthy 4y ago
  JavaScript/lua are dynamic and they are fast. It's other choices (GIL) which cause problem rather than the nature of the dynamic language space
  - tomn 4y ago
    The GIL improves single-threaded performance compared to other options.
    - tomn 4y ago
      Maybe i should have explained this.. To share objects between threads, some synchronisation is needed, for example to update reference counts. There are a few ways to do this: - make the user add locks; the problem with this if it goes wrong it can crash the interpreter and make it impossible to debug the problem from within python, which is not user-friendly, and lots of existing code will break. Competent users are already doing this though, so it's nearly free. - add fine-grained locking/synchronisation for object internals within the interpreter. This slows everything down, even if you're not using threads. - Lock the whole interpreter state whenever a thread is running. This makes threads less useful (no speed-up from threading pure-python code that isn't doing IO; you have to use multiprocessing for that), but it's cheap as you only need to lock/unlock when you're doing something slow anyway (IO, thread switching, native code). I think this explains why GIL removal has not been successful yet despite much work: the alternatives slow down single-threaded code, which is not worth it when nearly all sensible uses of threading don't benefit either.
  - ac130kz 4y ago
    I'd argue that JavaScript and Lua are much simpler underneath the hood, there's only a handful of types to be aware of, hence easier to make a JIT for.
deleted 4y ago
[deleted]
ar9av 4y ago
There are other python implementations like pypy which includes a JIT (Just In Time compiler). There are other jit which can run with official python (cpython) like numba (not all code can be optimized, but if you only need optimize your hot code path). You can use a superset language of python called cython that generate C code. It can be used to generate C bindings or fast python (for cpython) modules implemented in a python like code. You can use a really fast language like C, Rust, C++,... create python wrappers with cython, swig, Boost.python, cffi,... and use python like glue code. Python is not a fast languages as others, but there are tricks to make fast programs.
- a-dub 4y ago
  numba seems to hit the sweet spot for most numerics for me. it can get a little annoying with type inference issues but overall it seems the most concise and least hassle for moving loops into optimized machine code.
- DeathArrow 4y ago
  Can you use Django with those optimisations or are they good mainly for scientific computing?
  - doix 4y ago
    At my old gig we ran Django and FastAPI with pypy. I don't remember there being too many issues. One thing is that pypy versions lag behind official python, so if you're using bleeding edge stuff, it won't be supported in pypy yet. That was a couple of years ago at this point, and I've not been in the python ecosystem since then, but I can only imagine things are getting better in that regard rather than worse.
  - rpep 4y ago
    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.
t43562 4y ago
So the differences: https://docs.exaloop.io/codon/general/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 https://github.com/Nuitka/Nuitka I wonder really what the advantages/disadvantages of these are?
- SloopJon 4y ago
  Another big difference: "Codon is licensed under the Business Source License (BSL), which means its source code is publicly available and it's free for non-production use. ... each version of Codon converts to an actual open source license (specifically, Apache) after 3 years." https://docs.exaloop.io/codon/general/faq https://docs.exaloop.io/codon/general/faq
  - UncleEntity 4y ago
    Compilers traditionally don’t taint users code with their own license, seems this one does.
    - SloopJon 4y ago
      I don't see any indication that Codon makes any claim to generated code. It's just that the license prohibits production/commercial use of the compiler--not much different than other proprietary compilers like, say, Visual Studio.
- ptx 4y ago
  "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!
  - geysersam 4y ago
    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.
polotics 4y ago
previously: https://news.ycombinator.com/item?id=33908576 https://news.ycombinator.com/item?id=33908576
wageslave99 4y ago
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 of that language with C-API compatibility?
- CJefferson 4y ago
  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 you lots of your benefits of JITing. You could, hypothetically, introduce an entirely new API, which allowed for faster dynamic recompiling, but then you'd need to get every package anyone cares about to switch to that.
  - rustybolt 4y ago
    Sorry for the ignorance, but what do you mean by C-API here? Normally I'd say you mean the interface you use when you call native machine code from Python, but I don't see how this would slow things down.
    - radicalbyte 4y ago
      The interface to the C language. It is what makes Python fast - you write the code which needs to be fast in optimised C and call into it with Python. The Python code is then basically just the glue.
    - pdpi 4y ago
      That native code still needs to be able to interact with your Python objects somehow. You can't change the API around PyObject without forcing all C libraries to make changes on their side, and that API forces you to expose things a certain way.
DeathArrow 4y ago
>“Google users in America have searched for Python more often than for Kim Kardashian.” I wonder how Kim Kardashian programming language looks like. I guess low level but with garbage collector. :D
- a2800276 4y ago
  It wouldn't waste time garbage collecting to focus on trash talking instead.
  - rjmill 4y ago
    Introducing "Trashtalk" a Smalltalk dialect without GC! This language isn't here to make friends.
- spokeonawheel 4y ago
  do people actually talk about the kardashians still? I thought that was like 3 years ago
  - sigmoid10 4y ago
    The article states that this was around 2017-2018.
- pungentcomment 4y ago
  It's all garbage collector.
  - toss1 4y ago
    Seems like more like a scaled-up garbage producer than garbage collector...
- behnamoh 4y ago
  Kardashians are famous for... being famous.
DeathArrow 4y ago
It's not the first time it was tried to compile Python: https://en.wikipedia.org/wiki/IronPython https://en.wikipedia.org/wiki/IronPython I hope this time we will see better results.
- smcl 4y ago
  I'd say Nuitka or Cython are maybe the more common ones when talking about this. IronPython is/was interesting in that instead compiling to python bytecode or machine code it targetted the .NET CLR, and iirc I saw some kind of JIT going on when I was digging around (so some things ended up as machine code), but it's not really one of the usual "compiles python to machine code" implementations.
ginko 4y ago
nit: 'Python-based' would imply to me that it's written in Python, but it looks like it's mostly C++ & LLVM: https://github.com/exaloop/codon/tree/develop/codon https://github.com/exaloop/codon/tree/develop/codon
- pgt 4y ago
  Hardly a nitpick. It's key to the claim.
  - nerdponx 4y ago
    It's a little sad because PyPy literally is written in (a restricted subset of) Python, hence the name.
    - v3ss0n 4y ago
      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.
      - ddorian43 4y ago
        > 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)
        smolder 4y ago
        I suspect their relative memory efficiency depends on the size of the program and the size of the data it's processing.
        chc 4y ago
        Somewhat paradoxically, PyPy always uses more memory for programs with small working sets, but can use less memory for programs with large working sets. 1/6 is a lot more extreme than I would have expected, though.
crabbone 4y ago
Can we please not? Humanity wasted close to 50 years optimizing compilers for one garbage language. Wasted unimaginable efforts, money and developer hours... and all could've been avoided if the same people dedicated a fraction of those resources to language design. Same thing happened with Java. And now the existence of a well-developed compiler became an argument in its own right in favor of choosing a bad language. There's no need or reason to try to make Python run faster. It's a trash language. At best, it deserves a credit for being funny 30 years ago... but that had worn out pretty fast. Now it's just dumb. Improving its compiler will be again a resource sink for the programming community that, in the best case, may hope to produce something of value by accident, independent of its main goal...
- naijaboiler 4y ago
  yet its the language of choice for several people who are domain experts but not programming experts. It's doing a job for non-programmers who have to program. until a solution exists that does better, python is going nowhere.
  - crabbone 4y ago
    There are plenty of things which are bad but universally used. What's your point? Fast food is universally more popular than any healthy food that requires time to cook. People choose to buy low-quality goods in general, trading quality for immediate effect all the time. Take any industry, any product kind, you will see that consumption is skewed towards paying extra for immediate gain rather than paying for quality to minimize waste over time. The fact that you chose to rely on the opinion of non-experts in the field to assess the value / quality of a particular technology only means that you don't understand what quality is about. You are confused between wants and needs.
- deleted 4y ago
  [deleted]
- Mashimo 4y ago
  What is a non-trash programming language?
ptx 4y ago
"So we thought, let’s take Python syntax, semantics, and libraries and [...] Codon currently covers a sizable subset of Python, it still needs to incorporate several dynamic features and expand its Python library coverage. The Codon team is working hard to close the gap with Python even further".
bouchard 4y ago
I wonder how it compares to taichi-lang which also came out of MIT CSAIL and doesn't suffer from this "Business Source Licence" nonsense.
jwmoz 4y ago
Failed at the first hurdle: main.py:15:1: error: syntax error, unexpected 'async'
netbioserror 4y ago
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 qualities of the output products, are staggering. I'm kind of starting to see what Guido is talking about when he says Python is a legacy language that's probably on its way out. Even in the interpreted world, languages like Janet and other newcomers are performing fascinating experiments, often doing more with less.
- RayVR 4y ago
  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.
  - netbioserror 4y ago
    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.
    - RayVR 4y ago
      You said you don’t want to “crap on python” which I never said you were. I’m simply pointing out that what you’re “shocked by” makes complete sense if you look at what can be gained by people “bikeshed and optimize and compile python”
  - dgb23 4y ago
    But is this still really python? This compiler and others are not a drop in replacement. They typically cover a narrow subset and/or need additional code/hints etc. You can adopt it incrementally, but then you could just as well switch to a language with higher default performance, more language features that just work, unified tooling etc. and adopt that incrementally?
math_dandy 4y ago
Is it Pythonic enough to be compatible with tooling, e.g., the VS Code Python extension?
sirwhinesalot 4y ago
Surprised there is no comparison to MyPyC. That said the availability of a "JIT" compiler in the style of Numba but with much broader Python feature support sounds great to me.
- tekknolagi 4y ago
  You might enjoy Cinder then. It's based on CPython so it is nearly 100% compatible. https://github.com/facebookincubator/cinder/ https://github.com/facebookincubator/cinder/ Disclaimer: I used to work on it.
- adammarples 4y ago
  I took their fib example and ran it in mypyc too out of curiosity. I got speedups of ~10x rather than codon's 100x. Still pretty good, I like mypyc.
  - sirwhinesalot 4y ago
    mypyc keeps Python's "BigIntegers", unicode string implementation, reference counting, and has little to no floating point-related optimizations yet. It prioritizes compatibility over overall performance, so I'm not surprised. I was also disappointed at how poor mypyc is at compiling across multiple files, but that they can fix at some point. The BigInteger "issue" pretty much makes something like Fibonacci a worst case scenario for it.
    - ptx 4y ago
      Looks like they added support for unboxed floats yesterday (not sure about integers): https://github.com/python/mypy/commit/d05974b9b099ec755fd1c689a7d2c7150ea313af https://github.com/python/mypy/commit/d05974b9b099ec755fd1c6...
_gtly 4y ago
Paper here: "Codon: A Compiler for High-Performance Pythonic Applications and DSLs": https://dl.acm.org/doi/pdf/10.1145/3578360.3580275 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."
- rightbyte 4y ago
  Ye well if you remove the dynamic feutures of a dynamic language it gets fast. It would be really impressive of they can achieve those feutures with the sameish speed.
  - brucethemoose2 4y ago
    I dont necessarily need all that dynamism though, and would happily use a Python subset that removed some stuff (and forced type hinting) in exchange for better compilation. Yes there are already subsets like this, but its not as helpful if it isnt standard.
    - BiteCode_dev 4y ago
      Depends of the work you have to do. If you code a website, fast api and django, the two most popular framework to do so, heavily rely on them to make you productive.
      - bravura 4y ago
        If you code a website, your speed issues probably come from the database layer. Not your Python.
paro_nej 4y ago
> Faster than the speed of C One must note that this is impossible, unless you have chosen to handicap the C-implementations while benchmarking. Borderline unethical IMO to put forth such a claim.
- dbrueck 4y ago
  Pretty much every JIT-enabled language has this as at least a theoretical advantage over C. So not impossible and therefore not unethical.
  - paro_nej 4y ago
    They aren't JIT. They're doing AoT AFAICT.
    - dbrueck 4y ago
      I must have misunderstood what you were objecting to then, my bad. What claim are they making that is so impossible that it borders on being unethical? I mentioned JIT because it seems to be based on a similar principle at least, that of optimizing things on the programmer's behalf by looking at the program's usage and not just by looking at how to speed up the code generally.
      - paro_nej 4y ago
        My claim is that there is no additional information that Python provides as opposed to C that would make it faster. And hence, the only conclusion I have is either they have supercharged their compiler for that particular benchmark OR they have chosen to handicap C as once can express the computation in C that emits the same assembly that they lowered to and hence my point on handicapping the C benchmark.
        dbrueck 4y ago
        > My claim is that there is no additional information that Python provides as opposed to C that would make it faster Ok, but that's not what they are claiming - their claim (at least based on what the article is saying) is more about one toolchain vs another, i.e. "if you use our compiler (that takes python code as input) then the resulting executable will run as fast (or possibly faster than) programs created by all the popular compilers (that take C/C++ code as input)." The sales pitch is that they've got magic sauce in their compiler, and you get to use Python as well.
robomartin 4y ago
> Python — which is typically orders of magnitude slower than languages like C Not to nit-pick...this has been characterized by a team who tested and compared a large set of languages against a wide range of application code. The number is, if I remember correctly, about 78x slower. I don't think "orders" of magnitude is entirely fair. Yes, Python is slow. I have made the mistake of trying to use it for time-critical embedded applications. Never again. Aside from this admittedly pedantic observation, the first thing that crossed my mind with regards to this tool --which sounds fantastic-- is that you would have to trust the correctness and reliability of your code to this translation layer. Not sure how to think about this other than to keep a mental note of it if using this tool.
- rerx 4y ago
  78x is roughly two orders of magnitude in typical physics parlance. If you take a more CSy stance and count powers of two, it would be six to seven orders of magnitude. Sounds entirely fair to me.
  - robomartin 4y ago
    In the article they say most speed-ups are in the 5x to 10x range. The paper shows this to be true, particularly when compared to PyPy. In other words, the acceleration isn't measured against raw C implementations (where the 78x factor I quoted would be relevant). It is measured against Python or PyPy. How much faster does Codon make your Python code. The answer seems to be somewhere around the 5x to 10x range. In that context, and in the context of actual applications rather than hand-picked tests (how much can we optimize a loop), "orders of magnitude" seems to be an exaggeration. BTW, MIT does this kind of thing all the time with their press releases. They have a brand to support with outlandish claims about everything that comes out of there. Those with frequent exposure to this kind of press release are wise to this. I've seen it for decades. It's marketing. For me, when someone says "orders of magnitude" it means "massive". I tend to say "10 times faster", "50 times faster" even "100 times faster". I probably start using "orders of magnitude" faster at 1000x or when I am trying to explicitly make an impression on a mathematically-challenged audience. "Orders of magnitude" sounds great to that crowd. I have never, in 40 years in CS/Engineering, heard anyone use powers-of-two when they say "orders of magnitude". Doing so would open you to serious misinterpretation. Engineers might say something like "a factor of 2 to the n" or something like that.
hgoldfish 4y ago
I did a similar demo project five years ago when I was learning compiler theory. And it was implemented by Python. https://github.com/hgoldfish/aggie https://github.com/hgoldfish/aggie
AbsoluteCabbage 4y ago
Python should just have optional compilation built right into the language. Likewise, modern low level languages should have syntactical conveniences and optional whitespace. It’s 2023. We don’t need to keep having this war.
- messe 4y ago
  Scala seems to be taking this route with Scala 3. I’ll definitely be keeping an eye on it. The JVM is very underrated on HN, and I’m far from a Java fanboy (I’m basically a Zig evangelist).
  - mrkeen 4y ago
    > The JVM is very underrated on HN I don't like it for my use cases, but whenever I read about it on HN it's supposedly the best-tooled, finest artifact of performance engineering ever built.
- fulafel 4y ago
  I'm guessing you know, but as a reminder to readers, Python does have compilation built in. It works similarly as Java - source code is compiled to a bytecode that is then run by a virtual machine. A difference is that for executing that bytecode, CPython virtual machine have JIT native code generation.
zmmmmm 4y ago
Am losing count of all these efforts to rescue Python's performance - they all seem to amount to the same thing: it's not very hard to achieve this if you throw out fundamental aspects that make Python what it is. The premise is always that syntax is the barrier, and that people struggle so much to learn a new syntax that this is what keeps them using Python even though its performance is abysmal. But what if this isn't the right assumption? What if it's not the syntax but the ecosystem - and an ecosystem at that which highly depends on all the dynamic features to achieve what it does. Further than that, what about the assumption that people lacking confidence such that they blocked by learning another syntax are actually up for the challenge of understanding all the constraints and limitations of something that is something like but not quite real Python? These are exactly the people that you would expect to struggle with it.
- ActorNightly 4y ago
  What is this talk about "rescuing" Python performance? Python does not need to be rescued. Its fast enough. For 90% of applications, you are kidding yourself if you need more speed. These are enhancements on Python, where you want to run stuff even faster on par with other languages.
  - mrkeen 4y ago
    > What is this talk about "rescuing" Python performance? Which part don't you like: That python is relatively slow? https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/python3-java.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/... Or that people are trying to fix its slowness? See the thread you're currently in.
    - ActorNightly 4y ago
      Python is slower than other languages, yes. Python is not "slow" in the sense that it not applicable to use when you wanna run real world applications. Yours is the equivalent argument for buying a BMW M3 over a Toyota Corolla because it can do a faster lap time around a track and thus is better for your commute, except in the real world with traffic and traffic lights, on a 30 minute commute home, you will probably arrive at your destination 1 minute quicker in the BMW over a Corolla.
Labo333 4y ago
I don't understand those benchmarks: why is there no comparison to numba? Also comparisons where C++ is beaten don't seem very realistic.
BiteCode_dev 4y ago
Since this is highly incompatible with most python ecosystem right now, may I plug nuitka? https://nuitka.net/index.html https://nuitka.net/index.html It's a compiler for python code that can create stand alone executables, and up to 4 times the speed of the initial code. Best of all, it's extremely reliable, with a high level of support of event the tricky things like the scientic and gui stacks.
- plonk 4y ago
  Seconded, I deploy large packages with gigabytes of deep learning and GIS dependencies in single executables with Nuitka and it works very well. Also handles including data files into the executable if needed.
  - WhyCause 4y ago
    Out of curiosity, are the GIS dependencies the proprietary ones (coughESRIcough)?
    - anakaine 4y ago
      Ha ing been down a similar path, this whole thing works so much better if you don't 'import arcpy'. Licencing issues aside, you've often got faster tools in shapely, fiona, geopandas, rasterio, xarray.
    - plonk 4y ago
      Please no, not ArcGIS. I’m sure our dependencies would clash with arcpy’s if we tried. Fortunately my company uses FOSS packages almost exclusively.
  - flowersjeff 4y ago
    Third'ly?... Nuitka is amazing. Simply as that.
  - anakaine 4y ago
    We do similar. Works well.
mark_l_watson 4y ago
I just tried it and it works well enough for simple algorithmic code. I can't get any examples working though that do network I/O.
physPop 4y ago
Second post on this in two days? Had a show HN yesterday. We appreciate the info but dont plug an incomplete product so hard, especially one that doesn't really give other options a fair assessment on their website. Eg. no mention/discussion of nuitka, jax, etc.
misrasaurabh1 4y ago
This is super cool and useful. I know that Instabase , which also came from MIT got really popular and useful within finance communities because they allowed for really fast and efficient compute through their own Python DSL. Good to see this as an open source project which everyone can now use.
kmod 4y ago
Disclaimer: developer on Pyston, which could be considered a competitor My concern is: there have been a few projects already that are, from the outside, more or less the same approach and set of tradeoffs as this. And they haven't been that successful. Given that this is treading familiar ground I would expect some words about how this is different, and the lack thereof makes me a bit skeptical to say this will become successful when others did not.
- apgwoz 4y ago
  > and the lack thereof makes me a bit skeptical to say this will become successful when others did not. Success of projects like this is not usually based on merit, but on how many people you can convince to go along with it until it eventually becomes a thing of its own sustainability. So, the recipe here would be to: 1. Be "good enough" and easy enough to get started such that early adopters have a great first experience speeding up something important to them. (hook them) 2. Be open and friendly to potential incoming contributors, letting them land changes, have a say in the discussion, and generally be part of it all. (community build) 3. Encourage people to share their successes and hopes / dreams for how great $X is on their blogs, HN, social media, etc. (propaganda) 4. Goto 1. In this case, step 3 will work best by highlighting that "You actually don't need most of the dynamic features of Python" as the central narrative. One big caveat is that Codon choose to not use Python semantics for `%` so the basic test of `print(-2 % 5)` fails unless you run it with `-numerics=py`... which should just be the default behavior -- and a great first community patch / discussion!
deleted 4y ago
[deleted]
syngrog66 4y ago
took me a while to decode the fact that Codon is (AFAIK) just a Python-to-native compiler. and an incomplete/non-conformant one to boot. The title and OA was written in a breathless, but murky style "Oh... a native compiler. That cheats by not really honoring Python. Got it."

243 points by Stratoscope 4y ago

Quite sad to know that the dynamic nature of Python is preventing the speedups in the first place. I really hope there'll be a built-in optimizing JIT compiler without the limitations of PyPy, Codon, Nuitka, Numba, etc.

tlarkworthy 4y ago
JavaScript/lua are dynamic and they are fast. It's other choices (GIL) which cause problem rather than the nature of the dynamic language space
- tomn 4y ago
  The GIL improves single-threaded performance compared to other options.
  - tomn 4y ago
    Maybe i should have explained this.. To share objects between threads, some synchronisation is needed, for example to update reference counts. There are a few ways to do this: - make the user add locks; the problem with this if it goes wrong it can crash the interpreter and make it impossible to debug the problem from within python, which is not user-friendly, and lots of existing code will break. Competent users are already doing this though, so it's nearly free. - add fine-grained locking/synchronisation for object internals within the interpreter. This slows everything down, even if you're not using threads. - Lock the whole interpreter state whenever a thread is running. This makes threads less useful (no speed-up from threading pure-python code that isn't doing IO; you have to use multiprocessing for that), but it's cheap as you only need to lock/unlock when you're doing something slow anyway (IO, thread switching, native code). I think this explains why GIL removal has not been successful yet despite much work: the alternatives slow down single-threaded code, which is not worth it when nearly all sensible uses of threading don't benefit either.
- ac130kz 4y ago
  I'd argue that JavaScript and Lua are much simpler underneath the hood, there's only a handful of types to be aware of, hence easier to make a JIT for.

deleted 4y ago

[deleted]

ar9av 4y ago

There are other python implementations like pypy which includes a JIT (Just In Time compiler). There are other jit which can run with official python (cpython) like numba (not all code can be optimized, but if you only need optimize your hot code path). You can use a superset language of python called cython that generate C code. It can be used to generate C bindings or fast python (for cpython) modules implemented in a python like code. You can use a really fast language like C, Rust, C++,... create python wrappers with cython, swig, Boost.python, cffi,... and use python like glue code. Python is not a fast languages as others, but there are tricks to make fast programs.

a-dub 4y ago
numba seems to hit the sweet spot for most numerics for me. it can get a little annoying with type inference issues but overall it seems the most concise and least hassle for moving loops into optimized machine code.
DeathArrow 4y ago
Can you use Django with those optimisations or are they good mainly for scientific computing?
- doix 4y ago
  At my old gig we ran Django and FastAPI with pypy. I don't remember there being too many issues. One thing is that pypy versions lag behind official python, so if you're using bleeding edge stuff, it won't be supported in pypy yet. That was a couple of years ago at this point, and I've not been in the python ecosystem since then, but I can only imagine things are getting better in that regard rather than worse.
- rpep 4y ago
  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.

t43562 4y ago

So the differences: https://docs.exaloop.io/codon/general/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 https://github.com/Nuitka/Nuitka I wonder really what the advantages/disadvantages of these are?

SloopJon 4y ago
Another big difference: "Codon is licensed under the Business Source License (BSL), which means its source code is publicly available and it's free for non-production use. ... each version of Codon converts to an actual open source license (specifically, Apache) after 3 years." https://docs.exaloop.io/codon/general/faq https://docs.exaloop.io/codon/general/faq
- UncleEntity 4y ago
  Compilers traditionally don’t taint users code with their own license, seems this one does.
  - SloopJon 4y ago
    I don't see any indication that Codon makes any claim to generated code. It's just that the license prohibits production/commercial use of the compiler--not much different than other proprietary compilers like, say, Visual Studio.
ptx 4y ago
"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!
- geysersam 4y ago
  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.

polotics 4y ago

previously: https://news.ycombinator.com/item?id=33908576 https://news.ycombinator.com/item?id=33908576

wageslave99 4y ago

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 of that language with C-API compatibility?

CJefferson 4y ago
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 you lots of your benefits of JITing. You could, hypothetically, introduce an entirely new API, which allowed for faster dynamic recompiling, but then you'd need to get every package anyone cares about to switch to that.
- rustybolt 4y ago
  Sorry for the ignorance, but what do you mean by C-API here? Normally I'd say you mean the interface you use when you call native machine code from Python, but I don't see how this would slow things down.
  - radicalbyte 4y ago
    The interface to the C language. It is what makes Python fast - you write the code which needs to be fast in optimised C and call into it with Python. The Python code is then basically just the glue.
  - pdpi 4y ago
    That native code still needs to be able to interact with your Python objects somehow. You can't change the API around PyObject without forcing all C libraries to make changes on their side, and that API forces you to expose things a certain way.

DeathArrow 4y ago

>“Google users in America have searched for Python more often than for Kim Kardashian.” I wonder how Kim Kardashian programming language looks like. I guess low level but with garbage collector. :D

a2800276 4y ago
It wouldn't waste time garbage collecting to focus on trash talking instead.
- rjmill 4y ago
  Introducing "Trashtalk" a Smalltalk dialect without GC! This language isn't here to make friends.
spokeonawheel 4y ago
do people actually talk about the kardashians still? I thought that was like 3 years ago
- sigmoid10 4y ago
  The article states that this was around 2017-2018.
pungentcomment 4y ago
It's all garbage collector.
- toss1 4y ago
  Seems like more like a scaled-up garbage producer than garbage collector...
behnamoh 4y ago
Kardashians are famous for... being famous.

DeathArrow 4y ago

It's not the first time it was tried to compile Python: https://en.wikipedia.org/wiki/IronPython https://en.wikipedia.org/wiki/IronPython I hope this time we will see better results.

smcl 4y ago
I'd say Nuitka or Cython are maybe the more common ones when talking about this. IronPython is/was interesting in that instead compiling to python bytecode or machine code it targetted the .NET CLR, and iirc I saw some kind of JIT going on when I was digging around (so some things ended up as machine code), but it's not really one of the usual "compiles python to machine code" implementations.

ginko 4y ago

nit: 'Python-based' would imply to me that it's written in Python, but it looks like it's mostly C++ & LLVM: https://github.com/exaloop/codon/tree/develop/codon https://github.com/exaloop/codon/tree/develop/codon

pgt 4y ago
Hardly a nitpick. It's key to the claim.
- nerdponx 4y ago
  It's a little sad because PyPy literally is written in (a restricted subset of) Python, hence the name.
  - v3ss0n 4y ago
    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.
    - ddorian43 4y ago
      > 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)
      - smolder 4y ago
        I suspect their relative memory efficiency depends on the size of the program and the size of the data it's processing.
      - chc 4y ago
        Somewhat paradoxically, PyPy always uses more memory for programs with small working sets, but can use less memory for programs with large working sets. 1/6 is a lot more extreme than I would have expected, though.

crabbone 4y ago

Can we please not? Humanity wasted close to 50 years optimizing compilers for one garbage language. Wasted unimaginable efforts, money and developer hours... and all could've been avoided if the same people dedicated a fraction of those resources to language design. Same thing happened with Java. And now the existence of a well-developed compiler became an argument in its own right in favor of choosing a bad language. There's no need or reason to try to make Python run faster. It's a trash language. At best, it deserves a credit for being funny 30 years ago... but that had worn out pretty fast. Now it's just dumb. Improving its compiler will be again a resource sink for the programming community that, in the best case, may hope to produce something of value by accident, independent of its main goal...

naijaboiler 4y ago
yet its the language of choice for several people who are domain experts but not programming experts. It's doing a job for non-programmers who have to program. until a solution exists that does better, python is going nowhere.
- crabbone 4y ago
  There are plenty of things which are bad but universally used. What's your point? Fast food is universally more popular than any healthy food that requires time to cook. People choose to buy low-quality goods in general, trading quality for immediate effect all the time. Take any industry, any product kind, you will see that consumption is skewed towards paying extra for immediate gain rather than paying for quality to minimize waste over time. The fact that you chose to rely on the opinion of non-experts in the field to assess the value / quality of a particular technology only means that you don't understand what quality is about. You are confused between wants and needs.
deleted 4y ago
[deleted]
Mashimo 4y ago
What is a non-trash programming language?

ptx 4y ago

"So we thought, let’s take Python syntax, semantics, and libraries and [...] Codon currently covers a sizable subset of Python, it still needs to incorporate several dynamic features and expand its Python library coverage. The Codon team is working hard to close the gap with Python even further".

bouchard 4y ago

I wonder how it compares to taichi-lang which also came out of MIT CSAIL and doesn't suffer from this "Business Source Licence" nonsense.

jwmoz 4y ago

Failed at the first hurdle: main.py:15:1: error: syntax error, unexpected 'async'

netbioserror 4y ago

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 qualities of the output products, are staggering. I'm kind of starting to see what Guido is talking about when he says Python is a legacy language that's probably on its way out. Even in the interpreted world, languages like Janet and other newcomers are performing fascinating experiments, often doing more with less.

RayVR 4y ago
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.
- netbioserror 4y ago
  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.
  - RayVR 4y ago
    You said you don’t want to “crap on python” which I never said you were. I’m simply pointing out that what you’re “shocked by” makes complete sense if you look at what can be gained by people “bikeshed and optimize and compile python”
- dgb23 4y ago
  But is this still really python? This compiler and others are not a drop in replacement. They typically cover a narrow subset and/or need additional code/hints etc. You can adopt it incrementally, but then you could just as well switch to a language with higher default performance, more language features that just work, unified tooling etc. and adopt that incrementally?

math_dandy 4y ago

Is it Pythonic enough to be compatible with tooling, e.g., the VS Code Python extension?

sirwhinesalot 4y ago

Surprised there is no comparison to MyPyC. That said the availability of a "JIT" compiler in the style of Numba but with much broader Python feature support sounds great to me.

tekknolagi 4y ago
You might enjoy Cinder then. It's based on CPython so it is nearly 100% compatible. https://github.com/facebookincubator/cinder/ https://github.com/facebookincubator/cinder/ Disclaimer: I used to work on it.
adammarples 4y ago
I took their fib example and ran it in mypyc too out of curiosity. I got speedups of ~10x rather than codon's 100x. Still pretty good, I like mypyc.
- sirwhinesalot 4y ago
  mypyc keeps Python's "BigIntegers", unicode string implementation, reference counting, and has little to no floating point-related optimizations yet. It prioritizes compatibility over overall performance, so I'm not surprised. I was also disappointed at how poor mypyc is at compiling across multiple files, but that they can fix at some point. The BigInteger "issue" pretty much makes something like Fibonacci a worst case scenario for it.
  - ptx 4y ago
    Looks like they added support for unboxed floats yesterday (not sure about integers): https://github.com/python/mypy/commit/d05974b9b099ec755fd1c689a7d2c7150ea313af https://github.com/python/mypy/commit/d05974b9b099ec755fd1c6...

_gtly 4y ago

Paper here: "Codon: A Compiler for High-Performance Pythonic Applications and DSLs": https://dl.acm.org/doi/pdf/10.1145/3578360.3580275 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."

rightbyte 4y ago
Ye well if you remove the dynamic feutures of a dynamic language it gets fast. It would be really impressive of they can achieve those feutures with the sameish speed.
- brucethemoose2 4y ago
  I dont necessarily need all that dynamism though, and would happily use a Python subset that removed some stuff (and forced type hinting) in exchange for better compilation. Yes there are already subsets like this, but its not as helpful if it isnt standard.
  - BiteCode_dev 4y ago
    Depends of the work you have to do. If you code a website, fast api and django, the two most popular framework to do so, heavily rely on them to make you productive.
    - bravura 4y ago
      If you code a website, your speed issues probably come from the database layer. Not your Python.

paro_nej 4y ago

> Faster than the speed of C One must note that this is impossible, unless you have chosen to handicap the C-implementations while benchmarking. Borderline unethical IMO to put forth such a claim.

dbrueck 4y ago
Pretty much every JIT-enabled language has this as at least a theoretical advantage over C. So not impossible and therefore not unethical.
- paro_nej 4y ago
  They aren't JIT. They're doing AoT AFAICT.
  - dbrueck 4y ago
    I must have misunderstood what you were objecting to then, my bad. What claim are they making that is so impossible that it borders on being unethical? I mentioned JIT because it seems to be based on a similar principle at least, that of optimizing things on the programmer's behalf by looking at the program's usage and not just by looking at how to speed up the code generally.
    - paro_nej 4y ago
      My claim is that there is no additional information that Python provides as opposed to C that would make it faster. And hence, the only conclusion I have is either they have supercharged their compiler for that particular benchmark OR they have chosen to handicap C as once can express the computation in C that emits the same assembly that they lowered to and hence my point on handicapping the C benchmark.
      - dbrueck 4y ago
        > My claim is that there is no additional information that Python provides as opposed to C that would make it faster Ok, but that's not what they are claiming - their claim (at least based on what the article is saying) is more about one toolchain vs another, i.e. "if you use our compiler (that takes python code as input) then the resulting executable will run as fast (or possibly faster than) programs created by all the popular compilers (that take C/C++ code as input)." The sales pitch is that they've got magic sauce in their compiler, and you get to use Python as well.

robomartin 4y ago

> Python — which is typically orders of magnitude slower than languages like C Not to nit-pick...this has been characterized by a team who tested and compared a large set of languages against a wide range of application code. The number is, if I remember correctly, about 78x slower. I don't think "orders" of magnitude is entirely fair. Yes, Python is slow. I have made the mistake of trying to use it for time-critical embedded applications. Never again. Aside from this admittedly pedantic observation, the first thing that crossed my mind with regards to this tool --which sounds fantastic-- is that you would have to trust the correctness and reliability of your code to this translation layer. Not sure how to think about this other than to keep a mental note of it if using this tool.

rerx 4y ago
78x is roughly two orders of magnitude in typical physics parlance. If you take a more CSy stance and count powers of two, it would be six to seven orders of magnitude. Sounds entirely fair to me.
- robomartin 4y ago
  In the article they say most speed-ups are in the 5x to 10x range. The paper shows this to be true, particularly when compared to PyPy. In other words, the acceleration isn't measured against raw C implementations (where the 78x factor I quoted would be relevant). It is measured against Python or PyPy. How much faster does Codon make your Python code. The answer seems to be somewhere around the 5x to 10x range. In that context, and in the context of actual applications rather than hand-picked tests (how much can we optimize a loop), "orders of magnitude" seems to be an exaggeration. BTW, MIT does this kind of thing all the time with their press releases. They have a brand to support with outlandish claims about everything that comes out of there. Those with frequent exposure to this kind of press release are wise to this. I've seen it for decades. It's marketing. For me, when someone says "orders of magnitude" it means "massive". I tend to say "10 times faster", "50 times faster" even "100 times faster". I probably start using "orders of magnitude" faster at 1000x or when I am trying to explicitly make an impression on a mathematically-challenged audience. "Orders of magnitude" sounds great to that crowd. I have never, in 40 years in CS/Engineering, heard anyone use powers-of-two when they say "orders of magnitude". Doing so would open you to serious misinterpretation. Engineers might say something like "a factor of 2 to the n" or something like that.

hgoldfish 4y ago

I did a similar demo project five years ago when I was learning compiler theory. And it was implemented by Python. https://github.com/hgoldfish/aggie https://github.com/hgoldfish/aggie

AbsoluteCabbage 4y ago

Python should just have optional compilation built right into the language. Likewise, modern low level languages should have syntactical conveniences and optional whitespace. It’s 2023. We don’t need to keep having this war.

messe 4y ago
Scala seems to be taking this route with Scala 3. I’ll definitely be keeping an eye on it. The JVM is very underrated on HN, and I’m far from a Java fanboy (I’m basically a Zig evangelist).
- mrkeen 4y ago
  > The JVM is very underrated on HN I don't like it for my use cases, but whenever I read about it on HN it's supposedly the best-tooled, finest artifact of performance engineering ever built.
fulafel 4y ago
I'm guessing you know, but as a reminder to readers, Python does have compilation built in. It works similarly as Java - source code is compiled to a bytecode that is then run by a virtual machine. A difference is that for executing that bytecode, CPython virtual machine have JIT native code generation.

zmmmmm 4y ago

Am losing count of all these efforts to rescue Python's performance - they all seem to amount to the same thing: it's not very hard to achieve this if you throw out fundamental aspects that make Python what it is. The premise is always that syntax is the barrier, and that people struggle so much to learn a new syntax that this is what keeps them using Python even though its performance is abysmal. But what if this isn't the right assumption? What if it's not the syntax but the ecosystem - and an ecosystem at that which highly depends on all the dynamic features to achieve what it does. Further than that, what about the assumption that people lacking confidence such that they blocked by learning another syntax are actually up for the challenge of understanding all the constraints and limitations of something that is something like but not quite real Python? These are exactly the people that you would expect to struggle with it.

ActorNightly 4y ago
What is this talk about "rescuing" Python performance? Python does not need to be rescued. Its fast enough. For 90% of applications, you are kidding yourself if you need more speed. These are enhancements on Python, where you want to run stuff even faster on par with other languages.
- mrkeen 4y ago
  > What is this talk about "rescuing" Python performance? Which part don't you like: That python is relatively slow? https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/python3-java.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/... Or that people are trying to fix its slowness? See the thread you're currently in.
  - ActorNightly 4y ago
    Python is slower than other languages, yes. Python is not "slow" in the sense that it not applicable to use when you wanna run real world applications. Yours is the equivalent argument for buying a BMW M3 over a Toyota Corolla because it can do a faster lap time around a track and thus is better for your commute, except in the real world with traffic and traffic lights, on a 30 minute commute home, you will probably arrive at your destination 1 minute quicker in the BMW over a Corolla.

Labo333 4y ago

I don't understand those benchmarks: why is there no comparison to numba? Also comparisons where C++ is beaten don't seem very realistic.

BiteCode_dev 4y ago

Since this is highly incompatible with most python ecosystem right now, may I plug nuitka? https://nuitka.net/index.html https://nuitka.net/index.html It's a compiler for python code that can create stand alone executables, and up to 4 times the speed of the initial code. Best of all, it's extremely reliable, with a high level of support of event the tricky things like the scientic and gui stacks.

plonk 4y ago
Seconded, I deploy large packages with gigabytes of deep learning and GIS dependencies in single executables with Nuitka and it works very well. Also handles including data files into the executable if needed.
- WhyCause 4y ago
  Out of curiosity, are the GIS dependencies the proprietary ones (coughESRIcough)?
  - anakaine 4y ago
    Ha ing been down a similar path, this whole thing works so much better if you don't 'import arcpy'. Licencing issues aside, you've often got faster tools in shapely, fiona, geopandas, rasterio, xarray.
  - plonk 4y ago
    Please no, not ArcGIS. I’m sure our dependencies would clash with arcpy’s if we tried. Fortunately my company uses FOSS packages almost exclusively.
- flowersjeff 4y ago
  Third'ly?... Nuitka is amazing. Simply as that.
- anakaine 4y ago
  We do similar. Works well.

mark_l_watson 4y ago

I just tried it and it works well enough for simple algorithmic code. I can't get any examples working though that do network I/O.

physPop 4y ago

Second post on this in two days? Had a show HN yesterday. We appreciate the info but dont plug an incomplete product so hard, especially one that doesn't really give other options a fair assessment on their website. Eg. no mention/discussion of nuitka, jax, etc.

misrasaurabh1 4y ago

This is super cool and useful. I know that Instabase , which also came from MIT got really popular and useful within finance communities because they allowed for really fast and efficient compute through their own Python DSL. Good to see this as an open source project which everyone can now use.

kmod 4y ago

Disclaimer: developer on Pyston, which could be considered a competitor My concern is: there have been a few projects already that are, from the outside, more or less the same approach and set of tradeoffs as this. And they haven't been that successful. Given that this is treading familiar ground I would expect some words about how this is different, and the lack thereof makes me a bit skeptical to say this will become successful when others did not.

apgwoz 4y ago
> and the lack thereof makes me a bit skeptical to say this will become successful when others did not. Success of projects like this is not usually based on merit, but on how many people you can convince to go along with it until it eventually becomes a thing of its own sustainability. So, the recipe here would be to: 1. Be "good enough" and easy enough to get started such that early adopters have a great first experience speeding up something important to them. (hook them) 2. Be open and friendly to potential incoming contributors, letting them land changes, have a say in the discussion, and generally be part of it all. (community build) 3. Encourage people to share their successes and hopes / dreams for how great $X is on their blogs, HN, social media, etc. (propaganda) 4. Goto 1. In this case, step 3 will work best by highlighting that "You actually don't need most of the dynamic features of Python" as the central narrative. One big caveat is that Codon choose to not use Python semantics for `%` so the basic test of `print(-2 % 5)` fails unless you run it with `-numerics=py`... which should just be the default behavior -- and a great first community patch / discussion!

deleted 4y ago

[deleted]

syngrog66 4y ago

took me a while to decode the fact that Codon is (AFAIK) just a Python-to-native compiler. and an incomplete/non-conformant one to boot. The title and OA was written in a breathless, but murky style "Oh... a native compiler. That cheats by not really honoring Python. Got it."