[HN Gopher] Mapping Python to LLVM
___________________________________________________________________
Mapping Python to LLVM
Author : arshajii
Score : 67 points
Date : 2023-01-09 16:52 UTC (6 hours ago)
(HTM) web link (blog.exaloop.io)
(TXT) w3m dump (blog.exaloop.io)
| maximilianburke wrote:
| I 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.
| julienfr112 wrote:
| kind of like numba, isn't it ?
| debatem1 wrote:
| The type conversion assumptions here are real problematic. "64
| bits ought to be enough for anybody"-style statements ignore
| integers as bitfields, large constants (eg Avogadro's number),
| any kind of math with large intermediate terms, all kinds of
| stuff.
|
| Makes me very suspect about the rest of this project when they
| try to glide past all of these issues with nary a mention.
| [deleted]
| zamadatix wrote:
| > There are many things we took for granted here, like how we
| determine the data types to begin with, or how we put the
| source code in a format that's suitable for code generation.
| These, among other things, will be topics of future posts in
| this series. Stay tuned!
|
| I don't feel they are trying to glide past anything. It's the
| first post in the series about a product in 0.x state, it's
| gotta start somewhere other than perfection and they seem to
| know that.
| maxloh wrote:
| How good is Coden's performance compared to Cyphon and mypyc?
| dragonwriter wrote:
| > int can become an LLVM i64
|
| You can be efficient without sacrificing correctness; using LLVM
| shouldn't mean "throw out arbitrary-precision semantics".
| wyldfire wrote:
| I don't know how codon does this. But I always supposed that
| existing optimized pythons like pypy map integer operations to
| native types and promote them to arbitrary precision when they
| encounter overflow. It's IMO a similar problem to "but what if
| someone decided to overwrite Int.__add__ with some other
| function?" - arguably these are weird/bad things to do but
| AFAIK permitted by the language semantics. So to fix problems
| like these you just make it work for the paranoid case and
| implement optimizations that rely on that not being common.
| When the weird behavior is detected you fall back to the slower
| path.
| edelsohn wrote:
| How does Codon leverage the lessons learned from Unladen Swallow?
| baq wrote:
| Looks like it does it by not being Python, but rather Python-
| ish.
| toxik wrote:
| Codon is very impressive, it feels a lot like Python without
| being slow like Python.
|
| Don't think of it as a Python compiler, it is its own language.
| (Esp. re choice of int == i64, this saves SO MUCH computation for
| the CPU.)
|
| I will say though that I'm not sure where to use it yet, since
| it's too immature for important projects and also aims at the "we
| need a nuclear bomb" level performance.
___________________________________________________________________
(page generated 2023-01-09 23:00 UTC)