However, such an approach has previously not really worked for C++ with LLVM offload. Why would it work for Rust?
They're very different languages, with different semantics. Without reading more than the synopsis of the paper, they're 100% leveraging the substructural type system and will have a really tight requirement for you to use a certain kind of Rust code at the CPU/GPU boundary.
With C++ the last time, the problem was that there was no MLIR and it's dialects. So, the lowering could not take advantage of any vendor specific features like CUDA graphs and co-operative groups. That has apparently now change with MLIR being a possibility, but with C++, it is still in the experimental phase with CIR not finalized yet, even though people are working quiet hard on it.
With Rust, I am not sure if Rust lowers to MLIR, but if it does, then things should work otherwise not. However, knowing that all GPU vendors are working very hard on CIR and lowering to MLIR, and seeing how much time it is taking them, I would be surprised (pleasantly so) if Rust --> MLIR --> Backend would be faster.
Nvidia has started experimenting with Native Rust so it is still a possibility but still a pleasantly surprising one.
Unfortunately, the Rust description itself is inconsistent. It claims to be "sufficiently fast by default", yet "sufficiently fast" depends entirely on the requirements of a specific user project. And then it also plans to provide options that do not guarantee memory safety when the default speed is insufficient. It is already common for Rust projects to sprinkle memory unsafe code around when performance is needed.
It claims to be "sufficiently fast by default", yet "sufficiently fast" depends entirely on the requirements of a specific user project.
I think that's why the "by default" is there; the goal is to offer a safe/convenient API that performs well enough that by default you don't need to reach beyond said safe/convenient API. And if you happen to be in a situation where the default performance of the safe/convenient APIs is insufficient, more advanced APIs will be provided.
It's a mirror of Rust's general design goals, if anything.
But it still depends on the requirements of the specific user project, whether the default is sufficiently fast, ESL. It is still entirely inconsistent. Basic logic 101, clear as day. Why do you even try to contest this?
It's a mirror of Rust's general design goals, if anything.
Do you claim that "it's a mirror of Rust's general design goals, if anything" to be forced into memory unsafe, extra-difficult Rust code being required, when the going already gets tough regarding performance requirements? That is not a great design goal, and it is not conducive to memory safety nor high quality software.
You needn't use your real name, of course, but for HN to be a community, users need some identity for other users to relate to. Otherwise we may as well have no usernames and no community, and that would be a different kind of forum. https://hn.algolia.com/?sort=byDate&dateRange=all&type=comme...
But it still depends on the requirements of the specific user project, whether the default is sufficiently fast
I mean, "by default" means "by default", not "in all cases". Situations that the default doesn't address are not inconsistent with the existence of a default; it's just that said situations are expected to be a relative minority.
Perhaps a more concrete example would help: say the API the devs come up with is sufficiently fast enough for 99 common use cases and not fast enough for 1 uncommon one. I don't think it'd be inconsistent to call said API "sufficiently fast by default" since "sufficiently fast" is an accurate description of the API for "normal" use (i.e., that's the "default" state).
Do you claim that "it's a mirror of Rust's general design goals, if anything" to be forced into memory unsafe, extra-difficult Rust code being required, when the going already gets tough regarding performance requirements?
No, I think that's a rather... imaginative interpretation of what I said.
I wonder if they're looking to achieve easy speedups. I can see lots of value enabling performance gains where normally people wouldn't bother because it's too much effort. I don't think this will take away work from those who hand-optimise their kernels and scheduling, this is to enable GPU acceleration for those, who otherwise wouldn't.
Comments
They're very different languages, with different semantics. Without reading more than the synopsis of the paper, they're 100% leveraging the substructural type system and will have a really tight requirement for you to use a certain kind of Rust code at the CPU/GPU boundary.
To answer my own question apparently,
With C++ the last time, the problem was that there was no MLIR and it's dialects. So, the lowering could not take advantage of any vendor specific features like CUDA graphs and co-operative groups. That has apparently now change with MLIR being a possibility, but with C++, it is still in the experimental phase with CIR not finalized yet, even though people are working quiet hard on it.
With Rust, I am not sure if Rust lowers to MLIR, but if it does, then things should work otherwise not. However, knowing that all GPU vendors are working very hard on CIR and lowering to MLIR, and seeing how much time it is taking them, I would be surprised (pleasantly so) if Rust --> MLIR --> Backend would be faster.
Nvidia has started experimenting with Native Rust so it is still a possibility but still a pleasantly surprising one.
Unfortunately, the Rust description itself is inconsistent. It claims to be "sufficiently fast by default", yet "sufficiently fast" depends entirely on the requirements of a specific user project. And then it also plans to provide options that do not guarantee memory safety when the default speed is insufficient. It is already common for Rust projects to sprinkle memory unsafe code around when performance is needed.
I think that's why the "by default" is there; the goal is to offer a safe/convenient API that performs well enough that by default you don't need to reach beyond said safe/convenient API. And if you happen to be in a situation where the default performance of the safe/convenient APIs is insufficient, more advanced APIs will be provided.
It's a mirror of Rust's general design goals, if anything.
But it still depends on the requirements of the specific user project, whether the default is sufficiently fast, ESL. It is still entirely inconsistent. Basic logic 101, clear as day. Why do you even try to contest this?
Do you claim that "it's a mirror of Rust's general design goals, if anything" to be forced into memory unsafe, extra-difficult Rust code being required, when the going already gets tough regarding performance requirements? That is not a great design goal, and it is not conducive to memory safety nor high quality software.
Could you please stop creating accounts for every few comments you post? We ban accounts that do that. This is in the site guidelines: https://news.ycombinator.com/newsguidelines.html.
You needn't use your real name, of course, but for HN to be a community, users need some identity for other users to relate to. Otherwise we may as well have no usernames and no community, and that would be a different kind of forum. https://hn.algolia.com/?sort=byDate&dateRange=all&type=comme...
I mean, "by default" means "by default", not "in all cases". Situations that the default doesn't address are not inconsistent with the existence of a default; it's just that said situations are expected to be a relative minority.
Perhaps a more concrete example would help: say the API the devs come up with is sufficiently fast enough for 99 common use cases and not fast enough for 1 uncommon one. I don't think it'd be inconsistent to call said API "sufficiently fast by default" since "sufficiently fast" is an accurate description of the API for "normal" use (i.e., that's the "default" state).
No, I think that's a rather... imaginative interpretation of what I said.
I wonder if they're looking to achieve easy speedups. I can see lots of value enabling performance gains where normally people wouldn't bother because it's too much effort. I don't think this will take away work from those who hand-optimise their kernels and scheduling, this is to enable GPU acceleration for those, who otherwise wouldn't.