Rust Infrastructure Pull Request Submitted For Linux 6.1!

[bug77]

In fact in some instances Rust has led to better performance than C for four reasons:

- Rust makes it easier to implement better algorithms
- Rust can perform low level optimisations that are impossible in C
- Rust is generally better at autovectoring than C
- Rust makes it much easier to parallelise the code

Those advantages may or may not apply to the kernel in varying degrees but it's important to keep in mind that C is not inherently an exceptionally efficient language. The supposedly unbeatable performance of C is largely a myth.

And that is the main thing Rust's detractor constantly miss: when a (more or less) menial task get out of your way, that frees you up to think about things that actually matter. Not that memory management and safety don't matter, but they've been done so many times, it's long past due someone took a serious look at automating them.

[jacob]

Ah, the old fallacy. Languages don't have an intrinsic speed(*), so it's nonsense to say "X is faster/as fast as/slower than Y". It's all a property of implementations. You can have a shit C compiler/runtime (hi MSVC), and you can have a shit Rust compiler/runtime.

(*) Of course esoteric programming languages will do whatever. Specifications of common general-purposes programming languages however generally don't say "this has to execute in 17 nanoseconds". At best, they'll mention the scaling characteristic of certain APIs (e.g. C++'s std::map should be logarithmic with #elements -> \infinity).

Languages tend to have an intrinsic speed in many ways. For example Go mandates a tracing GC, which means that memory operations will always incur some overhead compared to equivalent code in C or Rust, or compared to a compiled language that uses simple refcounting instead. Code that revolves heavily around parsing strings will always be slower in C than in Rust or Pascal, because the 0-terminated representation not only makes strlen O(n) as noted previously, but it also means that taking a substring often means performing a heap allocation and copying the contents if you want to be able to use it as a bona fide string (with a final 0), while in Rust you would simply take a slice. Early versions of Fortran passed arrays as parameters to subroutines by value (by copying them on the stack!) which was obviously stupidly inefficient. Etc.

PS: no, I don't care that you "can" roll out your own alternative string representation in C. It's totally pointless because every single existing API and library, down to basic printf(), expects zero terminated strings. Period. Or perhaps should I say \0

[andrei_me]

What a load of crap.

Lol, you are answering the developer of rusticl, the OpenCL implemented in rust, also AFFAIR karolherbst is a Mesa developer, can't remember which driver

[mdedetrich]

Not even that. Fortran has always been faster. Plus C's million dollar mistake with zero terminated strings means that trivial operations like strlen() are O(n) instead of O(1). C is considered fast because its bias towards base+offset addressing was well suited for the PDP11. Later, CPUs' branch predictors and other heuristics were based on stats derived from existing code, that is mostly C. So essentially CPU manufacturers made huge efforts to produce CPUs where C could run well, rather than the other way around.

I don't know the history behind it, but having zero terminated strings is by far one of the stupidest things in C

I find it to be on the worse side. Go in particular compiles nearly instantaneously. Rust is usually similar or slightly better than C++, and not terribly worse than C because of its preprocessor.

Thats because Go does a lot less, in fact one of Go's design goals was to have a fast compiler which actually influenced the design of the language

[mdedetrich]

I am not arguing with trolls who don't actually code themselves, but only have "theoretical pointless discussions" around programming languages...

Everybody doing it for a living will tell you that it's a no brainer to have proper tooling around a language, which includes a good and competent compiler and a competent standard library. We don't want to have to think for 5 hours which of the 100 implementations I have to use to get peak performance. We want to use the language. And e.g. Rusts _huge_ benefit is, that it actually made the package managing part of the language and that third party libs which make sense, get pulled into the stdlib after a controlled process.

Having a standard would make all of that much harder and would actually sabotage it.

If you don't believe me, ask other full time programmers, they'll probably tell you something similar.

Indeed and this isn't even something specific to Rust (full time Scala/Java programmer which also have strong package management + cross OS support).

Also having standard for a language is largely a gimmick unless that standard provides something useful to the table (i.e. a formally verified specification which can guarantee certain properties). C has no such thing, and the main reason a standard in C exists in the first place is due to historical reasons (back then proprietary compilers were a thing where as now its kind of stupid, even having multiple OS implementations of a language is typically rare). I guess you can argue that C's role today is largely delegated to being a high level assembler, but LLVM is doing a better job of that and again, there isn't a LLVM standard either.

[mdedetrich]

Lol, you are answering the developer of rusticl, the OpenCL implemented in rust, also AFFAIR karolherbst is a Mesa developer, can't remember which driver

There is a very strong correlation between being a troll and not actually even using the thing you are talking about while arguing with people that have strong experience in C that use Rust to actually produce something useful.

[jacob]

I don't know the history behind it, but having zero terminated strings is by far one of the stupidest things in C

I can only guess that it was part of the design philosophy to simplify the compiler's codegen to a fault. When you think about it, absolutely EVERY data type that can be used in C (except for floats/doubles) ultimately comes down to a single integer of some size, this includes pointers. That's why C doesn't have proper arrays, only pointers (and you are supposed to just know the length). By the same token a string can only be represented as an "array" of characters, that is a single pointer to the first character. Then they had to come up with an ugly hack to know where the string ends...

I've read an interview with either Kernighan or Ritchie, don't remember which, who said that he considered zero terminated strings the worst mistake he ever did.

[jacob]

Indeed and this isn't even something specific to Rust (full time Scala/Java programmer which also have strong package management + cross OS support).

Also having standard for a language is largely a gimmick unless that standard provides something useful to the table (i.e. a formally verified specification which can guarantee certain properties). C has no such thing, and the main reason a standard in C exists in the first place is due to historical reasons (back then proprietary compilers were a thing where as now its kind of stupid, even having multiple OS implementations of a language is typically rare). I guess you can argue that C's role today is largely delegated to being a high level assembler, but LLVM is doing a better job of that and again, there isn't a LLVM standard either.

IMHO the discussions about standards for languages always miss the point. Standards were important when compilers were proprietary: having a standard was a reasonable protection against lock-in. When the entire language and its implementation are free-as-in-speech, that issue becomes irrelevant. In fact it can even be argued that "defined by implementation" better in that case.

[smitty3268]

Lol, you are answering the developer of rusticl, the OpenCL implemented in rust, also AFFAIR karolherbst is a Mesa developer, can't remember which driver

Nouveau. Although I wouldn't be surprised if Weasel knows that already. He frequently gets into these types of arguments and always insists anyone who disagrees with him is an idiot. I don't think it matters what kind of experience the other person involved has.

[timofonic]

Not for Lnux and Linus Torvalds evidently. It is clearly going to be merged.

I think he has some secret plan to make Rust available outside LLVM world, LTO too I hope too. Just sayin'.