Are we at this level now? The scheduler performance has nothing to do with the used language. Actually making use of the freedom C provides (while being unsafe) you have the ability to implement whatever complex algorithm you can envision in the most direct way. Moreover scheduling is all about tradeoffs: it's not hard to write a scheduler that is better than a genera purpose one for a specific task. If you like Rust write your code in Rust but the community should stop with this kind of attitude.
What attitude are you referring to? An engineer wanted to play around and see if they could get something to work. Not only did it work, for one task it worked well, so it probably exceeded their initial goal?
I thought that was exactly what we encouraged here on HN?
Antirez, I respect you immensely. I know you know what you are talking about. I do think that there's too much hype around rust.
That said, I also think that we live in a world where a little bit of clickbait or hype-riding is admissible. The economics of the thing make it almost mandatory. I would just acknowledge the hype, nod in disagreement, and move on. At the end o the day this is about someone tinkering with a language they enjoy. Let them have that.
I believe that some hype / over-enthusiasm is acceptable, but I'm a bit more worried when a given community uses it as some kind of organized propaganda, arriving to excesses like saying that writing code in non-safe languages should be considered immoral, and also never admitting that Rust is a compromise in the design space like anything else. So ok for the hype, but sometimes I see some excesses. Anyway this is just my very limited opinion, I don't claim to be right, I just believe my feeling represents some part of people here.
Like you said its fine to promote language on its merit, but using false propaganda to promote it borders fraud and Rust community needs to act together to stop such practices.
Overhype within Rust community is a sign of fear among the community that some simple language (may be zig, nim or something new) might come and pull the rug under their feet. Given it compromise on simplicity in favour of quashing memory safety bugs.
One reason rewrite in Rust is popular because its easier to copy something already done vs doing something original (one recent example came to mind is rewriting gnu coreutils in Rust).
Especially when the hype is added by a third party. This is an article about a hobby project written in a few weeks and yet the headline suggests it is somehow a serious contender for being added to Linux (right now at least. Maybe something grows out of this, most likely not)
>Especially when the hype is added by a third party.
I think this is ( or should have been ) obvious but also an interesting observation. At least it never came across my mind. The Hype driven feedback loop that generate a positive ( so to speak ) hype cycle.
The Rust community has definitely toned down a lot of their evangelism in the past 2 years. After obviously enough people came out to say enough is enough. But the third party continue the trend regardless.
> I would just acknowledge the hype, nod in disagreement, and move on.
Which is exactly what he did, in addition to also acknowledging the pattern of the Rust community using hype to attract attention. He didn't force anything onto anyone, he just expressed his opinion.
But I don't think I've ever seen any other community (except C++, 20 years ago, perhaps?) being so vocal about wanting to rewrite the whole software ecosystem in their language. "Rewrite it in Rust" is basically a catchphrase now.
> But I don't think I've ever seen any other community (except C++, 20 years ago, perhaps?) being so vocal about wanting to rewrite the whole software ecosystem in their language.
True. I suppose the main difference is that nobody (in their right mind) was ever advocating for rewriting fundamental system components such as Linux (the kernel) and all the GNU system utilities in Java/Perl/JavaScript. If they were, then I completely missed them.
I think that's mostly because there hasn't been any new mainstream language with the feature set and compilation model needed to port fundamental system components for a while. I remember lengthy debates about porting just about everything from C to C++ in the Linux world and even C++ was deemed unsuited for many reasons (with which I generally agree).
It turns out that Rust is compelling enough that it makes sense to investigate porting lots of things to it. I don't think anybody knows for sure exactly for which projects Rust is better than C (or C++), but I know that Google has ported many fundamental C++ projects to Rust and they're happy enough that they're continuing this trend.
> ... use of the freedom C provides (while being unsafe) you have the ability to implement whatever complex algorithm you can envision
This is highly misleading. That is not true. At all.
Just take a sample: Do you write OO on C? No, because C is a terrible OO language. Do you write short optimized array-oriented code on C? No, because C is not APL.
People write C how people write C, the way C make them write it.
Moving into other paradigms, you see things differently.
Rust makes a lot of idioms that are inexistent on C viable: Algebraic types alone will shape the way you do algorithms by a lot. Then they push for better errors, then know exactly where things alloc, etc.
Coding in Rust is distinctly different from code in C. It is like the best way you can refactor a codebase: You come for the safety and tooling, you stay because the algorithms write better themselves.
Writing oo style code in c is extremely common. At least where I work we often pass around structs of function pointers to accomplish roughly the same thing a vtable would give you and name methods such as foo_verb for methods that operate on struct foo.
An algebraic data type is just a c union with an auto generated flag and moving some type validation to compile time. Unions used in this manner are quite common in C. I do think the increased ergonomics and safety exist, but only when paired with other features like pattern matching. Selling algebraic data types alone as the major novel feature improvement is a bit misleading and dismissive of existing c features.
I do agree that additional compile safety in rust makes it far easier to confidently refactor without introducing bugs. Accomplishing the same in C requires a lot of unit tests which add maintenance overhead. Python is a more extreme example of that playing out. That all said, I don't think it's necessarily relevant to writing a performant scheduler.
Rust has many strengths and I endorse using it over C any day. That said, the way it's marketed feels misleading and gives experiences c developers bad vibes.
Yes, have a look at GTK, GOBject and parts of Gnome.
> Do you write short optimized array-oriented code on C?
If you want to stay close to C you'd use something like SAC [1] but no, pure C is not an array programming language.
> People write C how people write C, the way C make them write it.
C is sometimes called 'structured assembly' for a reason: it is a toolbox which can be used to construct things the way you see fit. This does mean you need to involve yourself more with certain implementation details since C itself does not force you to use any specific paradigm and as such does not provide you with the basic tenets of those paradigms. If you want to do OO in C you'll have to provide a pointer to the object you're working on in any function call related to that object since C does not assume there to be a 'current object'.
Does this mean C is the most optimal language to do OO programming or array programming? No, clearly not, this is why languages like C++/Java and APL were created. On the other hand it does mean that it is possible to do these things in C and - given the success of Gnome and GTK - doing so can be a viable proposition. The advantage of using C is that it is nearly universally portable, more so than many other languages.
So yes, use of the freedom C provides (while being unsafe) you have the ability to implement whatever complex algorithm you can envision is actually true in that it is possible to do so. You may not want to use C for these purposes but that is irrelevant when considering whether it is possible to do so.
OO and other paradigms are not algorithms. They are particular ways of organizing code. Any algorithm can be implemented with OO, FP, or plain procedural style. Objects can be closures. Loops can be TCO recursion.
So, you're definitely a better programmer than me. That said, there are more programmers at my level and below than at yours. I would not advise anyone to run a Linux scheduler I wrote and tested in C. However, if I wrote and tested one in Rust, I might not feel bad letting people use it.
All this news tells us is that a Rust implementation can compare to a C implementation in this field. As you say, schedulers are all about tradeoffs in the end anyway. This news unlocks us having more options, both C and Rust schedulers, meaning a better experience for the Linux community across a variety of workloads. Thus, I don't see any reason to be defensive about Rust performance being found to be comparable to C here.
> I would not advise anyone to run a Linux scheduler I wrote and tested in C. However, if I wrote and tested one in Rust, I might not feel bad letting people use it.
For something as complex and sensitive as a kernel scheduler, i think "who" wrote the scheduler (as in how much experience writing scheduler), and what software dev. practices (especially how that thing was tested) and far better predictor than just the language used. I would actually go as far as saying that the language used might not even be a predictor at all.
No amount of rust safety would prevent things like dead/locks, quadratic algorithms in weird cases, unreleased resources etc... etc...
> All this news tells us is that a Rust implementation can compare to a C implementation in this field.
That's what the news "implied", but that's not actually what the news says. And i think that's what people are trying to call out.
The dev. implemented a prototype scheduler in rust, and in a very contrive case it does better than "a" C scheduler. The implementation are probably using different algorithm, they probably making different tradeoffs, we have no idea how safe and bug free his implementation his, and not even how safe it's (how much unsafe block is in that thing).
As an exercise to show that rust is a viable language to do kernel development in term of mature tool chain and good integration with kernel API sure. But as tool to compare C vs rust for kernel dev... this is pretty much worthless.
> Are we at this level now? The scheduler performance has nothing to do with the used language.
The whole project is a toy and they’re not trying to hide it. The mention of the language is just a descriptor for the project, not an implication that Rust is faster.
> It's Phoronix, what do you expect? High editorial standards?
It seems that you're implying that their standards aren't high. Is this a general feel of yours or based on some concrete examples ?
I think that Phoronix does a pretty good job. Its free, has some interesting benchmarks, covers technical topics like the Linux kernel, Graphics, Computer Hardware etc. quite well.
Phoronix gets criticized a bit too much. I don't get it -- maybe someone can explain.
Any program can be written in assembly. The purpose of languages is to make writing programs easier. Every useful program written in language A that could also be written in language B or C is a piece of evidence that writing programs in A is easier.
Rust programs are safer than C programs but almost universally more complicated to write compared to C with equivalent high level libraries for data structures and other operations. So I can't see how your argument applies here.
I think you'd need to support your statement that Rust programs are almost universally more complicated to write than C, given equivalent high-level libraries. I'd argue that ADTs, const-by-default, and being expression-based are all pretty simple and straight-forward features that make Rust programs easier to write and reason about without even getting into other higher-level features.
Occasionally managing lifetimes can be a headache, but it's not nearly as often as most people seem to think it is, and is precisely the sort of thing you should be concerned with fully understanding in a C-equivalent anyway.
"with equivalent high level libraries for data structures" is doing a lot of heavy lifting here. Getting and managing those high level libraries and data structures is much easier in Rust. I'd also argue that C's type system needlessly complicates correctly using those high level libraries and data structures compared to their Rust counterparts.
Yes, but the environment for this specific program is the linux kernel, where most of the high level libraries for data structures already exist in C already, and the Rust code is pretty constrained due to the existing limitations. A lot of, what I assume to be, data structure fanciness in Rust comes through non standard crates, and the kernel doesn't allow that as far as I remember.
> Rust programs are safer than C programs but almost universally more complicated to write compared to C with equivalent high level libraries for data structures and other operations.
I'd argue equivalent C programs are usually undercomplicated due to missing safety requirements.
Rust allows for higher stakes in terms of risk/reward while guaranteeing many aspects of safety. I'm not sure for this case if the scheduler would benefit from more complex/risky structures but if it did, that'd be a valid example of Rust making things "easier".
Rust definitely makes some easy things more difficult but on the flip side it arguably makes very difficult things easier (to get right with fewer guinea pigs).
But I agree that the article misrepresents the tweet. The promise is in achieving comparable performance with less effort, not in achieving better performance.
But until you're an experienced Rust programmer, you may frequently hit walls, spending a considerable amount of time trying to implement something that would be trivial in other languages, but requires a lot of contorsion to compile in Rust.
And once it compiles, the way you achieved it may be suboptimal, complicated, buggy, and even unsafe due to logic bugs.
My fairly large projects written in Rust have slowly become unmaintainable. There 's too much code that's just there to work around the borrow checker, and hurt readability. There are memory leaks and dead locks that I've never been able to pinpoint. There are dependencies that I stopped updating a long time ago due to constant breaking API changes. There are "unsafe" and "transmute" keywords because I couldn't figure out how to go through many layers of abstraction just to copy a type that resolves to an integer into another type that resolves to the same integer.
I've been writing Rust code for 10+ years and I still appreciate it for some projects, but I also really enjoy going back to C for the control, flexibility and expressiveness it offers, not to mention better performance. After Rust, it feels like fresh air.
Currently working on a ~120kloc Rust project, which is currently in its third year of existence. It's by far the easiest codebase to maintain I've ever worked in. Our only use of `unsafe` is for the sake of wrapping a C++ library from AWS, which also happens to be where our only use of `transmute` is. I'm able to make sweeping refactors across the entire codebase quickly and without stress. We try to encode logic in the type system where we can and make heavy use of Rust's enums, which makes the compiler able to catch the large majority of issues we might run into.
I think that if you avoid reaching for `unsafe` every time you're frustrated with the type system, you'll have a much better time.
Being annoyed at articles that will have little or no impact on Rust's adoption in Linux are an unusual choice to spend your hard-earned credibility on. Why not simply let people enjoy things (speed, memory-safety, ergonomics)?
I had a similar reaction. It's not rust that makes this faster. It's the algorithm chosen. The rust part is an attention grabbing headline.
However I could see an argument that rust or another higher level language makes it easier for someone to experiment with a new algorithm and iterate faster on those ideas.
It's not just attention grabbing. So far, almost all rust development I've seen has been in drivers. Getting something as core as scheduler replaced is a very interesting event.
I remember replacing the Linux scheduler in an undergraduate class. It's probably changed since those days but I don't think it's that hard. Doing a good job is probably very hard though.
I don't mean that it's particularly hard, but rather that it's using new interfaces which haven't been exposed yet, AFAIK. Scheduler itself + bpf is there from what I've seen, but likely other things too.
Well it's not just about Rust. What we have here is pluggable schedulers leveraging the BPF functionality within the linux kernel. They can be written in watever language you like and they are running in the user space.
eBPF doesn't run in user space in the context of eBPF in the linux kernel. It's verified so that the kernel can be sure it won't loop forever and then gets JIT'ed and run in kernel space.
1. It's interesting that Rust is not just viable in some less important kernel code, but possible in core components.
2. C isn't necessarily the best language for performance. Specifically it's not very good about letting the compiler make assumptions about aliasing. Same reason some CPU-heavy stuff tended to use (ugh) Fortran[1]. Rust is better than C in giving the compiler access to this information for optimization.
But I think you read the article and the post wrong. It's not "ha ha, C suxx", it's just... interesting.
[1] I say "tended", because presumably nowadays it's optimized for GPUs, and I've not been keeping up.
Rewriting something, or writing something new but with past experience always produces a better product. Some people still attribute that to using a new language or framework, or market their new product that way.
But the real driver is the rewrite, not the tools. In that case, what's interesting is the algorithm, not the language it was implemented in.
Reminds me of a famous YouTuber making videos about new tech. Every video starts with "a company based in <name of a country> announced..." or "researchers from <name of a country> found..." - This is annoying. Does the country matter? Do people ignore or mock inventions from countries they don't like, writing on HN that they should be reinvented in another country because other countries suck? Fortunately not. But when it comes to programming languages, they do. And this is equally ridiculous.
This is such a core idea that as you find it really surprising how much it gets overlooked.
IMO, another important aspect of rewrite is that it's usually pretty easy to get 70% of the functionality for 40 % of the work. But as one approaches 100% feature parity , plus handling all the corner cases, the transition from prototype to production ready things equalize pretty fast.
Not to mentioned the unknown unknown that the new language might also bring.
And yet, this is a theme repeated for literally years at this point with Rust.
I'm sorry, but I'm tired of this. It's like being at the skate park watching someone scream at someone else's kid. "oh my god, no you can't do that, that's not the right way to do that! you're going to hurt yourself! oh wait, you pulled off the trick and everyone is cheering! YOURE NOT SUPPOSED TO DO THAT!!!111".
Every single Rust thread is like this. There's at least three in this whole thread already. It's exhausting and weird. And this whole implication of a global conspiracy to push Rust everywhere rather than gee god, maybe people just like it and are effective with it.
"I ended up writing a Linux scheduler in Rust using sched-ext during Christmas break, just for fun. I'm pretty shocked to see that it doesn't just work, but it can even outperform the default Linux scheduler (EEVDF) with certain workloads (i.e., gaming)." — Andrea Righi
I think that pretty clearly summarizes the entire reason for doing this and the excitement that it works and works well.
I don’t understand why he measured the performance gain like he did. Playing a game with a background kernel compile running is a very unique gaming benchmark.
I think it's more because a game is very sensitive to jitter in CPU performance, and can reflect pretty well the responsiveness of the machine with a heavy load in the background. You can replace the game with scrolling a webpage, using slack during compile times, etc. With a game, you get a hard number (FPS) and a very visual indication of how well the load is doing (e.g. stuttering is very noticeable and is a pretty good indicator). So the game is not the point, it's IMHO a visualization of the effectiveness of the scheduler.
It's akin to running any CPU intensive task while playing a game... The hope would be to make the most progress possible without stalling the foreground process.
That being said, my personal experience is that compiling large C projects on my machine with a fast SSD usually uses all cores on almost 100%, which would make it CPU-bound.
Yes, true, you can construct a machine on which any project you care to run is CPU bound. But meanwhile on my pretty beefy servers compiling a kernel from scratch is very much i/o bound. Maybe if I run it twice in a row after all of the caches have been prepped I can get it to be CPU bound but that's cheating, no? With enough RAM almost anything is CPU bound but that's not the normal situation. A typical laptop has 4 or 8 G of RAM and will rapidly consume all that while doing a kernel compile to the point that it's talking to the disk to a degree that it will slow down to where the CPU's are stalled.
> Yes, true, you can construct a machine on which any project you care to run is CPU bound.
You can also construct a machine on which any project you care to run is I/O bound. Which kind of makes your comment "kernel compile is not CPU bound" kind of pointless, no?
That being said, I just downloaded kernel source on my old laptop just to do a sanity check, and it's pinning all 4 of my cores to 100%, so I don't know that to tell you. Perhaps your beefy server (with, I assume, a powerful CPU) is not a typical scenario.
You mean: I've picked my system components in such a way that kernel compiles are not i/o bound. But on an average machine a kernel recompile is very much i/o bound. To the point that people will go out of their way to get large amounts of RAM and very high performance i/o subsystems into their machines. But your average i7/8G run-of-the-mill machine is going to run into the i/o bottleneck pdq. On a 32 or 64G (or even more) RAM box with an NVME drive you probably can get it to be CPU bound. On my 16G laptop with SATA SSD it very much is, the CPU is only utilized about 60% or so.
That's an interesting claim. Do you mean on all hardware it's IO bound? I would think it depends on the disks, concurrency setting for make, memory size, memory speed, and number of availabile cores.
Yes, all of those are important factor. And playing around with those factors (memory, IO speed etc...etc...) it;s easy to construct a system where CPU could be the limiting factor.
But it's still possible to make a claim that in general, most "in the real world" builds are limited by ram size (especially linking), memory bandwidth not really by CPU.
The main reason is really that compilation is not as parallel as one might think.
Compilation used to be much more IO bound in the past. But these days with nvme drives and really aggressive OS file caching (and or ramdisk) IO is less of an issue.
Also note that this changes significantly moving from O2 to O3 where CPU (single thread) performance become more and more important.Same for partial recompilation.
Depends what you're compiling. A kernel for embedded (and therefore a trimmed down set of modules) on a decent machine can easily just be a minute or two. The kernel build system is pretty good at incremental compilation as well.
Thanks for the vote of confidence! We agree, and have had a great time writing it. If you'd like to play around with it, take a look at https://github.com/sched-ext/scx. LWN wrote a nice article on this as well a while back: https://lwn.net/Articles/922405/.
this blew my mind. all people are arguing whether rust is a good fit, a strike force, or if a game is a good benchmark. the whole point of this is that one guy can write a scheduler during winter break and friggin hot swap it at runtime while a compile and a game can run. this is the newsworthy part.
dang it, I want to try it now. and make an article stating I did it in Zig for the clicks!
I would like to stem a little bit of sentiment here.
I can write a toy program that saves files to disk much faster than notepad.exe, but this is a consequence of making fewer decisions and handling fewer edge cases.
It's trivial to make fast software, especially toy software, but they tend not to survive practical applications without becoming as slow or slower than the systems they originally mimic.
I think the important bit here is: a Linux scheduler written "during Christmas break, just for fun", is better that the current one.
it might be the developer sense of "fun", it might be rust, but it is impressive, notheless
> a Linux scheduler written "during Christmas break, just for fun", is better that the current one.
...with certain workloads
i.e. it might be a bit better in a few specific cases, but a bit worse in a large number of more common workloads.
Not that I'm trying to take anything away from the work - getting on par with the well-tuned-over-many-years scheduler for any workloads is an impressive feat. But saying it's "better than the current one" without the caveats made by the original author is oversimplifying to the point of being misleading, I think.
given the video literally showcases how to change the scheduler at runtime while the game is running, it's actually great. imagine Steam loading a new scheduler when a game starts? this way we could all the time run the best scheduler for the workload without issue.
...is better for one specific workload scenario. It's actually baffling that the default scheduler doesn't seem to boost the priority of the 'active window process'.
The linux kernel has no concept of "active window process". It has the concept of "current process", and deciding which process that is, is exactly the job of the scheduler. :P
I'd love to see more focus on this in the Linux scheduler, at least allowing an optional mode for interactive use. It's frustrating to have my entire system occasionally grind to a halt because of compilation or a particularly beefy test suite.
That's what (in)famous kernel dev Con Kolivas[1] was doing up to late noughties. I'm not sure if he's still active in maintaining out of tree schedulers though.
That such a simple 2D game isn't able to reach 60fps under heavy system load just shows that the vanilla scheduler doesn't boost the process associated with the currently active window though?
Shouldn't this be standard on all 'desktop' operating systems, e.g. anything associated with the user gets higher priority than anything else happening on the system? Even the Amiga had such a priority-boosting system back in 1985 (otherwise multitasking wouldn't be of much use on such a slow computer, because pretty much any background task would make the UI unusable).
How would the vanilla scheduler know which process is associated with the currently active window? You're assuming there's more cooperation between the various layers of a linux desktop than I think there really are.
The scheduler doesn't need to know which process is associated with the currently active windows.
Simple heuristics can get you which to "reasonably" guesstimate which process are interactive and which aren't. For example, every X and descendant, or everything waiting on keyboard/controller or any other input.
I think the linux kernel historically did not want to prioritize interactive processes like windows and macos does.
The other thing is of course to reduce the CPU quanta, trading latency for throughput. I think most modern distribution do ship with better quanta for smooth GUI/desktop behavior.
One would think that at least a rewrite-from-scratch effort like Wayland would have come up with a solution.
Unfortunately the same problem also exists on other systems. Visual Studio even had to add a feature "Run build at low process priority" for the system to remain usable during builds:
I mean the end-user can always write the glue required to get the current running window get its process and mark that as the "high priority", but that's still working under the constraints of the regular scheduler.
Hard to answer, but I was interested because I assumed it built on the "recent" work to bring rust into the kernel. Where I haven't read much news about how it is being used except for Asahi Linux.
Somewhat disappointed that it is using eBPF instead, but still interesting to learn that even such fundamental and performance sensitive parts such as the scheduler can be changed.
> For production scenarios, other schedulers are likely to exhibit better performance, as offloading all scheduling decisions to user-space comes with a certain cost.
Aside from possibly increased scheduler latency, there’s the rather larger potential cost of outright deadlocks: what guarantees that the user scheduler task runs at all when it’s needed?
On 60 seconds of skimming the repo, I didn’t spot a specific solution to this problem. I wonder how it was addressed. Or maybe it wasn’t, since this is just an experiment.
At least in one version of the documentation patch, there's mention of a watchdog timeout that unloads the user scheduler if it fails to make forward progress for some period of time.
Correct -- the purpose of the watchdog is to account for buggy schedulers that fail to schedule runnable tasks. scx_rustland has special logic to track the user-space scheduling task, though. If it incorrectly failed to schedule it when it had no more runnable tasks to run, then the watchdog would eventually kick in, boot out scx_rustland, and revert back to EEVDF.
What is the implication here, or what is it trying to say? If it outperforms C, then it obviously has very different implementation details, including algorithms and whatnot. It does not outperform the scheduler because it is written in Rust.
There are absolutely things I'd be comfortable writing in Rust and not in C because I'd very likely mess up the C implementation. Rust encourages and lowers the cost for certain algorithms and implementations.
Whether or not that's the case here, I don't know. I wouldn't expect it to be the case here though.
But even apart from that, the implementation being different doesn't matter much I think? I think it's more about there being a compelling component existing in rust, and less about whether it could be a different language or not.
>There are absolutely things I'd be comfortable writing in Rust and not in C because I'd very likely mess up the C implementation. Rust encourages and lowers the cost for certain algorithms and implementations.
I share your sentiment, but that's not really relevant here. The kernel portion of the scheduler is written in C -- as are all of the other example (and production) schedulers we wrote. The BPF verifier ensures that the program is safe and can't crash the kernel, and we have a watchdog that will boot out a buggy scheduler that fails to schedule tasks in a timely manner.
>But even apart from that, the implementation being different doesn't matter much I think? I think it's more about there being a compelling component existing in rust, and less about whether it could be a different language or not.
An understandable point of confusion, but this is not the case. The fact that the user space portion of scx_rustland is written in rust is anecdotal. We have other schedulers which are entirely contained in the kernel, and others which have rich user space logic written in C. Many of them outperform EEVDF in a lot of different scenarios. By way of example, we're running a C scheduler now for Meta web workloads because it outperforms EEVDF by several percent for both latency and throughput.
> I think it's more about there being a compelling component existing in rust
Isn't the interesting part that there's a scheduler that's way better particularly in this use case? Linux is taking in Rust here and there already, I don't think that alone is interesting and the parent point is that the same thing could have been written in C.
There are compelling reasons to choose Rust, but it's not magically fixing performance by virtue of not being C. In which case, the implementation is the story.
> Linux is taking in Rust here and there already, I don't think that alone is interesting and the parent point is that the same thing could have been written in C.
I'm not sure if you mean "Linux taking in Rust is not interesting" or "This component in Rust (apart from implementation details) is interesting", but I absolutely think both are interesting.
For the first (which you may agree with, IDK), Linux has refused to take C++, etc. as languages.
For the second, my understanding is that the kernel support was kind of a provisional trial integration of Rust, and that no essential components were to be written in Rust. Now an alternate scheduler isn't a an essential component, but it the first thing I've heard of that would get me to compile a rust component for the kernel.
Edit: wait, wait, wait, this is eBPF driven? Does that even need the kernel linux support? This becomes even more interesting to me. Sounds like we could maybe see eBPF filters Go or Nim soon if that's the case.
Nah, the existence of a scheduler that performs some workload better than the generic one isn't very interesting. It's a well known fact that specialized schedulers perform better. It's just that the generic one advanced enough so that it's not worth switching for most people, but that's only after you look at the hassle of managing them.
What is really interesting here is the central piece of the kernel written on Rust, and working perfectly fine.
That is exactly what I meant, thank you. That said, I would like to know the differences in those implementation details as to why it outperforms the default scheduler.
To be clear, this doesn't mean this scheduler itself runs faster.
It means that the scheduler algorithm is better suited for gaming workloads, allocating your hardware more effectively.
Of course, if the scheduler ran much slower so your CPU spends more time on the scheduler than time saved through better resource allocation, then it wouldn't help performance. But that's hopefully not a major factor here.
I read this as a validating use case, showing that real kernel use cases can be written in Rust, without seeming temporary in an unserious language until the real code can be written.
Can the same algorithm be written in C? Sure, but it could also have been written in assembly.
