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

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

github.com

Post reply on HN
Print view View original

101–110 of 184 posts

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

#101

Post by throwaway894345 »

joshmaker wrote: post #95
jnxx wrote: post #93

Earlier quoted context omitted.

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

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”.

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

#102

Post by querez »

mangecoeur wrote: post #97
joshmaker wrote: post #95

Earlier quoted context omitted.

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

I have also been using python a long time and i honestly can’t remember a time i used mixed type list.

In my code this comes up often, e.g. when I use tuples instead of namedtuple or a dataclass.

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

#103

Post by miohtama »

jnxx wrote: post #91

Just out of curiosity: Why is it possible to compile Common Lisp Code (or Scheme, or Clojure) to high-performance native or jit-compiled code, but not Python? It is said that "Python is too dynamic", but is not everything in Lisp dynamic, too? And none of these languages is less powerful than Lisp, lack Unicode support, or whatever, so this can't be the reason.

It’s because Python object attributes can change any time, as they are accessed dynamically. Nothing can be inlined easily. The object structure is pointer heavy.

Here is some old 2014 post:

http://jakevdp.github.io/blog/2014/05/09/why-python-is-slow/

As other commenters pointed out, some of these Python features, which are unused 99,99% time, could be sacrified for additional speedup by breaking backwards compatibility.

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

#105

Post by terhechte »

joshmaker wrote: post #95
jnxx wrote: post #93

Earlier quoted context omitted.

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

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

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

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

#106

Post by bastawhiz »

querez wrote: post #102
mangecoeur wrote: post #97

Earlier quoted context omitted.

I have also been using python a long time and i honestly can’t remember a time i used mixed type list.

In my code this comes up often, e.g. when I use tuples instead of namedtuple or a dataclass.

Tuples aren't lists though. Tuples are really just structs with indexes instead of names.

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

#107

Post by camdenreslink »

harvie wrote: 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.

No need to be afraid. The Python C extension API makes it very hard to make a JIT work well because of how it is implemented. C extensions are also part of why Python is so popular in the first place. If everybody wrote pure Python (like they write pure JavaScript), then the reference implementation would probably look like Pypy.

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

#108

Post by tasty_freeze »

sambeau wrote: post #48

Who would create a language that only has ASCII strings in this day and age?

Here is the quote of the thing you are referring to:

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

Note the word "currently." Implementing this while also tracking the constantly evolving Python language through its various versions is a lot of work. They apparently prioritizing other things over this particular aspect.

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

#109

Post by hathawsh »

jnxx wrote: post #91

Just out of curiosity: Why is it possible to compile Common Lisp Code (or Scheme, or Clojure) to high-performance native or jit-compiled code, but not Python? It is said that "Python is too dynamic", but is not everything in Lisp dynamic, too? And none of these languages is less powerful than Lisp, lack Unicode support, or whatever, so this can't be the reason.

The demand for compiled Python hasn't been as high as the demand for other languages, so the number of people who have worked on it is much smaller than the number who have built JITs for ECMAScript and others. Python has long been fast enough for many things, and where it isn't, it's easy to call C code from CPython.

Python does have lesser-used dynamic capabilities that probably don't exist in Common Lisp. Those capabilities make it difficult to optimize arbitrary valid Python code, but most people who need a Python compiler would be happy to make adjustments.

Post reply on HN