Rust-Based Linux Scheduler Is Faster | Prime Reacts

Whoa whoa whoa I game all the time on Linux

The default scheduler algorithm in Linux is a trade off to be good in a wide range of tasks and situations. I personally worked in the past to hack the Linux kernel/scheduler to be more performant for our specific embedded product. Usually when you optimize some aspects of the system, you end up deteriorating the performance of something else.

An "apples to apples" comparison would be to have the same code written in C rewritten in Rust. If the Linux scheduler algorithm is different between the C and Rust versions then you are not comparing the languages, you are comparing the algorithms.

Gaming is great on Linux. It was my sole dealbreaker when I decided to switch away from Windows and I'm yet to find any issue that's made me go back. Performance is often on par or better and I think a lot of people have no idea how good it's gotten since they've last checked.

I remember my Intro to Operating Systems course at university. And we spent a really long time discussing different scheduling algorithms and their benefits and drawbacks. One of the issues that we discussed constantly about the different algorithms was starvation. Without looking at it I'd say the most likely explanation for the "improved performance" was that it was making choices that would lead to thread starvation more generally.

The aim of the scheduler is not to improve the main task that the user is using, but increasing the efficiency of utilization of resources by going around the system bottlenecks. If the user wants fast framerates, then it should stop the background tasks. What the guy should have done was showing that all resources are being used to their maximum limit, minimizing the effect of the largest bottleneck.

For this one I think you are kind of missing the point: A scheduler is always a tradeoff between - throughput - latency / interactive performance - fairness (no task is ever stalled / suffocated) I could easily write a scheduler (well not easy but ykwim) that runs terraria 10x faster with a compilation in the background: the scheduler that always prioritizes terraria over everything else. Now does the rust scheduler have 2x performance in terraria while compiling a Kernel? Maybe Is it as good at throughput, latency, fairness as the Linux scheduler? Probably not. Also the language of the scheduler has basically nothing to do with the performance because a somewhat decent scheduler maybe runs 0.01% of the time on a system The author also never claimed that it had anything to do with rust

Let me start with I really like Rust, and it's my goto language. The scheduler may be written in Rust, but it works by using eBPF as it's binary format, which is a bit like WASM for kernel and network drivers. If it's faster, its not because it's in Rust, it's because it does something to side step work that it usually done. That may be a good thing, though. I remember Windows CE back in the early 2000s saying basically that if your workload doesn't want to give up CPU time, then you can make it so that it doesn't have to do so. This scheduler, and the eBPF swappable model, could be a very good thing for certain workloads especially on limited hardware.

I once implemented a high throughput scheduler for Linux, in part to learn how Linux scheduling works, and in part because I had an idea to improve total system performance. It worked, it was neat, it _did_ have better performance in its one target domain, and I immediately abandoned it. Why? Because the real world use case for it doesn't really exist. Under CPU constrained loads like compiling the Linux kernel while gaming, the amount of overhead time spent by the scheduler itself is rather trivial. So helping the scheduler run even 100% faster will save you a _tiny_ slice overall. Everything in the demonstration video could easily be replicated with the existing scheduler and some half-baked c-group / sched-idle tuning.

14:29 Bro John Carmack wrote entire games in Assembly back in the day. You saw his interview with Lex Luthor.