5 ms·
The difference in performance between existing systems languages is greater than 1%. This is just not a big deal. People will not choose their systems language
by eloff 4y ago
The difference in performance between existing systems languages is greater than 1%. This is just not a big deal. People will not choose their systems language based on a 1% performance difference. It's so far down the list of considerations that it's a total non-issue.
- WalterBright 4y agoWould Linus accept a language for core Linux work that came with a 1% penalty?
- diffxx 4y agoThis question is impossible to answer in a vacuum. What if the language made developers 90% more productive or 90% less likely to introduce a memory bug or offered 3x faster compiler times? A 1% runtime performance hit would be well worth it if that were the case. Perhaps with the extra time available, developers could find better algorithms/ways of expressing their programs that would ultimately lead to faster runtime performance on average even with the 1% hit in certain microbenchmarks.
- darksaints 4y agoHe certainly hasn't accepted D as a language for core Linux work, despite the benefits without any supposed performance tradeoffs. And he uses GCC for compilation, despite the existence of specialized compilers that offer better runtime performance.
- WalterBright 4y agoWould Linus accept a C compiler that replaced malloc/free with a GC? It's only 1%.
- darksaints 4y agoNo, but not because of performance. Malloc/free is required for deterministic runtime behavior. A GC would take that away. Would Linus accept a language that is more than 1% slower than optimal? Yes, he already does. It's called C. C is slower than optimal assembly. He chose C because it is easier to write large systems in a higher level language, and it is far easier to write cross platform code in.
- pjmlp 4y agoThat is a common mistake, malloc()/free() aren't deterministic, specially in threaded code, heaviliy loaded system, ISO C doesn't even provide guarantees of how deterministic they should come back to the caller across C implementations.
- cozzyd 4y agoSure but you control when you call them.
- WalterBright 4y agoIn D you also control when to call the GC.
- pjmlp 4y agoIf you call them explicitly, you control the call. There is no control over the duration, or what third party code is doing with them.
- deleted 4y ago[deleted]
- arcticbull 4y agoI think the larger issue for Linux would be lack of determinism and memory bloat due to the presence of a collector.
- eloff 4y agoHe just did, it's called Rust. And if someone invented a language 5% faster than C. He'd still use C. If someone had invented a language faster than C when he started working on Linux, he would still have chosen C. He didn't pick it because it was the fastest (and it likely wasn't back then - C compilers have come a long way.)
- int_19h 4y agoThe whole point of Rust is to not require runtime checks by pushing safety to the type system; why would it be slower than C?
- slashdev 4y agoBecause practice is not the same as theory. It's both faster and slower than C, depending on the program, but overall slower. The answer to why is deeply complex and varies on a case-by-case basis. Rust is far more complex than C, so some language features compile down to a LOT more IR (intermediate representation) than C, and LLVM is left to try and make the best of it. Many problems in compilers are NP-complete, and the compiler will use heuristics and other techniques to get an approximately good enough answer. Like register allocation. The more complex the starting state, the less well that tends to work out. But there's other things too, Rust has bounds checks for example, while C often does not. C has null-terminated strings, while Rust strings store a length. Rust doesn't have aliasing, but doesn't yet (last I checked anyway) optimize for that. It will one day though. This is just touching on an extremely nuanced and complex subject. But C is typically faster than Rust, and will likely stay that way.