101
Seems like a weird headline. AFAIK, the language it's written in has nothing to do with the performance.
this post was submitted on 19 Jan 2024
101 points (94.7% liked)
Linux Gaming
16111 readers
145 users here now
Discussions and news about gaming on the GNU/Linux family of operating systems (including the Steam Deck). Potentially a $HOME away from home for disgruntled /r/linux_gaming denizens of the redditarian demesne.
This page can be subscribed to via RSS.
Original /r/linux_gaming pengwing by uoou.
Resources
WWW:
Discord:
IRC:
Matrix:
Telegram:
founded 2 years ago
MODERATORS
Rust has a cult
Which came first the language or the game? Cause I've read a few headlines that confused me not realizing there was a language named rust.
Language was released 2015 (started in 2006), Game was released 2018,
This is more just an example of Phoronix being Phoronix than rust fanboyism tbf
I wouldn't be surprised if this was essentially just a common result of refactoring code. Rust might help compile to more efficient C than the stuff people write on their own? But my code is always more performant after a refactor. Surely writing this in another language would cause someone to look deeper at the choices being made during development. Even the scheduler might have some technical debt.
The main improvement Rust provides is memory safety. It's very easy to make mistakes in C where you could overrun a buffer or something, introducing unexpected crashing and making it vulnerable to exploitation by malware or whatever. Rust eliminates a whole category of issues with their clever memory management paradigm. The improvements in this schedule probably have more to do with the strategy used than code efficiency.
Didn't we already do that with c++ and c#? Is rust just c++++?
C and Rust are low level languages, suitable for interacting directly with the hardware. C++ might be described as C with some object oriented stuff bolted on, making it excellent for videogame development. C# is a lot more like Java. It's great for line of business apps because it handles the complexity of memory management for you and provides an excellent framework and excellent libraries for a lot of common tasks. But it's not suitable for low level work.
Linux has quite a few schedulers. The performance of this new one is almost certainly a result of different algorithms used, not an effect of refactoring the existing ones, nor the language it's written in.
I don't think I'll dig in to the code just now, but if it turns out to have much practical value, perhaps we'll eventually see an article about the design.
Yeah, a scheduler just decided which processes get CPU time and takes up a very small part of total execution time. So yeah, I wouldn't expect compiler optimizations to matter much.
It's nice that we could see more rust in the kernel beyond drivers.
Though looking at his code/documentation, it seems that the big win here is moreso giving higher time-slice values to applications that identify themselves as "interactive".
This is a similar concept to what I've seen happen in MacOS, where even running unit tests for my work application doesn't bog down the rest of the system. In windows, however, a single heavy process can bring the whole system down to a crawl.
Rust does have the benefit of being 1. safer on memory (though it uses unsafe blocks here) and 2. a lot easier to parse compared to (imo) archaic versions of C. Even this hobby project has some pretty impressive readability compared to some parts of the kernel that I've tried to read for the fun of it.