Codon Compiler For Python Is Fast - but With Some Caveats (usenix.org) 36
For 16 years, Rik Farrow has been an editor for the long-running nonprofit Usenix. He's also been a consultant for 43 years (according to his biography at Usenix.org) — and even wrote the 1988 book Unix System Security: How to Protect Your Data and Prevent Intruders.
Today Farrow stopped by Slashdot to share his thoughts on Codon. rikfarrow writes: Researchers at MIT decided to build a compiler focused on speeding up genomics processing... Recently, they have posted their code on GitHub, and I gave it a test drive.
"Managed" languages produce code for a specific runtime (like JavaScript). Now Farrow's article at Usenix.org argues that Codon produces code "much faster than other managed languages, and in some cases faster than C/C++."
Codon-compiled code is faster because "it's compiled, variables are typed at compile time, and it supports parallel execution." But there's some important caveats: The "version of Python" part is actually an important point: the builders of Codon have built a compiler that accepts a large portion of Python, including all of the most commonly used parts — but not all... Duck typing means that the Codon compiler uses hints found in the source or attempts to deduce them to determine the correct type, and assigns that as a static type. If you wanted to process data where the type is unknown before execution, this may not work for you, although Codon does support a union type that is a possible workaround. In most cases of processing large data sets, the types are known in advance so this is not an issue...
Codon is not the same as Python, in that the developers have not yet implemented all the features you would find in Python 3.10, and this, along with duck typing, will likely cause problems if you just try and compile existing scripts. I quickly ran into problems, as I uncovered unsupported bits of Python, and, by looking at the Issues section of their Github pages, so have other people.
Codon supports a JIT feature, so that instead of attempting to compile complete scripts, you can just add a @codon.jit decorator to functions that you think would benefit from being compiled or executed in parallel, becoming much faster to execute...
Whether your projects will benefit from experimenting with Codon will mean taking the time to read the documentation. Codon is not exactly like Python. For example, there's support for Nvidia GPUs included as well and I ran into a limitation when using a dictionary. I suspect that some potential users will appreciate that Codon takes Python as input and produces executables, making the distribution of code simpler while avoiding disclosure of the source. Codon, with its LLVM backend, also seems like a great solution for people wanting to use Python for embedded projects.
My uses of Python are much simpler: I can process millions of lines of nginx logs in seconds, so a reduction in execution time means little to me. I do think there will be others who can take full advantage of Codon.
Farrow's article also points out that Codon "must be licensed for commercial use, but versions older than three years convert to an Apache license. Non-commercial users are welcome to experiment with Codon."
Today Farrow stopped by Slashdot to share his thoughts on Codon. rikfarrow writes: Researchers at MIT decided to build a compiler focused on speeding up genomics processing... Recently, they have posted their code on GitHub, and I gave it a test drive.
"Managed" languages produce code for a specific runtime (like JavaScript). Now Farrow's article at Usenix.org argues that Codon produces code "much faster than other managed languages, and in some cases faster than C/C++."
Codon-compiled code is faster because "it's compiled, variables are typed at compile time, and it supports parallel execution." But there's some important caveats: The "version of Python" part is actually an important point: the builders of Codon have built a compiler that accepts a large portion of Python, including all of the most commonly used parts — but not all... Duck typing means that the Codon compiler uses hints found in the source or attempts to deduce them to determine the correct type, and assigns that as a static type. If you wanted to process data where the type is unknown before execution, this may not work for you, although Codon does support a union type that is a possible workaround. In most cases of processing large data sets, the types are known in advance so this is not an issue...
Codon is not the same as Python, in that the developers have not yet implemented all the features you would find in Python 3.10, and this, along with duck typing, will likely cause problems if you just try and compile existing scripts. I quickly ran into problems, as I uncovered unsupported bits of Python, and, by looking at the Issues section of their Github pages, so have other people.
Codon supports a JIT feature, so that instead of attempting to compile complete scripts, you can just add a @codon.jit decorator to functions that you think would benefit from being compiled or executed in parallel, becoming much faster to execute...
Whether your projects will benefit from experimenting with Codon will mean taking the time to read the documentation. Codon is not exactly like Python. For example, there's support for Nvidia GPUs included as well and I ran into a limitation when using a dictionary. I suspect that some potential users will appreciate that Codon takes Python as input and produces executables, making the distribution of code simpler while avoiding disclosure of the source. Codon, with its LLVM backend, also seems like a great solution for people wanting to use Python for embedded projects.
My uses of Python are much simpler: I can process millions of lines of nginx logs in seconds, so a reduction in execution time means little to me. I do think there will be others who can take full advantage of Codon.
Farrow's article also points out that Codon "must be licensed for commercial use, but versions older than three years convert to an Apache license. Non-commercial users are welcome to experiment with Codon."
Faster than C? Not credible. (Score:5, Insightful)
This basically means that the C code compared with was not very good. Nothing can really beat well-written C code except in very unusual and artificial circumstances. For example, C does not support the "carry" flag. That can be fixed with a tiny bit of inline assembler. But you can also construct a benchmark around this that makes C slower than a specific compiler that has this support.
Hence whenever some compiler is claimed to be "faster than C in some circumstances", that is an immediate red flag for me because it indicates dishonesty. "On par with well-written C code" is about the maximum that can be claimed and that would require well-written code in whatever language gets compiled as well. Without that caveat, the implication is that this compiler can make badly written code fast and that is just generally not possible.
Re:Faster than C? Not credible. (Score:4, Informative)
The Codon claim of having performance that is "typically on par with (and sometimes better than) that of C/C++" is curiously unsourced.
If we look at similar claims from Mojo [modular.com] -- and no, I'm not going to insert the stupid flame emoji -- they compare Mojo performance with a 16-core processor to scalar (i.e. single-core) C++. I guess that's one way to make your performance look better.
Re: (Score:2)
Possible in, say, 70% of use cases, heck just use java or MS csharp, same improvements with just in time compilers or what not. Nothing new here. As a bonus, you can use language built for that without sacrificing anything since there were built for that right from the start. They do this natively without third party hacks.
Re: (Score:2)
May as well compare to C on an Abacus. That would be about as honest.
There are lies, damned lies and benchmarks.
Faster than C? Credible with a JIT (Score:2, Interesting)
Hence whenever some compiler is claimed to be "faster than C in some circumstances", that is an immediate red flag for me because it indicates dishonesty. "On par with well-written C code" is about the maximum that can be claimed and that would require well-written code in whatever language gets compiled as well.
Another exception: If you're using a JIT compiler, it can use run-time feedback to optimize code to run faster than native C without FDO/PGO.
The Wikipedia PGO page [wikipedia.org] lists Firefox, Java, and Chrome as examples of programs successfully using feedback optimization. For static optimization, you have to develop a sample workload that matches all your important types of load (since some optimizations will be be data-dependent). However Java with a JIT can dynamically adapt and re-optimize if a workload changes.
Re: (Score:1)
That's a lot of nice theory. In theory, monkeys can fly out of my butt, even though I have never observed that in practice.
What is the actual overhead required to gather that runtime information (initially and periodically), to run the JIT, and to check the assumptions made by the JIT compiler, compared to the speedup compared to a straightforward C implementation?
Re: (Score:1)
Zero! Because your JVM is already doing all that. Because it's empirically faster than not doing it.
(ignoring the part about testing against implementations in other languages)
The unconditional claim was that "'faster than C in some circumstances' [...] is an immediate red flag for me because it indicates dishonesty."
It's easy to imagine a program and varied workload where a JIT with PGO and dynamic optimization can beat "a straightforward C implementation" without those features. Given that Java programs a
Re: (Score:2, Insightful)
https://benchmarksgame-team.pa... [debian.net] says Java ranges from "slower than C" to sometimes "slower than Python". That's consistent with the OP, but only "running around the speed" of precompiled code if you squint.
And the earlier AC pointed to Chrome and Firefox as using PGO -- but Wikipedia says they're using that to make their compiled C++ code faster, not for JavaScript or the like. They do optimize JIT'ed code [logrocket.com] based on type and similar information, but that doesn't mean "faster than native": it just means f
Flying monkeys not being seen (Score:2)
Monkeys could fly out your butt, but based on the claim made in a sig, First Post dude/dudette moderated +5 Insighful will never see this.
Re: (Score:2)
Not really. There has to be room for optimization or an optimizing JIT compiler does nothing except waste cycles.
Re:Faster than C? Not credible. (Score:5, Interesting)
Not 100% true, though close enough for practical purposes.
FORTRAN routinely produces faster code because our has much stricter aliasing rules which makes it easier for the compiler to optimize (somewhat possible to mitigate with restrict in C). That's the only exception to the general rule I know, and the people using FORTRAN are too busy doing stuff with it to enter silly language games.
Dictionaries (Score:3)
I can see how JITed Java can asymptotically approach C++ performance with a long enough "warmup." To achieve this, it may be necessary to program in Java as if it were COBOL, that is, make use of what are effectively global variables rather than relying on the garbage collector. Or the escape analysis feature where memory an apparent heap allocation takes place on the stack. But for the most part, Java data is organized as collections of scalar variables ("records") or linear lists ("arrays").
Python m
Re: (Score:2)
I doubt that very much. What is true is that a lot of numeric FORTRAN code is extremely optimized on the code side. Replicating that in C code is essentially impossible because it would require massive effort. But a FORTRAN compiler cannot really do more than a modern C compiler.
Re:Faster than C? Not credible. (Score:5, Interesting)
Nothing can really beat well-written C code except in very unusual and artificial circumstances.
That's simply not true because of the complexity of C's execution model. For the same level of development, on basic numeric code, The best Fortran compilers have always been ahead of C compilers*. The reason for that is that because Fortran doesn't do a bunch of things that C can do and so can afford to do optimizations that C can't do. The narrowest understanding of Python's execution model (with fully static typing and so on) should be somewhere between C and Fortran and so it should be possible to get performance slightly better than C, but only with limitations on the code you can use.
* my knowledge on this is some years old, but I just checked and there are quite a number of 2023 articles, e.g. from climate scientists, that still maintain this. If you tell me that's "artificial and unusual" I'll happily agree to disagree.
Re: (Score:3)
I think this is realistically out of date, and new repeats of the refrain are mostly from a place of something tantamount to superstition.
I see it all the time in 'high performance computing' circles, that something they either didn't understand in the first place, or understood 20 years ago and held on even as things evolved becomes superstition.
At some point C compilers were fairly meh, and it was a popular optimization to hand write some assembly. By about 20 years ago, this was already a bit unlikely t
Re: (Score:3)
Not anymore. C compilers did lack advanced optimization for a long time because the code was pretty good anyways. That has changed. FORTRAN compilers cannot do more than modern C compilers. What is true that there is exceptionally well optimized numeric code in FORTRAN and it is likely practically impossible to get C code on the same quality level. Nothing to do with the compilers though.
Re: (Score:1)
Re: (Score:1)
Re: (Score:2)
That is nonsense. Sorry. If there are some optimizations like this possible in a specific language, all that prevents the same optimization being possible in C is coder skill and insight.
Re: (Score:2)
If there are some optimizations like this possible in a specific language, all that prevents the same optimization being possible in C is coder skill and insight.
This is such a terrible take.
"If CUDA can perform optimizations for running code on a GPU in a massively parallel fashion then C can do it too!"
Sure, you just need a team of 1,000 developers and 8 years and $100 million dollar budget! Easy peasy! Let me know when that report I requested is finished!
Porting functionality from something like JVM is always possible in a C program but the fact is that it doesn't exist so you would have to write it to use it. And when it already exists for free, today, ready to
Re: (Score:1)
This basically means that the C code compared with was not very good. Nothing can really beat well-written C code except in very unusual and artificial circumstances. For example, C does not support the "carry" flag. That can be fixed with a tiny bit of inline assembler. But you can also construct a benchmark around this that makes C slower than a specific compiler that has this support.
Hence whenever some compiler is claimed to be "faster than C in some circumstances", that is an immediate red flag for me because it indicates dishonesty. "On par with well-written C code" is about the maximum that can be claimed and that would require well-written code in whatever language gets compiled as well. Without that caveat, the implication is that this compiler can make badly written code fast and that is just generally not possible.
Yes, do that and you'll end with different kind of unfair: comparing Python code snippet that takes about 5 minutes to write and any noob can do that to painstakingly chiseled, hand-optimized, assembly-inlined, profiled, best possible C code that takes a day to produce, and you need to hire a top-level guru to do that.
Re: (Score:2)
Oh, no argument. In many cases using Python even if significantly slower would be the approach of choice. But the speed claim is just a lie and that makes me highly suspicious about any other claims.
Re: (Score:1)
Re: (Score:2)
"Faster than C code" is an unsubstantiated claim of superiority that lacks detail. These are usually made when that claimed superiority is actually not there.
Re: (Score:2)
is an unsubstantiated claim of superiority that lacks detail.
"I didn't bother reading anything the paper--I conclude it's unknowable."
Or... you could go... this is crazy I know... look at the code and decide. It's in Appendix B. They posted the exact code run in both C++ and their language that was benchmarked. And they succinctly explain why their code is running faster than the well written C++ code (cache misses).
There is absolutely nothing wishy washy about their claims. In classic Slashdot fashion you're just too lazy to read the actual code and are dismissi
Re: (Score:2)
Without that caveat, the implication is that this compiler can make badly written code fast and that is just generally not possible.
Generally it's very possible if your badly written code is in a language that offers automatic parallelization and optimizations that are difficult to achieve in std C or C++.
We have many examples of c language extensions which make c+ext far faster by default than ANSI C. And if you build compiler directives and non-standard declarations in the code to a new "language" and a new "compiler" then you can enshrine those optimizations into the "language" itself.
For example OpenCL is a perfect example of this.
Need for speed (Score:4, Funny)
I always used PyPy for speed and it worked quite well.
Isn't this a dupe? (Score:3)
Weird license, no unicode, pure hype (Score:1)
No thanks
numba is free alternative to this (Score:2)
Speed comparisons like this are overrated (Score:1)
At this point, I feel a bit jaded by the compiler benchmark games. Most "real world" performance issues are usually constrained by I/O, not execution speed. More critically to the "as fast as C/C++" posts, they seem to forget that C has explicit constructs for inline assembly, so in a certain sense, even if you brag about beating out a C compiler, you could also
Re: (Score:1)
More critically to the "as fast as C/C++" posts, they seem to forget that C has explicit constructs for inline assembly, so in a certain sense, even if you brag about beating out a C compiler, you could also make a "C" program that is just as fast, because it would be almost identical down to the object code level.
Geez, and Python can inline C++ code too, via Cython or pybind11 or whatever, so by that token, would you agree "Python is exactly as fast as C++"? If you're inlining assembly you're writing assembly not C/C++.
Re: (Score:1)
As a matter of fact, yes, and that was the exact point I was trying to make. You can pointlessly optimize a program to death in any language.
Slightly mistitled (Score:1)
This is not a "python compiler." As the summary and TFA say, it's a compiler for a significant (and, from the sound if it, useful) subset of python.
Setting aside the licensing issues, I like the JIT option to selectively "compile" some code and leave other code alone.