• Donate
  • Log In
Home
  • About
    • About
      • About Us
      • Our Board of Directors
      • Board Meeting Minutes
      • Board Elections
      • Updates & Announcements
      • Our Staff
      • Governance & Financials
      • Lifetime Achievement Award
  • Events
    • Events
      • Upcoming
      • Past
      • Conference FAQ
      • Conference Policies
      • Code of Conduct
      • Calls for Papers
      • Author Resources
      • Grant Opportunities
      • Best Papers
      • Test of Time Awards
  • Join & Support
    • Join & Support
      • Become a Member
      • Ways to Give
      • Our Supporters
      • Student Opportunities
      • Sponsorship Opportunities
  • Archive
    • Archive
      • Proceedings
      • Multimedia
      • ;login: Archive
      • Short Topics in System Administration Series
      • Journal of Education in System Administration (JESA)
      • Journal of Election Technology and Systems (JETS)
      • Computing Systems Journal
  • Search
Join the conversation
Back to ;login: Online

Codon: Python Compiler Update

March 10, 2025
Musings
Authors: 
Rik Farrow
Article shepherded by: 
Rik Farrow

I first wrote about Codon back in April 2023 in ;login:. At the time, I was excited about the attempt to create a compiler for Python that could run programs much faster than the Python interpreter. Recently, the founders of Codon sent me a pointer to a blog post with updates to their project that I found important, in some ways, exciting. 

When I tried Codon before, I struggled to get a simple script that I use to summarize ;login: downloads to compile. This time around, Codon had none of the problems I encountered the first time around. I attribute this to work done by Codon committers to improve the compiler's ability to convert Python scripts into the intermediate language they then present to an LLVM backend. Not that my script seemed to benefit from being compiled by Codon, taking about as long to run. But my script doesn't do much more than fill up an associative array,  sum the keys, then print the sorted totals as output.

In their blog post, the authors provide charts showing the improvement of Codon over regular Python when running the NPBench NumPy benchmarks. The geometric mean of speedups is modest, 2.4x, but the maximum is crazy, at 900x. The reason for this is that the Codon team has ported NumPy, a Python library, directly into Codon.

I assumed that the values shown in the chart were correct rather than trying to run the benchmarks myself. I learned a long time ago that attempting to duplicate someone else's benchmark results can be fool's errand: the people who created the hardware or software know much more about how to make it run fast. But I did want to try out a simple Python script that the blog's authors claimed could be speeded up 300x when using Codon-NumPy (in the Loops section of their blog):

import numpy as np
import time

a = np.empty((300, 300, 300), dtype=np.float32)
t0 = time.time()

for i in range(300):
for j in range(300):
for k in range(300):
a[i, j, k] = i + j + k

t1 = time.time()
print(a.mean())
print('time:', t1 - t0)

A simple, nested loop, using NumPy for creating the array object.

When I first tried this on my modest Debian on x86 desktop, I didn't see much performance improvement.

rik@nuke:~/C/Codon$ python3 loop.py
448.50006
time: 4.611926078796387
rik@nuke:~/C/Codon$ codon build loop.py
rik@nuke:~/C/Codon$ ./loop
448.5
time: 2.58449
rik@nuke:~/C/Codon$

Using Codon seemed to cut execution time about in half...

I contacted Ariya Shajii, CEO of Exaloop, and he replied that I had forgotten to include the -release flag—something that's not mentioned in the blog post, so I really didn't forget about it. When I include -release, I do see a 115x improvement, and the size of the executable is much smaller. Apparently, without the -release flag, the regular NumPy library gets included instead of the Codon-NumPy, something I could guess because the size of the binary without -release is much larger and contains strings that appear to be hooks from Codon into NumPy.

rik@nuke:~/C/Codon$ codon build -release loop.py
rik@nuke:~/C/Codon$ ./loop
448.5
time: 0.0398803
rik@nuke:~/C/Codon$ ls -l loop*
-rwxrwxr-x 1 rik rik 16224 Mar 7 14:35 loop
-rwxrwxr-x 1 rik rik 652688 Mar 5 18:07 loop-no
-rw-rw-r-- 1 rik rik 267 Mar 5 18:06 loop.py
rik@nuke:~/C/Codon$

Remembering to include the -release flag has dramatic results: 115x speedup and a much smaller binary (loop-no is the executable without using -release)

It's really important that you use -release when using Codon NumPy. I suggested that they make this the default. 

There's also support for using GPUs in Codon NumPy via decorators, as well as telling Codon how many threads you want to use in a loop.

Apache 2 License

That's two improvements, one in usability and another in performance that's a very big win for anyone using NumPy in Python scripts. As Python behaves like it is single-threaded because of the global interpreter lock (GIL), having Codon's ability to execute portions of loops in paralell is a big win, just as it is having compiled rather than interpreted code. Note that Codon does not currently run on Windows, just Linux and MacOS.

The other big news is that Exaloop, the company that is behind Codon, has changed their license to Apache 2,  one of the most liberal Open Source licenses. For example, commercial use, and derivations of Codon, are now permitted without licensing.

The bottom line is simple: if you are using Python to process large amounts of data using NumPy, you really want to start using Codon. More trivial uses, like my own routine processing of weblogs, really don't benefit much from compiled Python. On the other hand, if you are constantly spinning up lamdas that run Python code, I imagine that starting up a compiled script will be much faster and certainly cheaper than invoking a Python interpreter and have it process a script for every lambda instance.

Article Categories: 
Cloud
Programming
Linux
Last updated March 10, 2025
Authors: 

Rik Farrow has been a consultant for 44 years. He has written two books, as well as worked as the technical editor for a Unix magazine and for two editions of a popular operating system book. He also taught Unix system administration and Internet security during the 90s and noughts internationally, and worked as a volunteer for USENIX program and steering committees. Rik has been the editor of ;login: since 2005.

[email protected]
  • Log in to post comments
USENIX logo
  • Contact USENIX
  • Privacy Policy

© USENIX 2025
EIN 13-3055038

Website designed and built by Giant Rabbit LLC
Powered by Backdrop CMS

We need contributions from individuals like you.

USENIX conferences directly influence the development of computing systems and products used worldwide. Contribute today to support this vital work for the next 50 years.

Secure the Future of USENIX

Donate
Close