Spectral Compute @SpectralCom

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=tw…

Read the paper: doi.org/10.1145/381689… See the benchmarks: scale-lang.com/?utm_source=tw…

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-compu… 𝗔 𝗰𝗼𝗺𝗽𝗶𝗹𝗲𝗿 𝘁𝗵𝗮𝘁 𝗼𝗻𝗹𝘆 𝗰𝗼𝗺𝗽𝗶𝗹𝗲𝘀 𝘁𝗵𝗲 𝗲𝘅𝗮𝗺𝗽𝗹𝗲𝘀 𝗶𝗻 𝗶𝘁𝘀 𝗼𝘄𝗻 𝗱𝗼𝗰𝘂𝗺𝗲𝗻𝘁𝗮𝘁𝗶𝗼𝗻 𝗶𝘀 𝗮 𝗱𝗲𝗺𝗼. 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

@ToniRMCardoso Thanks for the retweet! 🚀

@SpectralCom 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-discord

Join our Discord: discord.com/invite/KNpgGbT…

"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. 𝗣𝗿𝗶𝗰𝗲 𝗶𝘀 𝗼𝗻𝗲 𝗯𝗲𝗻𝗲𝗳𝗶𝘁. 𝗚𝗲𝘁𝘁𝗶𝗻𝗴 𝗰𝗼𝗺𝗽𝘂𝘁𝗲 𝘄𝗵𝗲𝗻 𝘆𝗼𝘂 𝗻𝗲𝗲𝗱 𝗶𝘁 𝗶𝘀 𝘁𝗵𝗲 𝗯𝗶𝗴𝗴𝗲𝗿 𝗼𝗻𝗲.

That job, in numbers: scale-lang.com/?utm_source=li…

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 - 𝘁𝗵𝗮𝘁 𝗶𝘀 𝘁𝗵𝗲 𝗷𝗼𝗯.

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.

Join our Discord if you want to talk this one through: tinyurl.com/4a23dav5

Something still has to compile that code then, and many of the optimisations that matter aren't expressible in source at all. Agents speed up plenty of GPU work. They don't remove the compiler from it. Try scale-lang.com out and tell us what you think!

The largest body of GPU code in the world is CUDA. Models write it better than anything else. You can see people working around that. 🧵