Rust-Based Linux Scheduler Is Faster | Prime Reacts
HTML-код
- Опубликовано: 5 сен 2024
- Recorded live on twitch, GET IN
/ theprimeagen
Become a backend engineer. Its my favorite site
boot.dev/?prom...
This is also the best way to support me is to support yourself becoming a better backend engineer.
Reviewed article: www.phoronix.c...
By: Michael Larabel | / michaellarabel
MY MAIN YT CHANNEL: Has well edited engineering videos
/ theprimeagen
Discord
/ discord
Have something for me to read or react to?: / theprimeagenreact
Kinesis Advantage 360: bit.ly/Prime-K...
Hey I am sponsored by Turso, an edge database. I think they are pretty neet. Give them a try for free and if you want you can get a decent amount off (the free tier is the best (better than planetscale or any other))
turso.tech/dee...
Whoa whoa whoa I game all the time on Linux
I actually do, LOL.
I cackle all the time on Linux (at funny videos)
Yeah, LOL, because everyone knows that playing on Linux is super hard, right? Surely it's not just downloading steam launching your games and playing, right? HAhaHa, so hard LOL.
I do for 6 years now. Now with a huge library to choose from. It helps that i prefer single player games
All of the single player games I play work perfectly on Linux and there's literally one that doesn't (only the online part of it). I hope that I will be able to ditch the dual boot setup in the near future and go Linux only
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.
Yes I did the same. Its not "performance" but a tradeoff between "faster task switch" (more interactivity) VS "better throughput" (the compilation in the video would end faster).
There are many schedulers that can switch faster and be more interactive, but there is good reason usually why not to use them.
if (gaming) run_rusty();
Absolutely. Idk how good the Linux scheduler is, but I imagine it’s pretty good at being an all purpose scheduler that is fair to all processes running. So to make the scheduler better at a specific thing, we need to either improve the entire scheduler (seems unlikely tbh), or prioritize something while deprioritizing other processes.
But since hardware is improving at a much slower rate now compared to 10 years ago, it might be worth looking into improving schedulers for systems that only do one thing
@@Ellefsen97 Absolutely - but I must add "which" linux scheduler? Because there are actually pretty many already and the default one is an all-rounder balance between latency and throughput - but people often build custom kernels with specific choice of scheduler for this/that purpose (like interactivity or even more throughput on servers).
Also beware that maxing out interactive switching can lead to worse performance even on desktop and interactive (a'la gaming) use cases: Just think about it: your CPU wastes more percentage of its time doing task switching more often while you actually pretty much just run the game as-is and no other processes... That just makes a lot of wasted clock cycles on the altar of keeping things more interactive. So this actually hurts performance if you would run a lightweight distro with minimal background processes - but of course would perform similar to this video....
Then why not have a scheduler for each different thing and swap between them as needed? Then you can create a task scheduler manager and tell the other schedulers to leave some wiggle room for the manager to be able to do decisions, for games which are both cpu and gpu intensive run a gaming scheduler, keep background tasks semi-frozen and give them a nudge every now and then so they don't crash, or put them to 'sleep'
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.
If Rust forces you to write better code, that is a feature of the language.
@@morkallearns781 Are you saying they have C skill issues?
At the end of the day, the only thing that matteres here is if the algorithm itself is faster. C has the drawback of having to check for nullptrs to check if a function is being called correctly. PURE rust code does not have that drawback. (Although when interoping with C, one still needs to check if the C code passed valid data -> check for nullptr in most cases)
@@morkallearns781 Rust didn't force the author to make a better algorithm. They decided to write an algorithm with worse general performance but better special case performance. The language choice didn't matter affect this.
can agree, if it’s not the same task scheduling algorithm then it’s not really a worthwhile comparison.
It is however a good case study for rewritting/extending the C code with Rust
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.
I see a guy that is currently rewriting x86-64 linux kernel in gitlab, it look great
I remember a rant by linus where he was complaining, in his usual way, about people being careless in writing scheduling algorithms. Scheduling is what's known as a hard problem™. If you doubled perf you almost certainly screwed up royally somewhere else.
I guess it really depends on the system. Gaming computer? Might be a-okay. A server? Certainly not.
@@isodoubIet for some workloads a naive approach that sacrifices performance in other workloads makes a lot of sense though
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.
Ofc, it all depends on the context (real-time requirements, timing constraints, bandwidth usage, energy usage, among others), but the main focus is always efficient utilization of resources.
"If the user wants fast framerates"
As a user, here I would want good enough framerate so I can play the game, *and* background tasks running as fast as possible (without making the game unplayable).
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 played arma 3 on linux because it was a solid 10fps better until they stopped updating the linux branch
Ori and the Will of the Wisps (a Microsoft game) ran better on Linux than on Windows for me.
Which distro are you using for gaming?
I tried Hunt Showdown a few months ago on Pop OS!. I initially went great, albeit some minor glitches in the menu. Then, when I reran the game, Steam decided to reinstall the game. For some reason, it changed the location where games are supposed to live, thus it didn't find the previous installation anymore. I don't have enough free time to fix that kind of issues. I already have limited time to game.
I do hope it'll get better and better, though. Likewise, I'd really like to get rid of Windows.
Same experience after swapping to Linux Mint after Win7 EoL. Basically the only games that are unlikely to run are indie games that have gone the way of making their own engine with post-Win7 versions of .NET. AAA games generally have enough popularity that compatibility gets tweaked into Proton pretty quickly, and indie games that use Unity, Godot or other similarly popular engines work fine out of the box as well. Even if they don't have a native version or an "official Proton support" seal of approval from Valve. And everything that runs at all generally runs well: problems are typically limited to splash screens and pre-rendered, non-engine cutscenes showing a black screen. Performance problems and graphical glitches are surprisingly rare unless your hardware wouldn't be capable of running the game at your chosen quality settings on Windows to begin with. (At least on my AMD card, I've heard it's a bit more hit-and-miss with certain NVIDIA cards and driver versions)
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.
The reason why this is cool, and why you should care, is not that someone wrote one scheduler that performs better in games while compiling a kernel in the background. You should care because this allows you to change your scheduler to value performance of the applications you truly care about more.
CPUs have become incredibly complex, requiring custom made schedulers often to make full use of them, see what Microsoft has been doing on Windows 11 for Intel and AMD CPUs. What this means is we can swap out our scheduler based on our hardware and our workloads. I also heard some talks about swapping the scheduler in real time, which could be really cool for something like Feral's gamemoderun which could swap in a gaming optimized scheduler when an application is ran with gamemoderun.
Everyone's looking at the Rust scheduler because its written in Rust, not the kernel extension that it utilizes to function. What's important here is the kernel feature, not the proof of concept Rust scheduler.
Linux gaming today is totally different than even a year ago. I'm seriously considering switching to Ubuntu full-time. Only a few applications that are not supported while on Linux are pulling it back.
I switched full time to popOS a couple years ago. Steam games all run well, Blizzard games with BNet run but you have to specify dx version in the config (at least I did), and other games are hit or miss. Mostly they work, some even run better on linux than on windows, but you will also run into weird problems especially with online games that are not on steam. I had to do a lot of leg work to get Guild Wars 2 running and I don't think it runs as well as on windows.
Unfortunately Canonical has been making a lot of decisions as of late that's made Ubuntu a very unpleasant experience, in addition to it becoming generally more buggy compared to older releases. My recommendation is either some Ubuntu derivative like Mint, or Fedora. Fedora isn't quite as easy with its lack of encoders and need to setup proprietary repositories, but once that's done its a much more stable and easy experience compared to Ubuntu.
I use Linux full-time for years and re-started gaming recently and it never stopped me from playing AAA games at Ultra definition in 4K through Steam... just need a good GPU (doesn't need to be the top of the line). I don't need Windows for anything for years...
The idea of loading a scheduler at runtime is super cool - I don't think the point was that it's faster, but that it's possible to write a scheduler in a weekend and switch to it at runtime.
Just imagine - you want to play a game, you change the scheduler to one that's best for gaming.
Then, it's time to go work / school and you need longer battery life, so you change to one that's really good for battery life.
Then, you get back home and need to work on something that involves having a ton of applications fighting for CPU time. You switch to a scheduler that's designed to work well in that scenario.
This is something I could 100% see being built-in to desktop environments, or something a game launcher enables when you start a game.
Isn't this a good argument for specialized schedulers though?
Like if what you want to do is play games, load a scheduler that prioritizes game threads for increased performance, for something like SteamOS and the Steam Deck.
Not sure if you would gain much if you don't have a lot of background processes running, but I would be interested in seeing it investigated.
Makes sense to me. If MS can say they have some kind of gaming mode in Windows then I think task specific schedulers that can be enabled via some configuration will be great.
kind of, but could also "man nice" and start from there
@@trifalgarhThere's already gamemode on Linux
@@trifalgarhalso I think the steam deck is already using `gamemode` I think valve developed it (not sure) but you can use it in any game/program
Different scheduler already exist in the linux kernel and they can make a difference for specific workloads. The main difficulty for desktop/gaming machines is that you don't really know enough about the workload to really optimize. The way games behave can differ greatly and what works for one game may not work for another.
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.
Compiling in background is a good approximation for discord and twitch stream.
If you can hot-swap the scheduler such that it runs while a game is executing and then swaps back to the default scheduler when you exit the game (process ends), then I'm not sure it really matters that your "gaming scheduler" is sub-optimal for other use cases.
Yeah if does it's intended job and than Fs off when not needed then it's really great.
to be fair, the Windows scheduler is better than the "fair scheduler" precisely because it is not fair, you don't want a fair scheduler in a desktop that's supposed to run foreground tasks. One day linux kernel will learn about that
What is better than tweaking the Linux scheduler is to pin CPU cores to the exclusive use of the user-mode application, such that these pinned cores are not even being scheduled by the kernel.
Doing this with a back-end networking application (it doesn't use the Linux kernel networking stack either - it is able to reuse some of the Linux network drivers, so may need to explicitly load said driver module before starting said networking app - and the ethernet device needs to be removed from Linux management, of course, and there's some necessary config of hugepages).
A “better scheduler” doesn’t have to be overall. With the number of specific purpose VMs and workloads. Being able to select a workload specific scheduler per kernel instance is a fun prospect.
Did not address eBPF, I think that is the clue. Its not so much about Rust as it is a specific solution reacting to specific events.
lol, he made the game faster and the compilation slower. It'd be trivial to write a schedule that explicitly penalizes compilation and shows favor to game processes.
Isn't it a part of custom kernels anyway? You can find packages for kernels optimized for UX, prioritizing renders and user interaction instead of allocating power to other running processes
Hey, at least Linux gaming is less of a dream compared to Mac gaming 😂
I game all the time on my Mac.
@@midamericanyakuzaGood for you, unfortunately my experience with gaming on Mac has only been sore, especially on ARM 😔
It's been making great progress recently, hopefully it keeps doing so because Windows 11 is straight ass and will probably start getting (even more) expensive
Steambook
"WeRe DePrEcAtInG OpEnGL YoU nEeD to uSe mEtAL"
Gg mac gaming dreamers, it's over
Hey, I'm running a Bitcoin miner, and compiling Rust code (because compiling Rust is stupidly slow, get it), and running a neural network, and running Call of Dutty 16, and cracking nuclear codes in the background, but with this one simple trick, by changing Terraria's process "priority" to realtime or something, I can double Terraria's FPS. Clearly Rust is a better language than C, this is the conclusion of this all.
A scheduler can never make everything faster. Ideally it manages to slice up the available processing resources in a way that doesn't waste too much and keeps interactive workloads responsive without delaying long time tasks too much. It's allways a trade off. What he said is that it's a lot better for gaming. That necessarily means it's worse for throughput based work like compiling but it could be that it is still good enough that it's worth it on a desktop system.
"You wouldn't want Casey doing a UI"... Casey invented immediate-mode GUI's.
The misunderstanding is that most people are focusing on the fact that he used rust expecting the language to be the difference maker. He did not say rust made his scheduler better, and he didn't say his scheduler is a replacement to the Linux scheduler. He just said he made a scheduler in rust which can be used in runtime to make a game perform better compared to the Linux scheduler. An application would be to use it only to run games.
Its not "performance" but a tradeoff between "faster task switch" (more interactivity) VS "better throughput" (the compilation in the video would end faster).
There are many schedulers that can switch faster and be more interactive, but there is good reason usually why not to use them.
EEVDF is also relatively new in Linux so, we'll have to see.
“Gaming on Linux, kind of a pipe dream”
???
I had a dual boot install for a while to game on Windows with the very few games I couldn't get to run on Linux. One day there was only No Man's Sky left, which I didn't play for a year or so.
When I wanted to play it again, I started up Windows, and of course was ~~asked~~ forced to install an update, which failed when it turned out the partition was too small, so it undid the update it had done so far and rebooted, leading to deciding that it had to update, so it got caught in a loop.
So I decided I had enough, forced a shutdown of the computer, started on Linux, deleted the Windows partition, added the freed up space to my home partition, and tried whether No Man's Sky now also ran under Proton on Linux. And behold, it did. That's now… I dunno, at least 3 years ago, probably more like 5.
Only game I can think of right now that I can't get to run is Vermintide. There are so many games that run natively on Linux now, and the vast majority of the rest run perfectly fine under Proton or Wine, and it's getting better every year.
So I'm not sure what world you're living in, but gaming on Linux is far from a pipe dream, it's just everyday reality. I don't just “game all the time” on Linux, I play mostly whatever game catches my fancy on Linux. What the hell more would be necessary for gaming on Linux to not be a pipe dream?
I'm playing all games on Linux. Cyperpunk 2077 - everything, thanks to Valve's proton and Steam Deck. I use Arch btw.
Terraria is locked to 60fps. Since all the calculations are based on the 60fps lock, it looks looks and feels slow under 60.
Something sus about this comparison but I'm hopeful
The demo is not about doubling the framerate of Terraria. It's about the scheduler prioritizing the game to run at 60 fps, even if the CPU is under heavy load from other applications. In both cases he was compiling in the background so that the CPU load was at 100%. In the first example the scheduler did not prioritize the game, so the frame rates dropped to 25-30fps. In the second example the scheduler realized that the user was playing a game, so it prioritized the game by allocating enough CPU resources to run the game as 60fps. That's what this demo is all about.
I literally play games all the time on linux lol. Steam+Proton and lutris+proton would surprise many on how many things it can run.
But why not just use windows...
@@Kerojey forced updates was a sufficient deterrent for me
I have manged to achieve the same performance results by compiling my own version of the kernel. Few tweaks in scheduler and mincraft raised FPS from 15 to 45-50. I'm still using that config for new kernel versions. And no handwritten schedulers, just carefully crafted kernel config before compilation.
Would it be a good idea to let people pick a scheduler in their kernel specific to their needs? If you want a gaming maching you pick another compared to a workstation? And apparently you can swap on the fly if I understand the video correctly, so maybe even whenever you need it?
Theres a whole lot you can change about performance if you're compiling the kernel yourself
Yes you can change process scheduler on the fly just as you can change an IO scheduler on the fly for individual drives. It's pretty interesting thing to know about(at least io schedulers are interesting if you work with storage). Process schedulers and io schedulers also have various parameters you can tweak to change their characteristics to your needs which can be important on very specialized servers
sched-ext is the main takeaway here since a user can apply a new scheduler on the fly, as they go.
You could have a boot scheduler, userspace scheduler, gaming scheduler, a compiler sheduler, anything you want at any time.
Full time linux gamer. The only games I cant run are EA/Blizzard Games and Riot Games, pretty much just cause of their kernel level anticheat. We've come a long way
OK I'm convinced! Rewrite everything in rust!
0:06 Ok i'm gonna be first one to admit it can be pain, but at the same time it's not that bat, be it it heavly depends on games you want to play.... and i'm playing on steam deck which is technically linux but it's not representative.
vsync enabled and fps goes from 58-59 to 60-61 is enough to be seen as 30fps going to 60fps :)
"donald trump is as fast as usain bolt under certain workloads" wins best chat message of the century for me
The point of the demo is he's running many threads (compiling) while running one big game thread (terraria). This could just as well just be the terraria thread getting more cpu time, and so the "demo" proves nothing.
In order to compare them fairly we would also have to get the compile time for the kernel so we would know the detriment.
What we are really interested in is the scheduler overhead, not the performance of individual applications.
Neat! I was looking at my old linix kernel module book from college, and it is old enough that linux still had the O(1) scheduler
This has nothing to do with the language. It just means rando wrote a new scheduler in a random language, and it just prioritized jobs differently than one old, possibly shitty scheduler.
Poor Tim. He only wanted a happy and satisfying life.
Would be interesting to see how fast the scheduler would be in other languages like Nim.
The performance of the scheduler has nothing to do with the language it's written in (unless it's Python maybe)
Funny that @theprimeagen says Casey would be bad at UI. From Wikipedia Casey Muratori developed the technique and coined the term "Single-path Immediate Mode Graphical User Interface" which is what DearImgui uses
Tom needs to write a scheduler for the Linux kernel using JDSL.
Many have praised the use of Rust. It showcased new ideas and results in scheduler optimization. It's important not to forget that algorithms matter more than the language choice; both C and Rust can implement the same ideas
because most modern games need C++ compatibility and most (kernel) drivers run into issues when written in C++, so if you boot into a VM then it may be different. They may have had a major breakthrough in Kernel booting processes
I don't doubt it because it's actually relatively hard for the compiler to optimize C (there are a lot of assumptions the compiler can't make or fails to make regarding aliasing) but the article wasn't too convincing
If you want real world examples of rust outperforming while being secure, see Rustls which beats openssl
There's this great game called Human Resource Machine. It teaches you a stupid simple assembly like language and you literarily build spaghetti code as you build algorithms to solve problems. really cool game. was reminded of this off the "more lines of instructions does not mean slower"
System76 released a Rust-based scheduler in in January 2022 and 2.0 version in May 2023.
Torvalds secretly fuming and cursing the Rustaceans in Swedish
Never had any issue gaming on Linux. I use Arch btw
compilers have been beating humans for quite some time...
Asking what language is faster is like asking which pair of shoes is faster - it completely misses the point. It's not the shoe/language that runs, it's the person/program. More important than the shoe/language itself is whether it FITS the person/program you want to run fast.
This is very impressive, but people taking away that "rewrite the kernel scheduler in rust and gain performance" are wrong.
In fact its probably possible to compile the kernel scheduler as is to get a similar performance profile.
I know youre not saying this, but the clickbait man....
The relevant information would have been how long the compilation now took at the end.
Not immediately trusting "Rust make it moar better" as a conclusion is completely fair and justified.
That said, Rust has a few advantages like for example, when calling a function with a mutable pointer, in C/C++ the function could theoretically perform some math on said pointer and end up modifying the locals on the stack below it.
Rust does not allow it, which means that many memory accesses can be moved around function calls, alleviating some register allocation issues.
The rich and powerful type system allows for elimination of a whole category of correctness bugs which means (pointed out) less defensive coding, letting the "type math" prove that dumb stuff can't happen and not worrying about it.
I've been reminded what I've been thinking of is called a "pointer escape", which is not a problem in Rust.
I assume Prime isn't a 420Gamer69 so he isn't all that aware, but Linux gaming truly is pretty good right now. Steam deck supports a shit ton of games and plays them well. I on my desktop Linux can play most games I want and need with perfect performance and stability, even relatively small and niche ones. The only thing that's really missing are the online games with kernel level anti-cheats.
3:18 When he was swinging that thing it looked way worse with the non-rust approach.
there is a whole science in measuring program performance... this guy never got the memo.
Gaming on Tesla infotainment, Steam Deck, Steam on Chromebooks and Steam on Linux PC all use exactly the same Linux runtime.
I think this is mostly related to different architecture and the mode of scheduling. I don't think Rust has anything to do with the perf gains. Just a crappy old C code.
Theres probably a certain amount of it thats just from the simplicity of noth andling all the edge cases the real scheduler grew to handle over the years
1:50 that is also how Window’s scheduler performs in regards to Terraria 😅
I daily drive Linux for pretty much all of my games, it's a great experience. Hell, The Finals just got an update that makes it work on Linux, which is awesome
Next, sit down together with Tom to finally implement an JDSL-based Linux scheduler.
rust could be faster caused by:
less checks to get safe that ur values are what they should be in very big projects, cause rust handles them native and C handles them thirdparty (devs) and not every dev is a god, even if we all wish so
Look at the old kernel shed code instead.. you will quickly notice what is going on.
Honestly since it can be loaded at runtime, if it can speed up games it would be fine to do it while gaming, then replacing it when not gaming.
12:49, I recently made a benchmark of unrolled loops vs normal on C++: the 1st got almost twice the speed of the conventional way. And due to macros, I made each unrolled algorithm in 2 lines (not even f()s were compiled), vs ~6-10 lines f()s for known loops. 12:55, the reason is because the unrolled code makes it clear, for the compiler, the chance to use parallelism from a special hardware for basic operations. Follow this talk: ruclips.net/video/o4-CwDo2zpg/видео.html
13:05, to C++ I use to code macros for doing things on a safer way, and then I cut them out at once, by changing 1 line and recompiling. Could Rust do the same, by activating/deactivating its safe mode, maybe using its macros?
I don't trust Canonical engineers. I know someone extremely qualified who applied to them for two separate roles, scoring 100% on their assessments both times and being put into the "Top Applicants" pool, but was never given an interview.
I love how people are wanting to make full scientific scheduler comparisons for something a guy wrote over the Christmas holiday for fun 😂
All of the comments about scheduler applies to all schedulers
If have started to switch fully to Linux, even for gaming. Steam on Ubuntu has so far run every game I have thrown at it, even if they don't have official Linux support. The only issue I encountered is that games would sometimes crash immediately at start once or twice, but once it's running it all runs smoothly.
I play Titanfall 2 basically every day on Linux
It can also be faster because of eBPF JIT compiler
This is not about speed of Rust, it is about that is quite easy to make new scheduler in Rust or maybe using Rust compiled to eBpf or maybe dynamicaly generwting eBpf
I think sometimes rust can be really good for shipping something faster than C. The best example is the M1 graphics driver for Linux.
I don't think that video proves much. I regularly run Terraria at the same time as a lot of things. And sometimes when I switch to Terraria, it's not smooth, and other times (even if right after noticing an issue), it runs perfectly well again. So what's seen on the video could be the exact same thing, or similar, and has nothing to do with the scheduler.
I game almost exclusively on Linux (Arch BTW).
That said, while I don't have more or less errors than Widows, I have very different ones that are less straightforward to fix.
Theres also the BORE scheduler doing the same. Its written in C
Gaming on Linux is ok now. I play Minecraft, Dead Cells, League of Legends and some índice games with little to no hassle. The performance is worse than Windows
League of Legends will sadly stop working in 2 months when Riot forces Riot Vanguard to play League. It's a kernel level anti cheat and will never be supported in Linux.
@impersonator4439 yeah, I'm going to stop playing because I don't like to have anti-cheat software on my system, but it sucks for Linux users.
I'm sure people will figure out a way of going around it though.
I think this points out a different concern though. If a game is full screened, it likely should be prioritized in the scheduler. Windows in particular will prioritize games that are full screened. This is likely one of the reasons why windows is better at gaming.
It IS great for gaming. The main obstacle is people like you.
Honestly it looked like the first had a framrate cap at 30 and the second had one at 60. and with how terraria frame skip works it makes it look all cool and basically makes it seem as if the second one is really good.
Steam Deck is great for gaming. The only problem with Linux gaming is anti cheat and games like valorant and lol will not work.
that's good thing since those games are trash, aoe2 and apex work just fine
Manjaro Linux user here: proton almost everytime works out of the box or with a bit tweaking, most of the time u will f*k up about windows bugs and things there are proton bugs, thats reality
not every game works but enough to say the most
my specs: i5-2500k xD, 1050ti 4gb xD (my all day work/gaming/chill maschine baby)
Rewrite the same algorithm in C, get even better performance :)
Are you really coming to Brazil?
The Linux scheduler uses a "completely fair scheduling" policy. I'm wondering if he is using a different scheduling policy which handles the workloads he is doing a bit better.
Doesn't Haskell rely on LLVM ? So the argument for same compilers needs to be slightly more precise ;)
The linux scheduler is a compromise... It doesn't perform the best for everything of course... For example, at my company we have modified the kernel scheduler quite a lot to get better real time scheduler performance & to guarantee sub 1ms latency for 99.9999% of runtime.
as someone who has no clue, i imagine it's difficult to compare schedulers? there are so many different workloads and so many different cpus... just look at how fucking awful the windows scheduler still is with e cores on the latest intel platforms
Whoa whoa whoa I submit PRs to Proton all the time dude.
I was very suprised lately when I tried to run my games on linux and almost all of them run flawlessly :P
Maybe we need to do naming for lifetimes
I'd like to take this opportunity to say that I ported rustc-hash to C just to restore the symmetry.
Even if it'sa bad scheduler overall, you got to admit it would be great to have get better gaming scheduler.
Was this compared to that Linux scheduler that was actually capped at 8 threads?