Rust-Based Linux Scheduler Is Faster | Prime Reacts

24 thoughts on “Rust-Based Linux Scheduler Is Faster | Prime Reacts”

• Gaming on Tesla infotainment, Steam Deck, Steam on Chromebooks and Steam on Linux PC all use exactly the same Linux runtime.

• I GAME ALL THE TIME ON LINUX, HOLO ISO MF

• 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.

• I've been gaming on Linux for about 17 years now. It used to suck. Now it's decent.

• 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

• Bruh…. SteamOS/Steam Deck is great… good performance almost all my games run

• Thanks to the Steamdeck, gaming on Linux is actually great now 😊

• ThePrimeagen should learn assembly instead of Haskell. Not to write assembly, but to acquire a better understanding of how a processor works (from a software point of view).

• It can also be faster because of eBPF JIT compiler

• Gaming on Linux has gotten easier. However modern Kernel level anti cheat makes it suck again.

• Actually Linux scheduler is weak on some type of workloads and has always been. Back in the days of single core CPUs it was very obvious. Later with multi-core systems it scaled way better. Specifically for gaming type tasks it was very obvious.
  For the same reason Windows does have a setting to prioritize apps or services. It's basically two scheduler modes in windows since forever(win 95/NT).
  That programmer probably created a scheduler that prioritizes foreground processes a bit more and that improves the performance, under load, in that game, like windows does.
  Also comparing some of the features of Rust and C isn't fair. It's true that you could write anything written in Rust in C, but you will have a damn hard time matching some of the emergent properties of Rust code.
  Also "fearless concurrency" in Rust is a bit optimistic. I mean it's fearless, but it's not truly concurrency. You get fearless concurrency in MEAT(Erlang Elixir) big difference.

• красавчик

• Linux works great for gaming! Windows is so broken these days.

• ur gay when it comes to linux and i also think you might be using ubuntu, snapd, or flatpak in your life.

• Maybe we need to do naming for lifetimes

• 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.

• It IS great for gaming. The main obstacle is people like you.

• If proccess_name == terraria {
  resources += 9999999
  }

• 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: http://www.youtube.com/watch?v=o4-CwDo2zpg&t=2100
  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?

• 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).

• Casey is a moron because he can't defend his opinions.

• Never had any issue gaming on Linux. I use Arch btw

• Doesn't Haskell rely on LLVM ? So the argument for same compilers needs to be slightly more precise 😉

• I think that Linux gaming is better than mac?

Comments are closed.