- cross-posted to:
- hackernews@derp.foo
- cross-posted to:
- hackernews@derp.foo
tl;dr large gaming performance over stock CPU scheduler when there is a heavy CPU task running in background
Obviously, they only tested one game and it may not apply everywhere or hurt performance/latency in some cases.
One thing I wasn’t aware of is that sched-ext/ePBF supports changing CPU schedulers on-the-fly, which takes away one of the downsides of third-party schedulers. I.e. you can use the stock scheduler most of the time, but then switch to a third party scheduler for specific workloads. So less of a downside risk.
Finally, none of this is merged yet (including sched-ext) so it’s out of reach if you are just using the stock kernel.
You must log in or # to comment.
Seems like a weird headline. AFAIK, the language it’s written in has nothing to do with the performance.
Rust has a cult
This is more just an example of Phoronix being Phoronix than rust fanboyism tbf
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,
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.
deleted by creator
sched-ext is the proof of concept. It has a demo video if you follow the link to the mailing list in the article showing it improving performance in games that are normally CPU bottlenecked when the CPU is given a heavy background task.
It’s scheduler improvements though, so it’s not really a measurable improvement (or at least not easily measurable) to performance as a whole but it can result is a more responsive system under load.
