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.
Parent
twitter
facebook
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
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.
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
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.
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
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.
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++."
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
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++.
