3 ms·

Thank you for clarifying! That's helpful. > - those scenarios are mindware (and we just trust that kernel devs can and will recall it as appropriate) Ah, I se

Thank you for clarifying! That's helpful. > - those scenarios are mindware (and we just trust that kernel devs can and will recall it as appropriate) Ah, I see. I don't think they're "mindware" so much as they're good targets for making data-driven decisions about. Unlike C memory safety which no amount of measurement or careful thinking can solve, the relative merits of RAII/direct allocations vs arena allocations can be determined case-by-case through running a profiler and trying out things. Rust doesn't really lock you in to one approach, especially at the scale of an individual device driver. I think there is space here for a more sophisticated critique of Rust, which is that trying out alternative strategies can take some effort and still deliver negative results. For example, I was recently doing some profiling on an application and found that deserializing Cargo's metadata format (and malloc within it) show up a bunch. Out of curiosity, I tried switching the cargo-metadata crate [1] to using zero-copy deserialization. It took a couple hours to do. The end result was around a 15% performance improvement in the deserialization process -- not nothing, but also not hugely impactful, and overshadowed by the act of generating and reading the JSON on Cargo's side. But negative results are still useful. [1] https://crates.io/crates/cargo_metadata https://crates.io/crates/cargo_metadata

perching_aix 2y ago
Thing is, my impression is that running a profiler can get quite convoluted. I'm aware for example of different types of profilers / profiling techniques, but not in detail. I also know that I wouldn't pull out a profiler, unless I was experiencing unacceptable performance, which may not happen on my (or the reviewers') end at all. ... which again rings really similar to the memory management story in C (in my head anyways). You can use tooling, and the tooling does help, but certain tooling only helps in certain scenarios, and if you didn't bother to use the tooling for whatever reason, you're hosed, and you won't find out until potentially much later or even too late. What I'm essentially getting at is that Rust doesn't provide guarantees that'd ensure the correct employment of RAII or arenas (according to both you and the article at least), meaning their pitfalls manifesting exist somewhere on this range from possible to likely, and then depending on who you ask, the answer may be different. The article author appears to be of the opinion that this probability is closer to likely, while you - if I read it correctly - think it is closer to the other end of the spectrum. But another interpretation of the article is that the author is just remarking that it is a possibility now at all, and that that makes it a bad thing, regardless of likelihood. So ultimately, my point was to try and get engagement on this idea specifically rather than debating the likelihood itself, especially considering I stand no chance at appropriately gauging that likelihood myself.
- sunshowers 2y ago
  Thanks for your response. > I also know that I wouldn't pull out a profiler, unless I was experiencing unacceptable performance, which may not happen on my (or the reviewers') end at all. At some level it doesn't matter in that case, right? We only have a finite amount of time in the world to do things, and if it's fast enough then time is better spent elsewhere. For a GPU driver, I would imagine that unacceptable performance would be visible quite quickly in p99+ frame times, which the gaming community has figured out are important (they call them "1% lows"). My general philosophy having written Rust for a long time (and before that, C, Python and a bunch of other languages) is to nail correctness first, don't do anything too egregious performance-wise (so try and avoid quadratic or worse algorithms), then worry about performance only to the extent that you can measure average and outlier performance. RAII really, really helps in getting correctness right. (Rust also helps with performance. Idiomatic Rust tends to be quite fast due to aggressive inlining, especially with PGO.) > ... which again rings really similar to the memory management story in C (in my head anyways). I think where I differ is that profilers are a fairly mature and well-understood technology. You can even put profiles of Linux or macOS programs directly into a web browser profiler view, and get a really nice idea of where time is being spent (e.g. [1]). By the way, try out samply or a similar tool some time, it's really easy to use. I just don't think it's possible to get there with any amount of tooling on top of C, especially with existing codebases -- the language is just not rich enough to support the kinds of annotations required for a sound static analysis ("sound" here means all memory safety bugs are in code not otherwise marked unsafe). So yes, they look formally similar, but the difference in practice is enormous. [1] https://github.com/mstange/samply https://github.com/mstange/samply
  - cozzyd 2y ago
    Aggressive inlining is exactly what confuses most profilers in my (limited) experience.

perching_aix 2y ago

Thing is, my impression is that running a profiler can get quite convoluted. I'm aware for example of different types of profilers / profiling techniques, but not in detail. I also know that I wouldn't pull out a profiler, unless I was experiencing unacceptable performance, which may not happen on my (or the reviewers') end at all. ... which again rings really similar to the memory management story in C (in my head anyways). You can use tooling, and the tooling does help, but certain tooling only helps in certain scenarios, and if you didn't bother to use the tooling for whatever reason, you're hosed, and you won't find out until potentially much later or even too late. What I'm essentially getting at is that Rust doesn't provide guarantees that'd ensure the correct employment of RAII or arenas (according to both you and the article at least), meaning their pitfalls manifesting exist somewhere on this range from possible to likely, and then depending on who you ask, the answer may be different. The article author appears to be of the opinion that this probability is closer to likely, while you - if I read it correctly - think it is closer to the other end of the spectrum. But another interpretation of the article is that the author is just remarking that it is a possibility now at all, and that that makes it a bad thing, regardless of likelihood. So ultimately, my point was to try and get engagement on this idea specifically rather than debating the likelihood itself, especially considering I stand no chance at appropriately gauging that likelihood myself.

sunshowers 2y ago
Thanks for your response. > I also know that I wouldn't pull out a profiler, unless I was experiencing unacceptable performance, which may not happen on my (or the reviewers') end at all. At some level it doesn't matter in that case, right? We only have a finite amount of time in the world to do things, and if it's fast enough then time is better spent elsewhere. For a GPU driver, I would imagine that unacceptable performance would be visible quite quickly in p99+ frame times, which the gaming community has figured out are important (they call them "1% lows"). My general philosophy having written Rust for a long time (and before that, C, Python and a bunch of other languages) is to nail correctness first, don't do anything too egregious performance-wise (so try and avoid quadratic or worse algorithms), then worry about performance only to the extent that you can measure average and outlier performance. RAII really, really helps in getting correctness right. (Rust also helps with performance. Idiomatic Rust tends to be quite fast due to aggressive inlining, especially with PGO.) > ... which again rings really similar to the memory management story in C (in my head anyways). I think where I differ is that profilers are a fairly mature and well-understood technology. You can even put profiles of Linux or macOS programs directly into a web browser profiler view, and get a really nice idea of where time is being spent (e.g. [1]). By the way, try out samply or a similar tool some time, it's really easy to use. I just don't think it's possible to get there with any amount of tooling on top of C, especially with existing codebases -- the language is just not rich enough to support the kinds of annotations required for a sound static analysis ("sound" here means all memory safety bugs are in code not otherwise marked unsafe). So yes, they look formally similar, but the difference in practice is enormous. [1] https://github.com/mstange/samply https://github.com/mstange/samply
- cozzyd 2y ago
  Aggressive inlining is exactly what confuses most profilers in my (limited) experience.