Live data from Hacker News

Codon: A high-performance Python-like compiler using LLVM

github.com

131–140 of 184 posts

Re: Codon: A high-performance Python-like compiler using LLVM

#131
post #51
post #34

Can we change the title to say Python-like or something similar? Based on the comments so far, it seems that the detail that it compiles its own Python-inspired language, not actual Python, is lost on many. EDIT: A list of differences here: https://docs.exaloop.io/codon/general/differences The summary minimizes with "many Python programs will work with few if any modifications", but it actually looks like a substanti…

That list actually seems genuinely pretty minimal. Reading your comment I was expecting a long major list of changes, but it's only 3 things, most of which seem relatively unlikely to impact most programs, with the possible exception of dictionary sort order.

> …with the possible exception of dictionary sort order.

Which is an implementation detail that is not guaranteed by the language standard.

Porting code from 2 to 3 made me have to use a sorted dict because the code relied on the insertion order (metaclass magic operating on the class dict) but when they revamped the dictionary implementation I could do away with that fix. Until they come up with a more efficient dict and break everyone’s code again.

Does make me want to dust off the old spark parser and see what this can do with it.

Re: Codon: A high-performance Python-like compiler using LLVM

#132
post #93

Since Codon performs static type checking ahead of time, a few of Python's dynamic features are disallowed. For example, monkey patching classes at runtime (although Codon supports a form of this at compile time) or adding objects of different types to a collection. This seems like a very different language from Python if it won't let you do: [1, 'a string']

I have been using Python since 25 years, and never needed that one.

You never implemented a quick polish notation calculator that uses this data structure? [1,2, '+']

Re: Codon: A high-performance Python-like compiler using LLVM

#133

Earlier quoted context omitted.

In 25 years you’ve never once created a list with more than one type of object in it?

I mean, it depends on what you mean by “type”. A list of some Protocol type (what other languages call “interfaces”) is still a homogenous list even though the concrete types are heterogeneous. This is almost always what you want when you’re thinking of “a heterogeneous list”.

It's not unheard of to have unions and a couple of if isinstance.

In fact it's why in python they even have the | operator between types nowadays.

Re: Codon: A high-performance Python-like compiler using LLVM

#135
post #18

Unfortunately stuff like this never makes it to the upstream. And i am afraid to ask why. We had pypy for years, but never got merged with python. That is why there are still minor incompatibilities between pypy and "The Python", so it's not that useful as it might have been if it got merged with cpython at some point.

I got a massive jump in performance when moving from Python 3.8 to 3.10 (over some function call optimizations I think, based on the project). And 3.11 got even better (up to 50% faster on special cases, and 10~15% on average) with respect to 3.10. Python 3.12 is already getting even more speedups and a there's a lot more down the road[0]. But Python core developers value keeping "not breaking anyones code" (Python 3…

I got performance regression going from 3.10 to 3.11

https://ltworf.github.io/typedload/performance.html

Re: Codon: A high-performance Python-like compiler using LLVM

#136

Anybody claiming it's almost Python is kidding themselves. This compiler needs to do static type checking. This is inherently impossible in Python. Not just because of some obscure corner cases that nobody uses. It's baked into the language itself. Reality-check: Why do you think type hints and type checkers like mypy and pyright take such a long time to get going and even they are not there yet? If this was all so e…

What about GraalVM? Are they overselling, too?

No, their python support repository readme explicitly tells it’s highly experimental.

Re: Codon: A high-performance Python-like compiler using LLVM

#138
post #66

Earlier quoted context omitted.

I don't think python without heterogenous lists and dictionaries is really python?

I can't think of a time I ever needed to do such a thing, and I've written many thousand lines of python. Python supports OOP, so classes will get you quite far in this regard.

Wouldn't that exclude (most) nested lists?

Re: Codon: A high-performance Python-like compiler using LLVM

#139

Anybody claiming it's almost Python is kidding themselves. This compiler needs to do static type checking. This is inherently impossible in Python. Not just because of some obscure corner cases that nobody uses. It's baked into the language itself. Reality-check: Why do you think type hints and type checkers like mypy and pyright take such a long time to get going and even they are not there yet? If this was all so e…

If I can write (mostly) python code and get it to run on my GPU they can oversell this all they want.

I have a couple of projects I’ve been wanting to tackle but put off because I like python but it wouldn’t be a very good fit due to performance reasons. Now I get a whole new herd of yaks to shave.

Plus, extensible compiler? Who doesn’t want linq in python?

Re: Codon: A high-performance Python-like compiler using LLVM

#140

Earlier quoted context omitted.

Same here. If I needed that I might use a tuple.

And then it crashes when you convert it to JSON.

I just use an extension wrapper around boost::property_tree for my json (and xml) needs. Way faster than the built in json support and does automagic type conversion so I don’t have to worry about it.

Now, I’m not running at Web Scale™ but pure python was slow enough to be annoying.

Post reply on HN