Nerds taming the green dragon with SCALE, our framework for compiling CUDA codebases for AMD GPUs, with support for more accelerated platforms coming soon.
483 Green Lanes London England
Joined September 2025
- Tweets389
- Following56
- Followers358
- Likes189
๐ฆ๐๐๐๐ ๐ญ.๐ณ.๐ฐ ๐ถ๐ ๐ผ๐๐.
Same CUDA code, same answers: single-precision maths now meets NVIDIA's documented error bounds. Fast-math division behaves as it does with nvcc, which can mean a very large speedup for division-heavy kernels. Occupancy fixes let code that sizes its own launches get more out of the GPU, and launches and 3D memory copies are faster too.
Download SCALE 1.7.4 for free, run it on your codebase, and tell us how it went on Discord.
Full release notes: docs.scale-lang.com/stable/mโฆ
Join us on Discord: scale-lang.com/s/discord-li
The most useful thing a SCALE user can send us is a bug report.
The CUDA API is huge. Large-scale projects depend on both documented and undocumented behaviours. The real target isn't described by the manual, it emerges when we try to run real workloads.
So what users actually hit decides which parts of the API we cover next and which fixes ship first.
If SCALE fails to build your code, gives wrong results, or runs slower than it should, tell us what broke and where on Discord. It moves your problem up the list.
๐ฌ๐ผ๐๐ฟ ๐ณ๐ฎ๐ถ๐น๐ฒ๐ฑ ๐ฏ๐๐ถ๐น๐ฑ ๐ถ๐ ๐ผ๐๐ฟ ๐ฟ๐ผ๐ฎ๐ฑ๐บ๐ฎ๐ฝ.
AMD Instinctโข GPUs are incredible. A single AMD Instinctโข MI355X sports ๐ฎ๐ด๐ด๐๐ ๐ผ๐ณ ๐๐๐ ๐ฏ๐, ๐ด๐ง๐/๐ ๐ผ๐ณ ๐ฝ๐ฒ๐ฎ๐ธ ๐บ๐ฒ๐บ๐ผ๐ฟ๐ ๐ฏ๐ฎ๐ป๐ฑ๐๐ถ๐ฑ๐๐ต ๐ฎ๐ป๐ฑ ๐ณ๐ด.๐ฒ ๐ง๐๐๐ข๐ฃ๐ ๐ผ๐ณ ๐ฝ๐ฒ๐ฎ๐ธ ๐๐ฃ๐ฒ๐ฐ.
Put eight in a node and you have 2.3TB of HBM3E: enough to hold an entire frontier-scale model in memory on one machine. For accelerated HPC, it means bigger simulations resident on a single GPU, bandwidth-bound kernels with space to breathe, and serious double precision.
SCALE compiles supported CUDA code to run natively on it, cutting the effort required to move existing applications.
Our compiler is built to use what the hardware offers. One example: AMD GPUs can pass data between threads through DPP, hard-wired lane permutations that cost almost nothing. SCALE recognises the patterns in ordinary CUDA shuffles and maps them onto DPP automatically, so your code takes the fast path without a line of AMD-specific code.
The silicon was always capable. What held CUDA workloads back on AMD was getting the code there without leaving performance behind on the way. That is a compiler problem, and compilers can be fixed once for everyone.
We are now listed in @AMD's Instinct AI & HPC Software Ecosystem Program!
amd.com/en/ecosystem/isv/datโฆ
A hybrid GPU fleet only pays off if every part of it runs your code fast.
The best price-performance moves between vendors and hardware generations. Mixing accelerators is how you follow it.
The catch is the software. A second vendor usually means a second codebase, tuned to the same standard as the first. Every optimisation lands twice. Every release is validated twice. The engineering bill eats the hardware savings.
scale-lang.com removes that step. Your existing CUDA code compiles natively for AMD and NVIDIA GPUs, and the compiler does the tuning: novel optimisations that use each target's own hardware features, including ones that cannot be expressed in source at all.
On the Extended OpenDwarfs suite, unmodified CUDA code compiled with SCALE 1.7.3 is ๐ผ๐ป ๐ฝ๐ฎ๐ฟ ๐๐ถ๐๐ต ๐๐๐ฃ ๐ฎ๐ป๐ฑ ๐ป๐๐ฐ๐ฐ ๐ผ๐ป ๐ฎ๐๐ฒ๐ฟ๐ฎ๐ด๐ฒ, and faster on about half the workloads (AMD MI300X and NVIDIA B300, September 2026).
๐ข๐ป๐ฒ ๐ฐ๐ผ๐ฑ๐ฒ๐ฏ๐ฎ๐๐ฒ. ๐๐๐ฒ๐ฟ๐ ๐ฎ๐ฐ๐ฐ๐ฒ๐น๐ฒ๐ฟ๐ฎ๐๐ผ๐ฟ ๐ถ๐ป ๐๐ต๐ฒ ๐ณ๐น๐ฒ๐ฒ๐ ๐ฒ๐ฎ๐ฟ๐ป๐ถ๐ป๐ด ๐ถ๐๐ ๐ธ๐ฒ๐ฒ๐ฝ.
Benchmarks: scale-lang.com/?utm_source=tโฆ
The fairest way to compare GPU toolchains is to hand them the same workload.
That is the idea behind Extended OpenDwarfs, the benchmark suite built by our colleague Beau Johnston: 16 benchmarks spanning 13 Berkeley dwarfs, each written in CUDA, HIP and OpenCL, with every run checked for correctness.
Beau has now turned it on scale-lang.com. The CUDA code is compiled with SCALE and measured against native HIP on AMD and nvcc on NVIDIA, on systems from AMD Vega to NVIDIA Blackwell.
The result is a peer-reviewed paper, ๐๐ค๐ข๐ญ๐ช๐ฏ๐จ ๐ต๐ฉ๐ฆ ๐๐น๐ต๐ฆ๐ฏ๐ฅ๐ฆ๐ฅ ๐๐ฑ๐ฆ๐ฏ๐๐ธ๐ข๐ณ๐ง๐ด, which Beau presented in Singapore at the NVIDIA Supercomputing User Group (NVSUG) workshop at ICPP '26. Code and raw data are open, so anyone can rerun it.
The same suite runs our newest benchmarks too: with SCALE 1.7.3, unmodified CUDA code is ๐ผ๐ป ๐ฝ๐ฎ๐ฟ ๐๐ถ๐๐ต ๐๐๐ฃ ๐ฎ๐ป๐ฑ ๐ป๐๐ฐ๐ฐ ๐ผ๐ป ๐ฎ๐๐ฒ๐ฟ๐ฎ๐ด๐ฒ, and faster on about half the workloads.
You shouldn't have to pick a GPU vendor up front. And your codebase shouldn't pick one for you.
That was our CEO @SpectralMichael's point on stage at the The Xcelerated Compute Show in London, in a fireside chat with @dcdnews's Vlad - Gabriel Anghel.
He calls it team rainbow ๐: rather than signing up with team green, red or blue, you mix and match.
He compared the CUDA ecosystem to the UK plug: you can argue it's the better socket, but nobody rips out the wiring to switch. And rewriting code for each vendor is a maintenance bill that grows with every vendor you add.
So keep your CUDA code. scale-lang.com compiles it for NVIDIA and AMD GPUs. You get more performance per dollar from the hardware you already own, and you buy your next GPU because it's the best one for the workload, not because it's the only one your code runs on.
@BerryWrites wrote it up for @sdxcentral: sdxcentral.com/news/can-teamโฆ
The hardest test for a CUDA compiler is code that was never written with it in mind.
So on top of our own tests, we build 48 open-source CUDA projects - FFmpeg, OpenCV, GROMACS, hashcat and more. We follow each project's own build instructions as closely as we can, then run its own test suite on AMD and NVIDIA GPUs.
That is a deliberately unforgiving test, and it steers our roadmap. API coverage is driven by what real projects actually reach for, discovered by watching real builds fail - not by working alphabetically through a specification.
The scripts and the results for each release are public, failures included. Read them and pick holes in them - repo link: github.com/spectral-compute/โฆ
๐ ๐ฐ๐ผ๐บ๐ฝ๐ถ๐น๐ฒ๐ฟ ๐๐ต๐ฎ๐ ๐ผ๐ป๐น๐ ๐ฐ๐ผ๐บ๐ฝ๐ถ๐น๐ฒ๐ ๐๐ต๐ฒ ๐ฒ๐
๐ฎ๐บ๐ฝ๐น๐ฒ๐ ๐ถ๐ป ๐ถ๐๐ ๐ผ๐๐ป ๐ฑ๐ผ๐ฐ๐๐บ๐ฒ๐ป๐๐ฎ๐๐ถ๐ผ๐ป ๐ถ๐ ๐ฎ ๐ฑ๐ฒ๐บ๐ผ.
Come tell us what to test: scale-lang.com/s/discord?utmโฆ
๐ฆ๐๐๐๐ ๐ญ.๐ณ.๐ฏ ๐ถ๐ ๐ผ๐๐.
This release adds a Rocky Linux / RHEL 8 package, and supports older glibc in general.
More of the compiler now ships statically linked, so it is less likely to clash with other LLVM-based compilers.
Texture API support expands substantially. And there is the usual long list of nvcc-compatibility, runtime and CUDA-X library fixes.
Grab the new release from scale-lang.com.
๐๐ฟ๐ผ๐ฝ-๐ถ๐ป ๐๐ต๐ผ๐๐น๐ฑ ๐ฐ๐ผ๐๐ฒ๐ฟ ๐๐ต๐ฒ ๐๐๐๐๐ฒ๐บ ๐ฎ๐ ๐๐ฒ๐น๐น ๐ฎ๐ ๐๐ต๐ฒ ๐ฐ๐ผ๐ฑ๐ฒ.
Full release notes: scale-lang.com/s/scale173tw
Spectral Compute retweeted
llama.cpp carrying a hip tree that trails cuda is the quiet tax. cutlass having no amd door at all is the sharper split
There are two kinds of well-known CUDA project.
The first kind ships two codebases: a CUDA one and a hand-written HIP port. Hashcat, GROMACS, Cycles, llama.cpp all carry both. Every change has to land twice, and the port usually trails the original.
The second kind has no working AMD route at all. CUTLASS, AMGX and others simply do not run on AMD hardware - unless you compile them with scale-lang.com.
For the first group we are a way to delete a codebase. For the second we are the only door in.
Best part? SCALE is free for non-commercial use. Try it against your codebase, and drop into our Discord to let us know how it fared!
scale-lang.com/s/scale-discoโฆ
"Portable code is slower than hand-tuned code" is one of those things everyone knows and nobody rechecks.
CPU compilers disproved it decades ago. They exploit diverse hardware features better than most people manage by hand.
The GPU version of that argument is very concrete. Moving data between lanes can go through a general permute instruction, which bounces the data off the shared memory cache at roughly ten times the cost of a register move. Or it can go through a hardwired permutation pattern that is ๐น๐ถ๐๐ฒ๐ฟ๐ฎ๐น๐น๐ ๐๐ถ๐ฟ๐ฒ๐ - close to free, and expressed as a flag on an operand rather than an instruction of its own.
The catch is that the available patterns change between hardware generations, so almost nobody reaches for them by hand.
A compiler can. scale-lang.com takes a whole reduction loop, works out what is actually being computed across which lanes, and rebuilds it from the cheap patterns - chaining two of them where no single one matches.
The same analysis then found something on NVIDIA hardware: a whole-warp reduction instruction most people never write the metaprogramming to reach. SCALE now uses it automatically wherever it applies.
Read our blog post "Optimizing CUDA Shuffles with SCALE": tinyurl.com/5y5vhtxy
๐ก๐ผ๐ ๐ฒ๐๐ฒ๐ฟ๐ ๐ธ๐ฒ๐ฟ๐ป๐ฒ๐น ๐ด๐ฒ๐๐ ๐ฎ ๐ญ๐ฌ๐ฌ๐
.
A Monte Carlo run splits into millions of independent jobs. GPUs eat that. Hundreds of times a CPU core, easily.
An FDTD stencil is limited by memory bandwidth, not arithmetic. It runs as fast as the memory allows and no faster.
A sparse implicit solve is the awkward one. On the open-source OPM Flow reservoir simulator, a published comparison[1] put one GPU at about 5.6x a dual-threaded MPI process.
All three get sold as "GPU accelerated".
So when someone quotes you a speed-up, ask which kernel it came from. Borrowed from another shape, it tells you nothing about yours.
Ours, same treatment: on Rodinia, against hand-written HIP ports on an MI300X, scale-lang.com averaged ๐ฒ.๐ญ๐ต๐
. Up to 33.8x. Faster on 10 of the 14.
Benchmarks: tinyurl.com/4ku2yx47
Most real CUDA codebases have inline assembly in them somewhere.
Automated porting gives up on it. There is no source-level translation of inline PTX, so the code someone wrote specifically to be fast is the code that does not come across.
scale-lang.com parses it instead. Inline PTX is raised into the compiler's own intermediate representation, optimised like any other code, then lowered back onto whatever instructions the target hardware actually has.
A three-input bitwise operation written as inline assembly comes out the other side as two native AMD instructions, because once it is real code the optimiser can fold it.
This pays off on NVIDIA hardware too. Plenty of inline PTX in the wild was written around toolchain limitations that no longer exist, and assembly a compiler cannot read blocks it from optimising everything around it.
๐ฃ๐ผ๐ฟ๐๐ฎ๐ฏ๐ถ๐น๐ถ๐๐ ๐๐ต๐ผ๐๐น๐ฑ๐ป'๐ ๐ฐ๐ผ๐๐ ๐๐ผ๐ ๐๐ฝ๐ฒ๐ฒ๐ฑ.
๐๐ผ๐บ๐ฝ๐๐๐ฒ ๐ฎ๐๐ฎ๐ถ๐น๐ฎ๐ฏ๐ถ๐น๐ถ๐๐ ๐ถ๐ ๐ฎ ๐ฏ๐ผ๐๐๐น๐ฒ๐ป๐ฒ๐ฐ๐ธ.
New accelerators reach a handful of clouds first, and capacity stays tight for a while after that. If your code only builds for one vendor, you're stuck waiting on that vendor's capacity.
scale-lang.com compiles accelerated HPC codebases to run natively on both AMD and NVIDIA GPUs. That widens the pool of capacity you can actually use.
๐ฃ๐ฟ๐ถ๐ฐ๐ฒ ๐ถ๐ ๐ผ๐ป๐ฒ ๐ฏ๐ฒ๐ป๐ฒ๐ณ๐ถ๐. ๐๐ฒ๐๐๐ถ๐ป๐ด ๐ฐ๐ผ๐บ๐ฝ๐๐๐ฒ ๐๐ต๐ฒ๐ป ๐๐ผ๐ ๐ป๐ฒ๐ฒ๐ฑ ๐ถ๐ ๐ถ๐ ๐๐ต๐ฒ ๐ฏ๐ถ๐ด๐ด๐ฒ๐ฟ ๐ผ๐ป๐ฒ.
A recent scale-lang.com release included a significant atomics optimisation that only benefits AMD GFX11 cards. Hardware that is around five years old.
Silicon vendors rarely fund that work, and for a completely rational reason. Making last year's card faster does not sell this year's card. Their incentive is the next chip.
A compiler company's incentive runs the other way. We are paid for code running fast on whatever you already own. Older hardware, mixed fleets, the cards you bought two procurement cycles ago - ๐๐ต๐ฎ๐ ๐ถ๐ ๐๐ต๐ฒ ๐ท๐ผ๐ฏ.