10 ms·

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)

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.

electricant 3y ago
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.
- SpaceNugget 3y ago
  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. There are some user space BPF vms like https://github.com/iovisor/ubpf https://github.com/iovisor/ubpf and Solana.
knorker 3y ago
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.
Aurornis 3y ago
> 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.
- underdeserver 3y ago
  "Promising results for gaming performance" is not the kind of phrasing you use for toy projects though.
  - loeg 3y ago
    It's Phoronix, what do you expect? High editorial standards? Phoronix is the one overhyping this toy project, not the developer.
    - underdeserver 3y ago
      Never heard of them before ¯\_(ツ)_/¯
      - loeg 3y ago
        It's a long-running one-man show that is quick to publish sensational, sometimes inaccurate recaps of emails from mailing lists.
    - sidkshatriya 3y ago
      > 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.
    - jedisct1 3y ago
bluejekyll 3y ago
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?
Kinrany 3y ago
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.
- antirez 3y ago
  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.
  - baq 3y ago
    > 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.
  - jamincan 3y ago
    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.
  - deleted 3y ago
    [deleted]
  - reyqn 3y ago
    Maybe for an experienced C programmer, but not everyone is one.
otikik 3y ago
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.
- rcxdude 3y ago
  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)
  - ksec 3y ago
    >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.
- jacquesm 3y ago
  Only if it doesn't harm your cause, which it does.
  - iknowstuff 3y ago
    What do you think their cause is?
- bheadmaster 3y ago
  > 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.
mamcx 3y ago
> ... 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.
- the_third_wave 3y ago
  > Do you write OO on C? 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. [1] https://www.sac-home.org/index https://www.sac-home.org/index
jedisct1 3y ago
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.
- soulbadguy 3y ago
  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.
pseudocomposer 3y ago
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.
- soulbadguy 3y ago
  > 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.
k8svet 3y ago
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. Clearly, "George Soros funds Rust advocacy" /s
asveikau 3y ago
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.
- viraptor 3y ago
  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.
  - asveikau 3y ago
    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.
    - viraptor 3y ago
      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.
      - asveikau 3y ago
        But isn't exposing a C interface to Rust very easy? In either direction...
        viraptor 3y ago
        1:1, calling the original functions - sure. Building a good usable interface - that's harder.
deleted 3y ago
[deleted]
binary132 3y ago
The Rust thing here is a bit of a distraction, you can target BPF with C too.
ot 3y ago
> The scheduler performance has nothing to do with the used language. This is correct, but I don't think the article is trying to make any claim about the language being relevant for performance. What I believe the author is showcasing is two things: - sched_ext allows to write schedulers that outperform a default general-purpose scheduler on certain workloads (performance) - Since a sched_ext scheduler is a userland process, it can be implemented in any language. The author likes Rust and they used Rust (ergonomics) The headline compresses both things in one sentence, and this can create some confusion about what they intend to convey.

electricant 3y ago

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.

SpaceNugget 3y ago
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. There are some user space BPF vms like https://github.com/iovisor/ubpf https://github.com/iovisor/ubpf and Solana.

knorker 3y ago

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.

Aurornis 3y ago

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

underdeserver 3y ago
"Promising results for gaming performance" is not the kind of phrasing you use for toy projects though.
- loeg 3y ago
  It's Phoronix, what do you expect? High editorial standards? Phoronix is the one overhyping this toy project, not the developer.
  - underdeserver 3y ago
    Never heard of them before ¯\_(ツ)_/¯
    - loeg 3y ago
      It's a long-running one-man show that is quick to publish sensational, sometimes inaccurate recaps of emails from mailing lists.
  - sidkshatriya 3y ago
    > 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.
  - jedisct1 3y ago

bluejekyll 3y ago

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?

Kinrany 3y ago

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.

antirez 3y ago
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.
- baq 3y ago
  > 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.
- jamincan 3y ago
  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.
- deleted 3y ago
  [deleted]
- reyqn 3y ago
  Maybe for an experienced C programmer, but not everyone is one.

otikik 3y ago

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.

rcxdude 3y ago
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)
- ksec 3y ago
  >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.
jacquesm 3y ago
Only if it doesn't harm your cause, which it does.
- iknowstuff 3y ago
  What do you think their cause is?
bheadmaster 3y ago
> 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.

mamcx 3y ago

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

the_third_wave 3y ago
> Do you write OO on C? 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. [1] https://www.sac-home.org/index https://www.sac-home.org/index

jedisct1 3y ago

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.

soulbadguy 3y ago
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.

pseudocomposer 3y ago

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.

soulbadguy 3y ago
> 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.

k8svet 3y ago

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. Clearly, "George Soros funds Rust advocacy" /s

asveikau 3y ago

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.

viraptor 3y ago
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.
- asveikau 3y ago
  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.
  - viraptor 3y ago
    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.
    - asveikau 3y ago
      But isn't exposing a C interface to Rust very easy? In either direction...
      - viraptor 3y ago
        1:1, calling the original functions - sure. Building a good usable interface - that's harder.

deleted 3y ago

[deleted]

binary132 3y ago

The Rust thing here is a bit of a distraction, you can target BPF with C too.

ot 3y ago

> The scheduler performance has nothing to do with the used language. This is correct, but I don't think the article is trying to make any claim about the language being relevant for performance. What I believe the author is showcasing is two things: - sched_ext allows to write schedulers that outperform a default general-purpose scheduler on certain workloads (performance) - Since a sched_ext scheduler is a userland process, it can be implemented in any language. The author likes Rust and they used Rust (ergonomics) The headline compresses both things in one sentence, and this can create some confusion about what they intend to convey.