4 ms·

Spoiler: the title is clickbait and the article actually says that C isn't really slower. The initial C implementation written by the author that was passed of

Spoiler: the title is clickbait and the article actually says that C isn't really slower. The initial C implementation written by the author that was passed off as representative of C was naive and had a couple of performance blockers. The author points out those performance blockers, and once the author gets rid of those blockers and re-tests te conclusion is that C isn't actually slower.

marginalia_nu 4y ago
Performance comparisons like these are always pretty useless. What you're in the end comparing is the two programs, not the two languages. But "this PHP program is faster than that C program" is a lot less of a shocking headline than "PHP is faster than C".
ncmncm 4y ago
Yet, C is still slower afterward. The C++, rewritten correctly (see sibling comment), is substantially faster than the Bolin code.
- flohofwoe 4y ago
  Ignoring calling out into badly implemented external functions (like stdlib stuff), solving the same problem in any statically typed and compiled systems programming language should pretty much result in the same machine code output, any remaining differences are down to the compiler implementation, not the programming language. One of the things that actually can make a difference is different rules for pointer aliasing so that the compiler isn't forced to go through memory in some cases, but as Rust has shown, fixing this on the language level doesn't seem to make all that much of a difference in real world performance.
  - fyrn- 4y ago
    In rust's case part of that is that LLVM is very C optimized. It's not great at taking advantage of the more strict rules of rust yet. It is getting better though.
  - mustache_kimono 4y ago
    > but as Rust has shown, fixing this on the language level doesn't seem to make all that much of a difference in real world performance. AFAIK, for now, Rust's mutable no alias is only used at function parameters, so, for now, its use is pretty limited.
- arinlen 4y ago
  > Yet, C is still slower afterward. If you read the article you'll learn that in the end the author not only states there isn't any practical difference in the results that the author pulled with their ad-hoc test examples but also points out which non-performant choices were intentionally left in the last example that lead to the 40ms difference (which, again, the author states in no uncertain terms is meaningless) I don't know how anyone can look at benchmarks of two ad-hoc tests with one of them being intentionally and openly sub-optimal and from that point automatically jump to conclusions over performance traits of a whole programming language. Crazy stuff.

marginalia_nu 4y ago

Performance comparisons like these are always pretty useless. What you're in the end comparing is the two programs, not the two languages. But "this PHP program is faster than that C program" is a lot less of a shocking headline than "PHP is faster than C".

ncmncm 4y ago

Yet, C is still slower afterward. The C++, rewritten correctly (see sibling comment), is substantially faster than the Bolin code.

flohofwoe 4y ago
Ignoring calling out into badly implemented external functions (like stdlib stuff), solving the same problem in any statically typed and compiled systems programming language should pretty much result in the same machine code output, any remaining differences are down to the compiler implementation, not the programming language. One of the things that actually can make a difference is different rules for pointer aliasing so that the compiler isn't forced to go through memory in some cases, but as Rust has shown, fixing this on the language level doesn't seem to make all that much of a difference in real world performance.
- fyrn- 4y ago
  In rust's case part of that is that LLVM is very C optimized. It's not great at taking advantage of the more strict rules of rust yet. It is getting better though.
- mustache_kimono 4y ago
  > but as Rust has shown, fixing this on the language level doesn't seem to make all that much of a difference in real world performance. AFAIK, for now, Rust's mutable no alias is only used at function parameters, so, for now, its use is pretty limited.
arinlen 4y ago
> Yet, C is still slower afterward. If you read the article you'll learn that in the end the author not only states there isn't any practical difference in the results that the author pulled with their ad-hoc test examples but also points out which non-performant choices were intentionally left in the last example that lead to the 40ms difference (which, again, the author states in no uncertain terms is meaningless) I don't know how anyone can look at benchmarks of two ad-hoc tests with one of them being intentionally and openly sub-optimal and from that point automatically jump to conclusions over performance traits of a whole programming language. Crazy stuff.