6 ms·

> This module is under active development. Once upstream, it should allow Rust developers to run Rust code on GPUs. We aim to develop a rusty GPU programming in

> This module is under active development. Once upstream, it should allow Rust developers to run Rust code on GPUs. We aim to develop a rusty GPU programming interface, which is safe, convenient and sufficiently fast by default. This includes automatic data movement to and from the GPU, in a efficient way. We will (later) also offer more advanced, possibly unsafe, interfaces which allow a higher degree of control. I really appreciate the work and the effort that went into this. However, such an approach has previously not really worked for C++ with LLVM offload. Why would it work for Rust?

aw1621107 1mo ago
> However, such an approach has previously not really worked for C++ with LLVM offload. Why would it work for Rust? I think that will depend on the exact reason(s) C++ with LLVM offload didn't work out? If Rust differs from C++ in a way that addresses pain points/failure modes/etc. from the C++ attempt, for instance, then perhaps it isn't unreasonable to think Rust could succeed where C++ didn't (c.f., Mozilla's pre-Rust attempts to parallelize Firefox's CSS styling engine). Inversely, if Rust doesn't do things differently in the right way perhaps one might expect the effort to also not work out. Or maybe the problems are entirely non-technical and things could work out in either language.
- erupti 1mo ago
  [flagged]
ux266478 1mo ago
> 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.
- erupti 1mo ago
  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.
  - aw1621107 1mo ago
    > 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.
    - erupti2 1mo ago
      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.
      - aw1621107 1mo ago
        > 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.
winningChild 1mo ago
[dead]
winningChild 1mo ago
[dead]
boxed 1mo ago
Seems to work out well for Mojo, so I'd guess it's more an issue with C++.
- nylonstrung 1mo ago
  Well mojo handles it by introducing an additional step of lowering code to MLIR as an intermediate representation. Something that can be done with C++ as well
  - pjmlp 1mo ago
    In fact, clang is in the process of adding an MLIR layer as well, ClangIR.
jcelerier 1mo ago
> However, such an approach has previously not really worked for C++ with LLVM offload ... isn't Metal shading language just C++17 compiled with LLVM ? working on every Mac and iPhone in the world is not what I would call "not really worked". Likewise, SYCL works just fine.
- mathisfun123 1mo ago
  bruh lol this is so wrong and so confident i don't want to even attempt to explain how wrong you are. > just C++17 compiled with LLVM i invite you to attempt to compile/run absolutely any C++17 codebase on your iphone's GPU lol!
  - nish__ 1mo ago
    Wouldn't any metal app have to be written in C++17?
  - jcelerier 1mo ago
    I mean "any C++ codebase" doesn't make sense in general. I run C++23 code on ESP32, that doesn't mean I'm gonna build KDE or chrome for it, and that doesn't make it any less C++.
  - pjmlp 1mo ago
    For starters Metal Shading Language is based on C++14, so naturally any C++17 will fail.
- pjmlp 1mo ago
  It is C++14.
  - jcelerier 27d ago
    no, it has been updated to C++17 in metal 4: https://developer.apple.com/metal/Metal-Shading-Language-Specification.pdf https://developer.apple.com/metal/Metal-Shading-Language-Spe...

aw1621107 1mo ago

> However, such an approach has previously not really worked for C++ with LLVM offload. Why would it work for Rust? I think that will depend on the exact reason(s) C++ with LLVM offload didn't work out? If Rust differs from C++ in a way that addresses pain points/failure modes/etc. from the C++ attempt, for instance, then perhaps it isn't unreasonable to think Rust could succeed where C++ didn't (c.f., Mozilla's pre-Rust attempts to parallelize Firefox's CSS styling engine). Inversely, if Rust doesn't do things differently in the right way perhaps one might expect the effort to also not work out. Or maybe the problems are entirely non-technical and things could work out in either language.

erupti 1mo ago
[flagged]

ux266478 1mo ago

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

erupti 1mo ago
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.
- aw1621107 1mo ago
  > 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.
  - erupti2 1mo ago
    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.
    - aw1621107 1mo ago
      > 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.

winningChild 1mo ago

[dead]

winningChild 1mo ago

[dead]

boxed 1mo ago

Seems to work out well for Mojo, so I'd guess it's more an issue with C++.

nylonstrung 1mo ago
Well mojo handles it by introducing an additional step of lowering code to MLIR as an intermediate representation. Something that can be done with C++ as well
- pjmlp 1mo ago
  In fact, clang is in the process of adding an MLIR layer as well, ClangIR.

jcelerier 1mo ago

> However, such an approach has previously not really worked for C++ with LLVM offload ... isn't Metal shading language just C++17 compiled with LLVM ? working on every Mac and iPhone in the world is not what I would call "not really worked". Likewise, SYCL works just fine.

mathisfun123 1mo ago
bruh lol this is so wrong and so confident i don't want to even attempt to explain how wrong you are. > just C++17 compiled with LLVM i invite you to attempt to compile/run absolutely any C++17 codebase on your iphone's GPU lol!
- nish__ 1mo ago
  Wouldn't any metal app have to be written in C++17?
- jcelerier 1mo ago
  I mean "any C++ codebase" doesn't make sense in general. I run C++23 code on ESP32, that doesn't mean I'm gonna build KDE or chrome for it, and that doesn't make it any less C++.
- pjmlp 1mo ago
  For starters Metal Shading Language is based on C++14, so naturally any C++17 will fail.
pjmlp 1mo ago
It is C++14.
- jcelerier 27d ago
  no, it has been updated to C++17 in metal 4: https://developer.apple.com/metal/Metal-Shading-Language-Specification.pdf https://developer.apple.com/metal/Metal-Shading-Language-Spe...