A high-performance, zero-overhead, extensible Python compiler using LLVM

by wspeirs • 2 years ago

241 93 2 years ago

I immediately wonder how it compares to Shedskin¹

I can say one thing - Shedskin compiles to C++, which was very compelling to me for integrating into existing C++ products. Actually another thing too, Shedskin is Open Source under GPLv3. (Like GCC.)

1: https://github.com/shedskin/shedskin/

crorella• 2 years ago

I looks like codon has less restrictions when compared to shed skin.

actionfromafar4• 2 years ago

I suppose that's right, I don't think shedskin can call numpy yet, for instance. On the other hand it seems easier to put shedskin on an embedded device, for instance.

Lucasoato• 2 years ago

Is Codon free? Codon is and always will be free for non-production use. That means you can use Codon freely for personal, academic, or other non-commercial applications.

I hope it is released under a truly open-source license in the future; this seems like a promising technology. I'm also wondering how it would match C++ performance if it is still garbage collected.

troymc2• 2 years ago

The license is the "Business Source License 1.1" [1].

The Business Source License (BSL) 1.1 is a software license created by MariaDB Corporation. It's designed as a middle ground between fully open-source licenses and traditional proprietary software licenses. It's kind of neat because it's a parameteric license, in that you can change some parameters while leaving the text of the license unchanged.

For codon, the "Change Date" is 2028-03-01 and the "Change License" is "Apache License, Version 2.0", meaning that the license will change to Apache2 in March of 2028. Until then, I guess you need to make a deal with Exaloop to use codon in production.

[1] https://github.com/exaloop/codon?tab=License-1-ov-file#readm...

axit• 2 years ago

From what I've seen is the "Change Date" is usually updated so you always have a few years older software as Apache License and the latest software as BSL

jitl• 2 years ago

What’s the difference between this and Cython? I think another comment already asks about shedskin.

rich_sasha• 2 years ago

Cython relies heavily on the Python runtime. You cannot, for example, make a standalone binary with it. A lot of unoptimized Cython binary is just Python wrapped in C.

From a quick glance this seems to genuinely translate into native execution.

edscho• 2 years ago

You absolutely can create a standalone binary with Cython: see the `--embed` option [1].

[1] https://cython.readthedocs.io/en/stable/src/tutorial/embeddi...

veber-alex• 2 years ago

What's up with their benchmarks[1], it just shows benchmark names and I don't see any numbers or graphs. Tried Safari and Chrome.

[1] https://exaloop.io/benchmarks/

sdmike1• 2 years ago

The benchmark page looks to be broken, the JS console is showing some 404'd JS libs and a bad function call.

pizlonator• 2 years ago

Also those are some bullshit benchmarks.

It’s not surprising that you can make a static compiler that makes tiny little programs written in a dynamic language into fast executables.

The hard part is making that scale to >=10,000 LoC programs. I dunno which static reasoning approaches codon uses, but all the ones I’m familiar with fall apart when you try to scale to large code.

That’s why JS benchmarking focused on larger and larger programs over time. Even the small programs that JS JIT writers use tend to have a lot of subtle idioms that break static reasoning, to model what happens in larger programs.

If you want to get in the business of making dynamic languages fast then the best advice I can give you is don’t use any of the benchmarks that these folks cite for your perf tuning. If you really do have to start with small programs then something like Richards or deltablue are ok, but you’ll want to diversify to larger programs if you really want to keep it real.

(Source: I was a combatant in the JS perf wars for a decade as a webkitten.)

big-chungus4• 2 years ago

so, assuming I don't get integers bigger than int64, and don't use the order of build in dicts, can I just use arbitrary python code and use it with codon? Can I use external libraries? Numpy, PyTorch? Also noticed that it isn't supported on windows

w10-1• 2 years ago

Unclear if this has been in the works longer as the graalvm LLVM build of python discussed yesterday[1]. The first HN discussion is from 2022 [3].

Any relation? Any comparisons?

Funny I can't find the license for graalvm python in their docs [2]. That could be a differentiator.

- [1] GraalVM Python on HN https://news.ycombinator.com/item?id=41570708

- [2] GraalVM Python site https://www.graalvm.org/python/

- [3] HN Dec 2022 https://news.ycombinator.com/item?id=33908576

vamega• 2 years ago

GraalPy license on GitHub - https://github.com/oracle/graalpython/blob/master/LICENSE.tx...

mech422• 2 years ago

Might want to look at PyPy too: https://pypy.org/features.html

Sparkenstein• 2 years ago

Biggest problem at the moment is async support, I guess

https://github.com/exaloop/codon/issues/71

codethief• 2 years ago

Reminds me of these two projects which were presented at EuroPython 2024 this summer:

https://ep2024.europython.eu/session/spy-static-python-lang-...

https://ep2024.europython.eu/session/how-to-build-a-python-t...

(The talks were fantastic but they have yet to upload the recordings to YouTube.)

haberman• 2 years ago

Non-goals: Drop-in replacement for CPython: Codon is not a drop-in replacement for CPython. There are some aspects of Python that are not suitable for static compilation — we don't support these in Codon.

