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

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

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

reply
> I think that will depend on the exact reason(s) C++ with LLVM offload didn't work out?

Are you making a claim or asking a question? ESL?

reply
Seems to work out well for Mojo, so I'd guess it's more an issue with C++.
reply
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
reply
> 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.

reply
It is C++14.
reply
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!

reply
For starters Metal Shading Language is based on C++14, so naturally any C++17 will fail.
reply
Wouldn't any metal app have to be written in C++17?
reply
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++.
reply
[dead]
reply
[dead]
reply