4 ms·

The gpu driver for Apple silicon is Rust and the author stated it would have been much more difficult to implement in C. It isn't upstreamed yet. """ Normally

by dmm 1y ago

The gpu driver for Apple silicon is Rust and the author stated it would have been much more difficult to implement in C. It isn't upstreamed yet. """ Normally, when you write a brand new kernel driver as complicated as this one, trying to go from simple demo apps to a full desktop with multiple apps using the GPU concurrently ends up triggering all sorts of race conditions, memory leaks, use-after-free issues, and all kinds of badness. But all that just… didn’t happen! I only had to fix a few logic bugs and one issue in the core of the memory management code, and then everything else just worked stably! Rust is truly magical! Its safety features mean that the design of the driver is guaranteed to be thread-safe and memory-safe as long as there are no issues in the few unsafe sections. It really guides you towards not just safe but good design. """ https://asahilinux.org/2022/11/tales-of-the-m1-gpu/ https://asahilinux.org/2022/11/tales-of-the-m1-gpu/ > the whole thing seems kinda cute but like, shouldn't this experiment in programming language co-development be taking place somewhere other than the source tree for the world's most important piece of software? Torvalds seems to disagree with you.

remix2000 1y ago
Rustlang doesn't aim to address race conditions. Sounds to me like overly "cautious" inefficient code you can write in any language. Think using `std::shared_ptr` for everything in C++, perchance…?
- tobz1000 1y ago
  The comment probably refers to data races over memory access, which are prevented by usage of `Send` and `Sync` traits, rather than more general race conditions.
  - remix2000 1y ago
    I see, but that's not the point of my comment. I don't know rustlang, perhaps I could address that if someone translated the rust-specific parlance to more generally accepted terms.
    - jdub 1y ago
      a data race is specific kind of race condition; it's not rust parlance, but that specificity comes up a lot in rust discussions because that's part of the value
      - remix2000 1y ago
        I meant the trait send sync things. I just thought it was obvious, since Rust is not the only language susceptible to data races.
        masklinn 1y ago
        > since Rust is not the only language susceptible to data races. The point is rather that it’s not. The “trait send sync things” specify whether a value of the type is allowed to be respectively move or borrowed across thread boundaries.
    - deleted 1y ago
      [deleted]
    - Dr_Emann 1y ago
      Thats kinda the problem, there are concepts in rust that don't have equivalents in other common languages. In this case, rust's type system models data-race-safety: it prevents data races at compile time in a way unlike what you can do in c or c++. It will prevent getting mutable access (with a compile time error) to a value across threads unless that access is syncronized (atomics, locks, etc)
      - remix2000 1y ago
        And from what I can see, rustlang mutability is also a type system construct? I.e. it assumes that all other code is Rust for the purpose of those checks?
        gpm 1y ago
        > rustlang mutability is also a type system construct? Yes > I.e. it assumes that all other code is Rust for the purpose of those checks? Not exactly, it merely assumes that you upheld the documented invariants when you wrote code to call/be-called-from other languages. For example that if I have a `extern "C" fn foo(x: &mut i32)` that - x points to a properly aligned properly allocated i32 (not to null, not to the middle of un-unallocated page somewhere) - The only way that memory will be accessed for the duration of the call to `foo` is via `x`. Which is to say that other parts of the system won't be writing to `x` or making assumptions about what value is stored in its memory until the function call returns (rust is, in principle, permitted to store some temporary value in `x`s memory even if the code never touches x beyond being passed it. So long as when `foo` returns the memory contains what it is supposed to). Note that this implies that a pointer to the same memory isn't also being passed to rust some other way (e.g. through a static which doesn't have a locked lock around it) - foo will be called via the standard "C" calling convention (on x86_64 linux this for instance means that the stack pointer must be 2-byte aligned. Which is the type of constraint that is very easy to violate from assembly and next to impossible to violate from C code). That it's up to the programmer to verify the invariants is why FFI code is considered "unsafe" in rust - programmer error can result in unsoundness. But if you, the programmer, are confident you have upheld the invariants you still get the guarantees about the broader system. Rust is generally all about local reasoning. It doesn't actually care very much what the rest of the system is, so long as it called us following the agreed upon contract. It just has a much more explicit definition of what that contract is then C.
- lowbloodsugar 1y ago
  Heh. This is such a C++ thing to say: “I want to do the right thing, but then my code is slow.” I know, I used to write video games in C++. So I feel your pain. I can only tell you: open your mind. Is Rust just a fad? The latest cool new shiny, espoused only by amateurs who don’t have a real job? Or is it something radically different? Go dig into Rust. Compile it down to assembly and see what it generates. Get frustrated by the borrow checker rules until you have the epiphany. Write some unsafe code and learn what “unsafe” really means. Form your own opinion.
giancarlostoro 1y ago
I was just going to say, I think its hard to argue against it since it is the only way to run the GPU on the M1 / M2 Macs.
William_BB 1y ago
What does rust have to do with thread safety and race conditions? Is rust going to synchronize shared memory access for me? Speaking seriously, they surely meant data races, right? If so, what's preventing me from using C++ atomics to achieve the same thing?
- Aurornis 1y ago
  > What does rust have to do with thread safety and race conditions? Is rust going to synchronize shared memory access for me? Rust’s strict ownership model enforces more correct handling of data that is shared or sent across threads. > Speaking seriously, they surely meant data races, right? If so, what's preventing me from using C++ atomics to achieve the same thing? C++ is not used in the Linux kernel. You can write safe code in C++ or C if everything is attended to carefully and no mistakes are made by you or future maintainers who modify code. The benefit of Rust is that the compiler enforces it at a language level so you don’t have to rely on everyone touching the code avoiding mistakes or the disallowed behavior.
- Lvl999Noob 1y ago
  Rust's design eliminates data races completely. It also makes it much easier to write thread safe code from the start. Race conditions are possible but generally less of a thing compared to C++ (at least that's what I think). Nothing is preventing you from writing correct C++ code. Rust is strictly less powerful (in terms of possible programs) than C++. The problem with C++ is that the easiest way to do anything is often the wrong way to do it. You might not even realize you are sharing a variable across threads and that it needs to be atomic.