This is targeting a Python subset, not Python itself.

For example, something as simple as this will not compile, because lists cannot mix types in Codon (https://docs.exaloop.io/codon/language/collections#strong-ty...):

    l = [1, 's']

It's confusing to call this a "Python compiler" when the constraints it imposes pretty fundamentally change the nature of the language.

odo1242• 2 years ago

Yeah, it feels closer to something like Cython without the python part.

quotemstr• 2 years ago

It's not even a subset. They break foundational contracts of the Python language without technical necessity. For example,

Dictionaries: Codon's dictionary type does not preserve insertion order, unlike Python's as of 3.6.

That's a gratuitous break. Nothing about preserving insertion order interferes with compilation, AOT or otherwise. The authors of Codon broke dict ordering because they felt like it, not because they had to.

At least Mojo merely claims to be Python-like. Unlike Codon, it doesn't claim to be Python then note in the fine print that it doesn't uphold Python contractual language semantics.

orf2• 2 years ago

Try not to throw around statements like “they broke duct ordering because they felt like it”.

Obviously they didn’t do that. There are trade-offs when preserving dictionary ordering.

adammarples• 2 years ago

Well would you claim that Python 3.5 isn't python?

jjk7• 2 years ago

The differences seem relatively minor. Your specific example can be worked around by using a tuple; which in most cases does what you want.

itishappy2• 2 years ago

Altering python's core datatypes is not what I'd call minor.

They don't even mention the changes to `list`.

Integers: Codon's int is a 64-bit signed integer, whereas Python's (after version 3) can be arbitrarily large. However Codon does support larger integers via Int[N] where N is the bit width.
Strings: Codon currently uses ASCII strings unlike Python's unicode strings.
Dictionaries: Codon's dictionary type does not preserve insertion order, unlike Python's as of 3.6.
Tuples: Since tuples compile down to structs, tuple lengths must be known at compile time, meaning you can't convert an arbitrarily-sized list to a tuple, for instance.

https://docs.exaloop.io/codon/general/differences

Pretty sure this means the following doesn't work either:

    config = { "name": "John Doe", "age": 32 }

Note: It looks like you can get around this via Python interop, but that further supports the point that this isn't really Python.

bpshaver7• 2 years ago

Who is out here mixing types in a list anyway?

orf2• 2 years ago

It’s common to have a list of objects with different types, but which implement the same interface. Duck typing of this kind is core to Python.

CaptainNegative• 2 years ago

I often find myself mixing Nones into lists containing built-in types when the former would indicate some kind of error. I could wrap them all into a nullable-style type, but why shouldn't the interpreter implicitly handle that for me?

nicce• 2 years ago

Everyone who chooses the Python in the first hand.

itishappy2• 2 years ago

The json module returns heterogenous dicts.

https://docs.python.org/3/library/json.html

dathinab3• 2 years ago

parsing json is roughly of the type:

you might have similar situations for configs e.g. float | str for time in seconds or a human readable time string like "30s" etc.

given how fundamental such things are I'm not sure if there will be any larger projects (especially wrt. web servers and similar) which are compatible with this

also many commonly used features for libraries/classes etc. are not very likely to work (but idk. for sure, they just are very dynamic in nature)

so IMHO this seems to be more like a python-like language you can use for idk. some since computations and similar then a general purpose faster python

RogerL• 2 years ago

return [key, value]

__mharrison__• 2 years ago

Someone who is using Python the wrong way.

dekhn• 2 years ago

I've been mixing types in Python lists for several decades now. Why wouldn't you? it's a list of PyObjects.

gwking2• 2 years ago

An example related to JSON content is HTML content. I have a Python library that represents all of the standard HTML tags as a family of classes. It is like a lightweight DOM on the server side, and has resulted in a web server that does not use string based templating at all. It lets me construct trees of HTML completely in Python and then render them out with everything correctly escaped. I can also parse HTML into trees and manipulate them as I please (for e.g. scraping tasks and document transforms). It is all strongly typed using mypy and I adhere to the strictest generic typing I can manage.

Each node has a list of children, and the element type is `str|HtmlNode`. I find this vastly easier to use than the LXML ETree api, where nodes have `text` and `tail` attributes to represent interleaved text.

Interestingly, the LXML docs promote their design as follows: > he two properties .text and .tail are enough to represent any text content in an XML document. This way, the ElementTree API does not require any special text nodes in addition to the Element class, that tend to get in the way fairly often (as you might know from classic DOM APIs). https://lxml.de/tutorial.html#elements-contain-text

It could be a simple matter of taste! But I suspect that the difference between what they are describing as "classic DOM" vs what I am doing is that they are referring to experience with C/C++/Java libraries circa 2009 that had much less convenient dynamic type introspection. The "get in the way fairly often" reminds me of how verbose it is to deal with heterogenous data in C/C++/ObjC. In ObjC for example, you could have an array mixing NSString with other NSObject subclasses, but you had to do work to type it correctly. If you wanted numbers in there you had to use NSNumber which is an annoying box type that you never otherwise use. And ObjC was considered very dynamic in its day!

I have long felt that the root of much evil was the overbearing distinction between primitive and object types in C++/Java/Objective-C.

All of this is a long way of saying, I think "how to deal with heterogenous lists of stuff" is a huge question in language design, library design, and the daily work of programming. Modern languages have by no means converged on a single way to represent varying types of elements. If you want to create trees of stuff, at some level that is "mixing types in a list" no matter how you might try to encode it. Just food for thought!

BiteCode_dev• 2 years ago

For a real compiler try nuitka.

wpietri2• 2 years ago

Yeah, this right here would kill it for me:

Strings: Codon currently uses ASCII strings unlike Python's unicode strings.

That rules out almost anything web-ish for me.

The use case I could imagine is places where you have a bunch of python programmers who don't really want to learn another language but you have modest amounts of very speed-sensitive work.

E.g., you're a financial trading company who has hired a lot of PhDs with data science experience. In that context, I could imagine saying, "Ok, quants, all of your production code has to work in Codon". It's not like they're programming masters anyhow, and having it be pretty Python-ish will be good enough for them.

wpietri2• 2 years ago

Ah, looking further, I find this about the company: "Their focus lies in bridging the gap between these two aspects across various domains, with a particular emphasis on life sciences and bioinformatics."

That makes sense as a sales pitch. "Hey, company with a lot of money! Want your nerds to go faster and need less expensive hardware? Pay us for magic speed-ups!" So it's less a product for programmers than it is for executives.

Retr0id• 2 years ago

> Strings: Codon currently uses ASCII strings unlike Python's unicode strings.

Yikes. These days I wouldn't even call those strings, just bytes. I can live with static/strong typing (I prefer it, even), but not having support for actual strings is a huge blow.

timwaagh• 2 years ago

It's a really expensive piece of software. They do not publish their prices because of it. I don't think it's reasonable to market such products onto your average dev because of it. Anyhow Cython and a bunch of others provide a free and open source alternative.

zamazan4ik• 2 years ago

I hope one day the compiler itself will be optimized even more: https://github.com/exaloop/codon/issues/137

jay-barronville• 2 years ago

Instead of building their GPU support atop CUDA/NVIDIA [0], I’m wondering why they didn’t instead go with WebGPU [1] via something like wgpu [2]. Using wgpu, they could offer cross-platform compatibility across several graphics API’s, covering a wide range of hardware including NVIDIA GeForce and Quadro, AMD Radeon, Intel Iris and Arc, ARM Mali, and Apple’s integrated GPU’s.

They note the following [0]:

The GPU module is under active development. APIs and semantics might change between Codon releases.

The thing is, based on the current syntax and semantics I see, it’ll almost certainly need to change to support non-NVIDIA devices, so I think it might be a better idea to just go with WebGPU compute pipelines sooner rather than later.

Just my two pennies…

[0] https://docs.exaloop.io/codon/advanced/gpu

[1] https://www.w3.org/TR/webgpu

[2] https://wgpu.rs

MadnessASAP• 2 years ago

Well for better or worse CUDA is the GPU programming API. If you're doing high performance GPU workloads you're almost certainly doing it in CUDA.

WebGPU while stating compute is within their design I would imagine is focused on presentation/rendering and probably not on large demanding workloads.

pjmlp• 2 years ago

Because WebGPU is a API designed for browsers, targeting hardware designs from 2016.

amelius• 2 years ago

The challenge is not just to make Python faster, it's to make Python faster __and__ port the ecosystem of Python modules to your new environment.

Myrmornis2• 2 years ago

This should be top comment. If I don't get the ecosystem then I'd just use Rust.

eigenspace• 2 years ago

It’s also just simply not python. It’s a separate language with a confusingly close syntax to python, but quite different semantics.

ipsum2• 2 years ago

Previous discussion (2022): https://news.ycombinator.com/item?id=33908576

shikon7• 2 years ago

From the documentation of the differences with Python:

Strings: Codon currently uses ASCII strings unlike Python's unicode strings.

That seems really odd to me. Who would use a framework nowadays that doesn't support unicode?

tony-allan• 2 years ago

I would love to see LLVM/WebAssembly as a supported and documented backend!

GTP• 2 years ago

People that landed here may be interested in Mojo [0] as well.

[0] https://www.modular.com/mojo

mgaunard• 2 years ago

aren't there like a dozen of those already?

numba, cython, pypy...

albertzeyer• 2 years ago

There is also RPython (used by PyPy) (https://rpython.readthedocs.io/), which is a strict subset of Python, allowing for static analysis, specifically for the translation logic needed by PyPy. Thus, I was told that RPython is not really intended as a general purpose language/compiler but only really specifically to implement sth like PyPy.

But it's anyway maybe an interesting comparison to Codon.

xiaodai• 2 years ago

Please stop trying to make python fast. Move over to Julia already.

A high-performance, zero-overhead, extensible Python compiler using LLVM

Related Stories