LegNeato

7 ms·

1.
by LegNeato 1mo ago
Just distracting / ugly to my eyes.
2.
by LegNeato 1mo ago
The goal of this work is to run existing unmodified CPU libraries (which may use core::simd) on the GPU. If you are manually writing ML-shaped workloads, it doesn't add any value over writing with tech like torch/tensorflow/j
3.
by LegNeato 1mo ago
It's just a way for us to add minutia and details that most don't care / need to know about. There are three audiences we try to make the posts accessible for: Rust people who don't know about GPUs, GPU people who don&#x
4.
by LegNeato 1mo ago
The goal is to use similar abstractions and code across both the CPU and GPU where it makes sense.
5.
by LegNeato 1mo ago
It is not currently available but we intend to make it available after we launch our products.
6.
by LegNeato 1mo ago
Part of our thesis is that decent GPUs are in every shipping device and most software doesn't use them and should.
7.
by LegNeato 1mo ago
The tentative plan is to open source all the compiler and `std` bits with our products built on top (compilers are not good businesses). More about our products coming in the next couple of months!
8.
by LegNeato 1mo ago
Didn't want to go into crazy detail in the post. Each family of operations is a trait parameterized by the operation itself: pub trait EvaluateReduction<Operation, T>: LaneEvaluator { /// Reduce one distr
9.
by LegNeato 1mo ago
We never mention anything about superiority nor compare with other languages or programming models. This post is about making existing Rust CPU code work on the GPU.
10.
by LegNeato 1mo ago
Author here, AMA.
11.
by LegNeato 2mo ago
Oh, this again. I should put a website with this up... I was the person who personally ran 10.6 security updates at Apple (10.6.1+), the "DRI". My team in the Updates Program office and I reviewed every single bug to determine if
12.
by LegNeato 2mo ago
Quite honestly I would use cuda-oxide over rust-cuda for anything new right now....while rust-cuda is more complete, cuda-oxide is more aligned with nvidia's future direction (when we were rebooting rust-cuda we were told to by nvidia
13.
by LegNeato 2mo ago
Maintainer of rust-gpu and rust-cuda here. 1. Rust CUDA is over 5 years years old, was dead for 2(?) years, but was rebooted and works. It enables both rust on the GPU and controlling the GPU from the host. The host library (cust) predates
14.
by LegNeato 2mo ago
As a Puerto Rico resident, it is not "beyond time" and you have no clue what you are talking about.
15.
by LegNeato 3mo ago
See also the rust spir-v backend: https://github.com/Rust-GPU/rust-gpu/
16.
by LegNeato 5mo ago
There is no reason why compiler passes cannot be in an egraph, they are more general than optimizations. When you think about it, traditional compiler concerns like instructions selection are sort of a optimization problem if you squint.
17.
by LegNeato 5mo ago
Why do passes anymore when we have invented egraphs?
18.
by LegNeato 5mo ago
We are the maintainers of https://github.com/rust-gpu/rust-gpu and https://github.com/Rust-GPU/Rust-CUDA FWIW. We haven't upstreamed the VectorWare work yet as it is still being cleaned up an
19.
by LegNeato 5mo ago
Agreed, and thank you.
20.
by LegNeato 5mo ago
It is not, we just haven't yet upstreamed everything.
21.
by LegNeato 5mo ago
It depends. At VecorWare are a bit of an extreme case in that we are inverting the relationship and making the GPU the main loop that calls out to the CPU sparingly. So in that model, yes. If your code is run in a more traditional model (CP
22.
by LegNeato 5mo ago
Founder here. 1. Programming GPUs is a problem. The ratio of CPUs to CPU programmers and GPUs to GPU programmers is massively out of whack. Not because GPU programming is less valuable or lucrative, because GPUs are weird and the tools are
23.
by LegNeato 5mo ago
No, it means not being able to see what is going on. Which is literally what the word blind means. You can be blinded by many things (blindfold, clouds/fog, bright lights, darkness, accidents, genetics, etc), permanently and temporaril
24.
by LegNeato 5mo ago
One of the rust-gpu maintainers here. Haven't officially heard from anyone at AMD but we've had chats with many others. Happy to talk with whomever! I would imagine AMD is focusing on ROCm over Vulkan for compute right now as thei
25.
Rust Threads on the GPU(vectorware.com)
2 points by LegNeato 5mo ago|0 comments
26.
by LegNeato 7mo ago
Thank you! We're small so have to focus. If anyone from AMD wants to reach out, happy to chat.
27.
by LegNeato 7mo ago
Doing things at compile time / AOT is almost always better for perf. We believe async/await and futures enables more complex programs and doing things you couldn't easily do on the GPU before. Less about performance and more
28.
by LegNeato 7mo ago
Currently NVIDIA-only, we're cooking up some Vulkan stuff in rust-gpu though.
29.
by LegNeato 7mo ago
We aren't focused on performance yet (it is often workload and executor dependent, and as the post says we currently do some inefficient polling) but Rust futures compile down to state machines so they are a zero-cost abstraction. The
30.
by LegNeato 7mo ago
Yes, that's the idea. GPU-wide memory is not quite as scarce on datacenter cards or systems with unified memory. One could also have local executors with local futures that are `!Send` and place in a faster address space.

More ›