>C Is Not a Low-level Language: Your computer is not a fast PDP-11. (2024)

>tests and benchmarks
What drives me nuts about benchmarks is that every time I implement an algorithm in multiple languages...for fun (LeetCode/HackerRank puzzles) or out of curiosity...C beats everything else. It wins even if the algorithm is the same, wins by a wide margin if done "the C way." Tests and benchmarks tell me, for example, that "Java is fast sar", but when I try it, it's dog slow, and that's after I account for the JVM getting to a usable state.

I should clarify: same implementation of an algorithm might use structs in C and objects in OOP languages, but is otherwise the same solution. Naturally if C++ has the exact same code as C then it's going to turn in the same times. "The C way" means the solution is similar but I'm taking advantage of something I can easily do in C

>it applying to C too is the problem, cniles larp a lot when in the end their language isn't special
In C a string is just an array of bytes. In most other languages it's an opaque and immutable type. In C string processing can be orders of magnitude faster. And in fact many high level languages implement their string functions using C under the hood.

See Also

SQLite: Check-in [eedf6bed]

In C an array of any type is simply a contiguous block of memory. If you want something more sophisticated it's up to you to code it. Iterating over the array is simple arithmetic on a pointer, and the CPU's prefetch can easily predict what you'll need next if you're iterating forward. In many higher level languages the default array/list/etc. is actually a complicated, linked structure under the hood. It's great for resizing when programmers don't know (i.e. don't think about) what size they will end up with, but terrible for performance.

In C you can treat a block of memory as an array of any type you like at any time you like. This makes it easy to speed up certain operations just by using a wider type. This is completely foreign to just about every other language. There are situations where C basically lets you use the ALU as if it was a vector unit, which is not an option in most other languages.

C does not have built in complicated types. It's up to you to import or implement them. The source of the "it's a hash problem" copypasta. This at least makes you think about their costs and which is most appropriate. In higher level languages devs blindly use objects, hash maps, lists, dictionaries, etc. without once thinking about their costs because they are there and convenient. If you spent a week watching a C and Java or Python or even C++ dev try to solve the same problem, you would see the C dev making more efficient decisions over and over again.

I could go on. None of this has anything to do with the compiler.

that a developer wouldn't necessarily do even in C++ because it's not proper or 'how you do things', and can't do in something like Python.

Granted I've never included Rust before so maybe it would surprise me. Occasionally C++ surprises me and wins, there are occasions where the compiler knows more from a C++ solution. But as a general rule I see:
C
C++
C#
JavaScript (it's actually decent on performance)
...
Java off in the distance
Python (and I've seen Python beat Java)

Of course someone could argue that my puzzle algorithms are even less valid than a carefully chosen benchmark suite...but it just shocks me that I never see what common benchmarks claim.