- tialaramex 1y ago
  > What does rust have to do with thread safety [...] ? Rust inherently models this idea. Read about Rust's "Send" and "Sync" marker traits. e.g. https://doc.rust-lang.org/std/marker/trait.Send.html https://doc.rust-lang.org/std/marker/trait.Send.html > Is rust going to synchronize shared memory access for me? Much better than that. (safe) Rust is going to complain that you can't write the unsynchronized nonsense you were probably going to write, shortcutting the step where in production everything gets corrupted and you spend six months trying to reproduce and debug your mistake...
a-dub 1y ago
> Torvalds seems to disagree with you. i don't really care for mindless appeals to authority. make your own arguments and defend them or don't bother. this gpu driver looks pretty cool though. looks like there's much more to the rust compatibility layer in the asahi tree and it is pretty cool that they were able to ship so quickly. i'd be curious how kernel rust compares to user space rust with respect to bloat. (user rust is pretty bad in that regard, imo)
- 15155 1y ago
  > i don't really care for mindless appeals to authority. This isn't an appeal to just any authority, but the authority that defines Linux and is its namesake.
  - a-dub 1y ago
    [flagged]
    - EGG_CREAM 1y ago
      It’s very intellectually lazy of you not to be curious about why the creator and decades long, knowledgeable guardian of Linux has the opposite opinion as you, all because you read the Wikipedia about logical fallacies one time.
    - mynameisash 1y ago
      Also the guy that created "the world's most important piece of software", as you put it. Appealing to the authority on the exact thing you raised concern about is the single most important authority one can cite.
      - lesuorac 1y ago
        Eh? Surely it's better to cite the authority's reasons as to why they think this way than just to cite the authority itself ... It's not like there's a lack of times he's talked about rust. Just link his commentary similar to linking ashai linux.

by dmm 1y ago

remix2000 1y ago

Rustlang doesn't aim to address race conditions. Sounds to me like overly "cautious" inefficient code you can write in any language. Think using `std::shared_ptr` for everything in C++, perchance…?

