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
Github reports it's 55% C++ and 43% Python, not too bad if it's correct.
Python-based compiler achieves orders-of-magnitude speedups
101–110 of 193 posts
Re: Python-based compiler achieves orders-of-magnitude speedups
#102Paper here: "Codon: A Compiler for High-Performance Pythonic Applications and DSLs": 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…
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.
Re: Python-based compiler achieves orders-of-magnitude speedups
#103Python 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.
Re: Python-based compiler achieves orders-of-magnitude speedups
#104Can 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…
Who is "we"? You don't have to have anything to do with it.
We, the programming community. And I'd rather you would have nothing to do with it than me.
Re: Python-based compiler achieves orders-of-magnitude speedups
#105Paper here: "Codon: A Compiler for High-Performance Pythonic Applications and DSLs": 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…
I wonder what experienced Common Lisp compiler devs could accomplish if they turned their attention to Python.
Re: Python-based compiler achieves orders-of-magnitude speedups
#106Paper here: "Codon: A Compiler for High-Performance Pythonic Applications and DSLs": 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…
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.
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.
Re: Python-based compiler achieves orders-of-magnitude speedups
#107Preface: 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…
> while the Nim compiler is essentially a community hobby project that has made the concept of a "compiled Python" a reality already.
I checked out Nim a few years ago because I have a large Python project that I'd like to move to a compiled language. In my experience, if you get on the forums and do any kind of comparison between Python and Nim, you will quickly get responses of "Nim isn't Python, so quit trying to make it like Python".
I think Nim would have been much more successful if it was more like Python, and if Python compatibility was one of its goals. Just as an example, a subrange a..b in Nim is closed on the right, unlike Python, and a..I'm not saying Nim had to be the perfect Python compiler and compile all Python code unmodified. Based on what I've read, Python is too dynamic for this. But in cases where there was the choice to either be compatible with Python or "do something unique", Nim often takes the unique path, and not always for any good reason IMO.
Re: Python-based compiler achieves orders-of-magnitude speedups
#108Quite 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.
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
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.
Re: Python-based compiler achieves orders-of-magnitude speedups
#109Am 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.
Re: Python-based compiler achieves orders-of-magnitude speedups
#110Can 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…
What is a non-trash programming language?
In general, or specifically in the same niche as Python?
Python has several disjoint domains where it's used. So, for example, when it comes to statistics, then J, R or Julia would all be better than Python. Not ideal, but still a lot better.
When it comes to infrastructure and ops, then Erlang would've been a lot better. Still not ideal because of how existing implementation deals with deployment (too complicated), but that's not a feature of the language, and could be worked on in the same way how OP wants to work on Python compiler.
When it comes to Web... well, I'm not a specialist... and I find everything about Web revolting, so it's hard for me to think about alternatives. On the other hand, there's rarely a language that doesn't come with a Web framework / some tools that allow it to be used to make Web applications. So, just, basically, throw a dart, and wherever it lands it's going to be better than Python with a very high probability.
Python is also used to teach intro to computer science. And there's a lot of problems with this idea. Firstly, I don't believe that intro to CS should be taught by way of learning to program. It should give an overview of what CS is about, give some foundation, basic concepts from important fields... just like intro to math does, for example. But if we still have to have intro to CS the way we do today, then Scheme would be a lot better for this. Assembly is also a good pick, but for a different reason.
Now, to address the "in general" part: I don't believe that languages like Python should be used universally in different domains. What I believe we need is a language like OMeta, which we specialize for the domains we want to program in, so that we can keep language and compiler mechanics separately from syntax of specific domains. Ironically, this was even obvious at the time of ALGOL design, but nobody waited for it to be implemented and went with the quick-and-dirty solution instead.