Very well written article. Delves into some details of things like exception handling semantics without going too far in the weeds. Thanks for sharing.
Mapping Python to LLVM
21–30 of 34 posts
Re: Mapping Python to LLVM
#22I recall that Google had a project to compile Python to LLVM (Unladen Swallow @ https://code.google.com/archive/p/unladen-swallow/ ), but work stopped on it a long time ago. If I recall it really wasn't that much faster than CPython given the overhead, but it's been a long time; if it was faster I assume it wouldn't have been abandoned.
I think the main difference is that this doesn’t purport to be a drop in replacement. also, they seem to be doing some multithreading.
Re: Mapping Python to LLVM
#23A major type-incompatibility not mentioned in the linked blog post is this, from[1], * Strings: Codon currently uses ASCII strings unlike Python's unicode strings. Judas priest, after all the effin' grief we went through to learn how to handle Unicode strings in Python 3, and to finally begin to realize their value, you take this step backward? Forget the i64 limits, the lack of native Unicode strings is a flat deal-…
Breaking compatibility from the current spec/functionality of python should be a definite no-no for any implementation. That being said, I can still appreciate that they didn't try to write their own busted unicode implementation since many other ones have contributed to security issues.
I don't understand why you say that. Like, it's gonna cost them in adoption to diverge, they don't need a lecture to understand that, they are doing what meets their needs and sharing it.
Re: Mapping Python to LLVM
#24Have to assign variables to a bit of memory on the stack because SSA??
LLVM has an optimization pass that takes care of that.
Re: Mapping Python to LLVM
#25> How can I use Codon for production or commercial use?
> Please reach out to... to inquire about about a production-use license.
Having "contact us" pricing with several incompatibilities makes this pretty hard to consider in a commercial environment. I wish they had a public pricing structure.
From their faq: https://docs.exaloop.io/codon/general/faq.
Re: Mapping Python to LLVM
#26> How can I use Codon for production or commercial use? > Please reach out to... to inquire about about a production-use license. Having "contact us" pricing with several incompatibilities makes this pretty hard to consider in a commercial environment. I wish they had a public pricing structure. From their faq: https://docs.exaloop.io/codon/general/faq .
I agree, I'm curious enough to try it but not gonna bother if I have to email someone just to get an idea of how much it costs to use in real code.
Re: Mapping Python to LLVM
#27The LinkedIn href is wrong in exaloop.io website
Re: Mapping Python to LLVM
#28A major type-incompatibility not mentioned in the linked blog post is this, from[1], * Strings: Codon currently uses ASCII strings unlike Python's unicode strings. Judas priest, after all the effin' grief we went through to learn how to handle Unicode strings in Python 3, and to finally begin to realize their value, you take this step backward? Forget the i64 limits, the lack of native Unicode strings is a flat deal-…
Breaking compatibility from the current spec/functionality of python should be a definite no-no for any implementation. That being said, I can still appreciate that they didn't try to write their own busted unicode implementation since many other ones have contributed to security issues.
The implementation is optimised for genomics, thats why.
Re: Mapping Python to LLVM
#29How much does this differ from PyPy's RPython in terms of how the language is restricted?
While RPython is a restricted version of python used to build the PyPy python interpreters, the interpreters themselves are not restricted. Any deviation from CPython behavior, intended or not, is considered a bug. So Codon should be compared to the PyPy python interpreter, not to RPython. The advantage to writing the interpreter in RPython rather than C (CPython) or pre-compiling python code to LLVM IR and from there to creating and executable (Codon), is that RPython comes with a metaJIT (which can generate a JIT) and a mark-and-sweep garbage collector for any interpreter built on top of it.
Re: Mapping Python to LLVM
#30I recall that Google had a project to compile Python to LLVM (Unladen Swallow @ https://code.google.com/archive/p/unladen-swallow/ ), but work stopped on it a long time ago. If I recall it really wasn't that much faster than CPython given the overhead, but it's been a long time; if it was faster I assume it wouldn't have been abandoned.
Quite. Unladen Swallow was unfortunately a failure, in part because LLVM at the time was quite buggy, and in part because LLVM wasn't (isn't?) magic enough to speed up a dynamic language.
The blog post here mentions they do their own optimization passes, before handing over to LLVM. I imagine that's pretty important.