tobz1000 1y ago
The comment probably refers to data races over memory access, which are prevented by usage of `Send` and `Sync` traits, rather than more general race conditions.
- remix2000 1y ago
  I see, but that's not the point of my comment. I don't know rustlang, perhaps I could address that if someone translated the rust-specific parlance to more generally accepted terms.
  - jdub 1y ago
    a data race is specific kind of race condition; it's not rust parlance, but that specificity comes up a lot in rust discussions because that's part of the value
    - remix2000 1y ago
      I meant the trait send sync things. I just thought it was obvious, since Rust is not the only language susceptible to data races.
      - masklinn 1y ago
        > since Rust is not the only language susceptible to data races. The point is rather that it’s not. The “trait send sync things” specify whether a value of the type is allowed to be respectively move or borrowed across thread boundaries.
  - deleted 1y ago
    [deleted]
  - Dr_Emann 1y ago
    Thats kinda the problem, there are concepts in rust that don't have equivalents in other common languages. In this case, rust's type system models data-race-safety: it prevents data races at compile time in a way unlike what you can do in c or c++. It will prevent getting mutable access (with a compile time error) to a value across threads unless that access is syncronized (atomics, locks, etc)
    - remix2000 1y ago
      And from what I can see, rustlang mutability is also a type system construct? I.e. it assumes that all other code is Rust for the purpose of those checks?
      - gpm 1y ago
        > rustlang mutability is also a type system construct? Yes > I.e. it assumes that all other code is Rust for the purpose of those checks? Not exactly, it merely assumes that you upheld the documented invariants when you wrote code to call/be-called-from other languages. For example that if I have a `extern "C" fn foo(x: &mut i32)` that - x points to a properly aligned properly allocated i32 (not to null, not to the middle of un-unallocated page somewhere) - The only way that memory will be accessed for the duration of the call to `foo` is via `x`. Which is to say that other parts of the system won't be writing to `x` or making assumptions about what value is stored in its memory until the function call returns (rust is, in principle, permitted to store some temporary value in `x`s memory even if the code never touches x beyond being passed it. So long as when `foo` returns the memory contains what it is supposed to). Note that this implies that a pointer to the same memory isn't also being passed to rust some other way (e.g. through a static which doesn't have a locked lock around it) - foo will be called via the standard "C" calling convention (on x86_64 linux this for instance means that the stack pointer must be 2-byte aligned. Which is the type of constraint that is very easy to violate from assembly and next to impossible to violate from C code). That it's up to the programmer to verify the invariants is why FFI code is considered "unsafe" in rust - programmer error can result in unsoundness. But if you, the programmer, are confident you have upheld the invariants you still get the guarantees about the broader system. Rust is generally all about local reasoning. It doesn't actually care very much what the rest of the system is, so long as it called us following the agreed upon contract. It just has a much more explicit definition of what that contract is then C.
lowbloodsugar 1y ago
Heh. This is such a C++ thing to say: “I want to do the right thing, but then my code is slow.” I know, I used to write video games in C++. So I feel your pain. I can only tell you: open your mind. Is Rust just a fad? The latest cool new shiny, espoused only by amateurs who don’t have a real job? Or is it something radically different? Go dig into Rust. Compile it down to assembly and see what it generates. Get frustrated by the borrow checker rules until you have the epiphany. Write some unsafe code and learn what “unsafe” really means. Form your own opinion.

giancarlostoro 1y ago

I was just going to say, I think its hard to argue against it since it is the only way to run the GPU on the M1 / M2 Macs.

William_BB 1y ago

What does rust have to do with thread safety and race conditions? Is rust going to synchronize shared memory access for me? Speaking seriously, they surely meant data races, right? If so, what's preventing me from using C++ atomics to achieve the same thing?

Aurornis 1y ago
> What does rust have to do with thread safety and race conditions? Is rust going to synchronize shared memory access for me? Rust’s strict ownership model enforces more correct handling of data that is shared or sent across threads. > Speaking seriously, they surely meant data races, right? If so, what's preventing me from using C++ atomics to achieve the same thing? C++ is not used in the Linux kernel. You can write safe code in C++ or C if everything is attended to carefully and no mistakes are made by you or future maintainers who modify code. The benefit of Rust is that the compiler enforces it at a language level so you don’t have to rely on everyone touching the code avoiding mistakes or the disallowed behavior.
Lvl999Noob 1y ago
Rust's design eliminates data races completely. It also makes it much easier to write thread safe code from the start. Race conditions are possible but generally less of a thing compared to C++ (at least that's what I think). Nothing is preventing you from writing correct C++ code. Rust is strictly less powerful (in terms of possible programs) than C++. The problem with C++ is that the easiest way to do anything is often the wrong way to do it. You might not even realize you are sharing a variable across threads and that it needs to be atomic.
tialaramex 1y ago
> What does rust have to do with thread safety [...] ? Rust inherently models this idea. Read about Rust's "Send" and "Sync" marker traits. e.g. https://doc.rust-lang.org/std/marker/trait.Send.html https://doc.rust-lang.org/std/marker/trait.Send.html > Is rust going to synchronize shared memory access for me? Much better than that. (safe) Rust is going to complain that you can't write the unsynchronized nonsense you were probably going to write, shortcutting the step where in production everything gets corrupted and you spend six months trying to reproduce and debug your mistake...

a-dub 1y ago

> Torvalds seems to disagree with you. i don't really care for mindless appeals to authority. make your own arguments and defend them or don't bother. this gpu driver looks pretty cool though. looks like there's much more to the rust compatibility layer in the asahi tree and it is pretty cool that they were able to ship so quickly. i'd be curious how kernel rust compares to user space rust with respect to bloat. (user rust is pretty bad in that regard, imo)

15155 1y ago
> i don't really care for mindless appeals to authority. This isn't an appeal to just any authority, but the authority that defines Linux and is its namesake.
- a-dub 1y ago
  [flagged]
  - EGG_CREAM 1y ago
    It’s very intellectually lazy of you not to be curious about why the creator and decades long, knowledgeable guardian of Linux has the opposite opinion as you, all because you read the Wikipedia about logical fallacies one time.
  - mynameisash 1y ago
    Also the guy that created "the world's most important piece of software", as you put it. Appealing to the authority on the exact thing you raised concern about is the single most important authority one can cite.
    - lesuorac 1y ago
      Eh? Surely it's better to cite the authority's reasons as to why they think this way than just to cite the authority itself ... It's not like there's a lack of times he's talked about rust. Just link his commentary similar to linking ashai linux.