[HN Gopher] A high-performance, zero-overhead, extensible Python...
___________________________________________________________________
A high-performance, zero-overhead, extensible Python compiler using
LLVM
Author : wspeirs
Score : 132 points
Date : 2024-09-18 14:44 UTC (8 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| actionfromafar wrote:
| I immediately wonder how it compares to Shedskin1
|
| 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 wrote:
| I looks like codon has less restrictions when compared to shed
| skin.
| actionfromafar wrote:
| 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 wrote:
| > 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.
| troymc wrote:
| 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 wrote:
| 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
| actionfromafar wrote:
| 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.
| jitl wrote:
| What's the difference between this and Cython? I think another
| comment already asks about shedskin.
| rich_sasha wrote:
| 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 wrote:
| You absolutely can create a standalone binary with Cython:
| see the `--embed` option [1].
|
| [1] https://cython.readthedocs.io/en/stable/src/tutorial/embe
| ddi...
| veber-alex wrote:
| 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 wrote:
| The benchmark page looks to be broken, the JS console is
| showing some 404'd JS libs and a bad function call.
| big-chungus4 wrote:
| 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 wrote:
| 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 wrote:
| GraalPy license on GitHub -
| https://github.com/oracle/graalpython/blob/master/LICENSE.tx...
| Sparkenstein wrote:
| Biggest problem at the moment is async support, I guess
|
| https://github.com/exaloop/codon/issues/71
| codethief wrote:
| 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 wrote:
| > 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 wrote:
| Yeah, it feels closer to something like Cython without the
| python part.
| quotemstr wrote:
| 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.
| orf wrote:
| 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.
| actionfromafar wrote:
| The trade-off is a bit of speed.
| cjbillington wrote:
| 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.
| dathinab wrote:
| if you claim
|
| > high-performance Python implementation
|
| then no this aren't trade-offs but breaking the standard
| without it truly being necessary
|
| most important this will break code in a subtle and
| potentially very surprising way
|
| they could just claim they are python like and then no one
| would hold them for not keeping to the standard
|
| but if you are misleading about your product people will
| find offense even if it isn't intentionally
| adammarples wrote:
| Well would you claim that Python 3.5 isn't python?
| stoperaticless wrote:
| 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)
| jjk7 wrote:
| The differences seem relatively minor. Your specific example
| can be worked around by using a tuple; which in most cases does
| what you want.
| itishappy wrote:
| 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.
| bpshaver wrote:
| Who is out here mixing types in a list anyway?
| orf wrote:
| 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.
| bpshaver wrote:
| Good point.
| CaptainNegative wrote:
| 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?
| bpshaver wrote:
| Yeah, that seems fair.
| nicce wrote:
| Everyone who chooses the Python in the first hand.
| bpshaver wrote:
| 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.
| itishappy wrote:
| The json module returns heterogenous dicts.
|
| https://docs.python.org/3/library/json.html
| bpshaver wrote:
| Yeah, just because it _can_ do that doesn 't mean that it
| is good design.
| dathinab wrote:
| 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
| bpshaver wrote:
| Agreed, I was just joking. I understand heterogenous lists
| are possible with Python, but with the use of static type
| checking I feel like its pretty rare for me to have
| heterogenous lists unless its duck typing.
| timwaagh wrote:
| 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 wrote:
| I hope one day the compiler itself will be optimized even more:
| https://github.com/exaloop/codon/issues/137
| jay-barronville wrote:
| 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
___________________________________________________________________
(page generated 2024-09-18 23:00 UTC)