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

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

github.com

Post reply on HN
Print view View original

31–40 of 95 posts

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

#31

Post by adammarples »

quotemstr wrote: post #20
haberman wrote: post #18

> 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-…

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…

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

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

#33

Post by actionfromafar »

orf wrote: post #27
quotemstr wrote: post #20

Earlier quoted context omitted.

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…

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.

The trade-off is a bit of speed.

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

#34

Post by actionfromafar »

axit wrote: post #22
troymc wrote: post #7

Earlier quoted context omitted.

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 "C…

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

Just to make it clear - the cutoff date on previously released software remains the same. So if you download it now and wait a few years, your software will have matured into its final form, the Apache 2 license.

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

#35

Post by stoperaticless »

adammarples wrote: post #31
quotemstr wrote: post #20

Earlier quoted context omitted.

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…

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

All versions of python are python.

If lang is not compatible with any of python versions, then the lang isn’t python.

False advertising is not nice. (even if the fineprint clarifies)

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

#36

Post by jay-barronville »

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

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

#37

Post by cjbillington »

actionfromafar wrote: post #33
orf wrote: post #27

Earlier quoted context omitted.

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.

The trade-off is a bit of speed.

This might be what you meant, but the ordered dicts are faster, no? I believe ordering was initially an implementation detail that arose as part of performance optimisations, and only later declared officially part of the spec.

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

#38

Post by dathinab »

bpshaver wrote: post #24
haberman wrote: post #18

> 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-…

Who is out here mixing types in a list anyway?

parsing json is roughly of the type:

type Json = None | bool | float | str | dict[str, Json] | list[Json]

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

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

#39

Post by bpshaver »

nicce wrote: post #29
bpshaver wrote: post #24

Earlier quoted context omitted.

Who is out here mixing types in a list anyway?

Everyone who chooses the Python in the first hand.

Well, I'm one of those people, and I feel that I rarely do this. Except if I have a list of different objects that implement the same interface, as another commenter mentioned.

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

#40

Post by bpshaver »

CaptainNegative wrote: post #26
bpshaver wrote: post #24

Earlier quoted context omitted.

Who is out here mixing types in a list anyway?

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?

Yeah, that seems fair.
Post reply on HN