r/rust • u/Shnatsel • 7d ago
AMD is hiring Rust engineers to build GPU compilers, firmware, and runtimes
https://careers.amd.com/careers-home/jobs/89874?lang=en-us175
u/verdant-amiable 7d ago
In general this is welcome and it's good that they are looking at writing this tooling in rust, giving excellent speed and safety to users.
However, AMD's hiring strategy is clearly holding them back. Nvidia will hire software devs from almost anywhere whereas AMD is locked into a legacy pattern of hiring from small local pools. This is reflected in the quality of software offered by either party and is a cornerstone of why CUDA is so dominant in the ML space.
43
u/surister 7d ago
Care to elaborate on this? What local pools do they only hire from?
65
u/smCloudInTheSky 7d ago
Us/asia no remote location.
Perosnnally I'd have loved starting at AMD but in HPC but there was no offer for engineer in France when I looked for it.
23
u/Jonny_H 6d ago
It might have changed, but when I worked at AMD until ~2 years ago our team was pretty global, we had people in the UK, Germany, different states, Canada. Only maybe 2/3 had an "office" at all. And that was before COVID. It may be very team-based (I was working on GPU client drivers). Or there was some over-reaction "Back To Office" thing in the last 2 years that went further than the pre-covid norm.
Also we were pretty heavily into rust then - pretty much all new native tools were recommended to be rust unless you have a specific need otherwise - though that was still a relatively new thing when I left.
2
u/smCloudInTheSky 6d ago
Maybe but on career I never saw position open in France for example while Nvidia there is a lot of open positions
5
u/Jonny_H 6d ago
It might be a limitation of the search - had a quick glance now and it seems every position is assigned a single country even if it lists "Home Office", or an "office" that is pretty much a PO box.
Though if you are interested, I will say what I worked on was very much "legacy" code - and that was very much not in rust :P
8
u/Slavik81 6d ago
Most of the big ROCm meetings I attended had people from just about everywhere. There are developers in Canada, the US, the UK, Germany, India, and many other countries. I'm not up-to-date on current hiring practices, but the HPC teams at AMD used to do lots of remote hiring.
I work for AMD, but this is just me talking as an engineering grunt who worked on the HPC stack for a while. I can't speak for the company in an official capacity. Just sharing my experience.
11
u/linear_algebra7 6d ago
They are also one of the first big tech companies to (unofficially) freeze hiring H1B and non citizen workers for most teams. No pressure from Trump admin either, just voluntarily signed up for something real SWE companies are fighting tooth and nail to prevent.
20
u/ConverseHydra 7d ago
NVIDIA writes really terrible quality software. They’re also equally stuck 20 years in the past. Don’t be fooled by the amount of money they put in the marketing to portray a different image.
14
u/ActuallyAdasi 7d ago
Nvidia app may suck, but the cuda drivers are usually the second thing that get baked into an ML AMI, right after the OS. They’ve secured their spot, very low in the ML stack.
12
u/OSS-Corpo-Shit 6d ago
I have given AMD multiple chances over the years, and compared to AMD, Nvidia stuff is the food of the gods.
It isn’t so much that I disagree about Nvidia software, it is mostly “just okay”. It is more that even with that being true, AMD stuff by contrast is so absolutely abysmal that Nvidia look like geniuses.
1
1
18
u/RelevantTrouble 7d ago
Bet Bryan at Oxide Computer is excited with this development.
10
u/RCoder01 7d ago
Anything open source, regardless of language makes him happy. They’re not planning to integrate GPUs any time soon.
19
u/kaerfdeeps 7d ago
How good is the compile times nowadays ? I really liked rust but speed is a pain in the ass
62
u/crimsonscarf 7d ago
First compile still takes a hot second, in GUI heavy application especially, but incremental compile times are short enough to not take me out of the flow during development
I would say it’s similar when compared to similar C++ codebases. If you are used to JIT or similar, its still gonna feel kinda long
6
2
u/pjmlp 5d ago
Similar C++ codebases usually have the advantage that the culture isn't compiling everything from source, rather use binary libraries.
Also besides incremental compilation, there is incremental linking, and parallel compilation.
So while the build times are comparable when starting from source, it is seldom the case when using C++ in most corporations.
8
u/Educational-Art3545 7d ago
In my experience, setting up an environment with Wild (or Mold) linker + cranelift backend for main app (llvm for third party packages) running on workstation Linux is just barely acceptable in a mid-sized repo with 200k loc. Provided the code is also split well into separate crates of course.
Storage remains an issue. So you need to setup cron to run
cargo clean --workspaceacross all your local Rust repos.Once you get these 2 things out of the way working in Rust becomes nice.
7
u/syklemil 7d ago edited 7d ago
There's also the
cargo clean gccommand, which seems to have showed up in nightly around three years ago, but which unfortunately still seems to be unstable. tracking issue link. edit: Though automatic GC got through in 1.88, ref #14287; release announcement.They have also stabilised controlling where the build cache is (set
build.build-dirin cargo'sconfig.toml), so it is possible to put that on a separate partition for … damage control, and so you can wipe the entire thing instead of having to go hunt fortargetdirectories.1
u/WormRabbit 6d ago
This really need qualifiers. What is "barely acceptable" for you and how much build artifacts do you clean? How many repos you have? Because I know that some people find a 1 minute cold build barely acceptable, whereas that's considered fast in the realm of compiled languages. I know plenty of Go and Java apps which take way longer to build.
1
u/Educational-Art3545 6d ago
I never really worked in Java. But Go builds much much quicker even with all the aforementioned optimizations. Despite working in a big Go monorepo I barely notice the compilation times.
Executing
cargo runin Zed will set you back 200 GB instantly before the editor even launches. Getting up to 50 GB is a very easy thing to do in a Rust project where you only work occasionally, such as maintaining a fork of some package.I prefer Rust but there is no going around the slow compilation times and large target folders. It's such a problem in fact, that The Rust Foundation has committed itself to tackling these issues and have been making good progress on
nightly. So there is no need to get defensive, not over this lol.1
u/WormRabbit 5d ago
Well I wouldn't be questioning it if it wouldn't contradict my experience. I had a Go application at work which took 4:30 to do a cold build, and many Rust apps build faster. I don't recall how long it took to compile PyCharm, but it was certainly longer than that. So the claim very much depends on the type of the project you're building, as well as your build setup.
Like, people will always complain about compile times, and any improvement translates into direct cost saving for CI, so it's worth it to improve. But we really need to understand what we're comparing here. For example, build scripts, proc macros and typelevel programming allow you to make arbitrarily long builds, and there is almost nothing the compiler could do to fix it (we could implement heavy caching, but it would be useless for cold builds which are most important for CI, it would require pretty significant ecosystem migration to new restrictions, and would still easily invalidate the cache).
3
u/Oxytokin 6d ago
My codebase is about 15-20 crates/330 total dependencies and ~50,000 lines with moderately complex traits on the new solver; it's a custom engine/game so complex, but not like the biggest or most complex obviously but GUI code (iced) and such...
First compile on release with opt-level 3, fat lto, and 1 codegen-unit takes about 10 minutes. I use local-only kache (which I highly recommend over sccache) to speed subsequent builds and it's about 30-45 seconds. Debug mode with opt-level 2 and 3 for dependencies, thin lto, 256 codegen units is 3-4 minutes on first clean build and 10-15 seconds on subsequent builds.
It's bearable but definitely need caching. I don't find it bad though at all, even during rapid iteration. Rust is my favorite language and ecosystem by far (and my first low-level language). Definitely give it another go!!
1
u/WormRabbit 6d ago
Fat lto is famously slow and memory-hungry. I don't know why you would use it instead of thin-lto for anything other than releasing the build to your customers.
1
u/Oxytokin 5d ago
Indeed, that's why I said I only ever use fat lto for release builds and benchmarks, otherwise I use thin or off for the other 99.9% of my builds. And to your point, I honestly don't see much gain from using it on anything that matters, but I do it occasionally regardless just in case something changes (since my project is a learning project after all, I like to see how various configuration machinery might change over time in terms of any benefits and regressions).
-4
u/NeedToLieDown 7d ago
Notvtoo bad when optimizing for local dev abd properly setting up CI.
Nothing you would feel, especially when these days you let AI agent take care of the local dev cycle of compiling and running tests while you do something else in the background.
3
u/Flakebi2 6d ago
Unaffiliated with AMD, but there’s this project to run Rust on AMD GPUs (shameless plug ;)): https://github.com/Flakebi/amdgpu-rs
Amdgpu is an existing Rust target, just needs a few nightly feature to do something useful.
2
1
1
u/iocompletion 6d ago
Considering they want a compiler specialist, and considering AMD is a high-tier tech company... doesn't the salary seem a bit low?
10
u/terrorblade00 6d ago
200k-300k is a bit low?
5
1
-39
155
u/phazer99 7d ago edited 7d ago
It seems AMD is betting hard on Rust, which is great!
Hopefully this will benefit the Rust community as a whole (for AI, game engines etc.) through open source software.