Hang Liu, Junjie Li, Yinzhi Wang, Niraj K. Nepal, Yang Wang
6 min
Abstract
This study explores the use of INT8-based emulation for accelerating traditional FP64-based HPC workloads on modern GPU architectures. Through SCILIB-Accel automatic BLAS offload tool for cache-coherent Unified Memory Architecture, we emulate FP64 matrix multiplications in the LSMS CPU application in the MuST suite without code changes. We find that accuracy depends on both arithmetic precision and the properties of the operator, which can be dealt with through tunable precision emulation. Unlike traditional mixed-precision approaches, this method preserves original algorithms while optimizing hardware utilization. We showcase the potential of improving accuracy and performance at the same time. This work highlights the potential of AI-driven hardware to transform HPC, advocating for adaptive precision strategies in future scientific computing.
Sam: Imagine you have a big, precise number you need to multiply by another big one, but your calculator only handles small chunks quickly. You break each big number into slices using sets of prime numbers that don't share factors—called coprime moduli—so each slice fits in INT8. Then you do multiple quick INT8 multiplies on the GPU's Tensor Cores, which are super-fast units for that, and reassemble the exact original result using the Chinese Remainder Theorem because those primes guarantee a unique fit. Researchers label this Ozaki-II GEMM emulation, and it lets you tune the number of slices for just the right accuracy-speed balance.
Alex: Huh, so like splitting a huge puzzle into tiny fast-to-solve pieces, then putting it back perfectly. Does this actually deliver on the promise for real simulations like LSMS?
Sam: Yes, in tests on an NVIDIA GB200 GPU with the FeNi3 alloy benchmark from MuST. The high-precision modes matched the CPU's FP64 accuracy for key outputs like total energy per atom and magnetic moments, while speeding up the main matrix work by about 1.7 times overall.
Alex: That's a clear improvement without losing reliability. But wait—is the whole simulation sped up, or just that GEMM part?
Sam: Just the GEMM-heavy parts, which dominate in LSMS. Other operations stay on the CPU in FP64, so gains taper in the highest precision modes as you add more INT8 slices. The paper notes this as a targeted approach, preserving the original algorithm fully.
Alex: So it bridges the gap for GEMM-bound codes like this quantum chemistry one. What makes LSMS a good fit—why does it tolerate the emulation so well?
Sam: LSMS solves for electron densities via Green functions, computed by inverting huge matrices along an energy path. Errors from emulation mostly hit a narrow sensitive region, but integration averages them out, and physics principles like the variational theorem keep total energy robust—even lower modes stay accurate enough. This inherent stability makes it ideal for GPU offload.
Alex: Interesting—the math of the method itself helps.
Sam: They measured errors in the Green function and observables across modes. Mid-to-high settings—like 16 moduli in GEMMul8—hit FP64-level fidelity, with self-consistent convergence matching the baseline.
Alex: And no code changes—that's huge for legacy software. How does SCILIB-Accel pull that off without breaking things?
Sam: It uses dynamic binary instrumentation to intercept BLAS library calls—like a spy watching for GEMM requests—and offloads them via cache-coherent unified memory, where CPU and GPU share data seamlessly. Paired with GEMMul8's hook for Ozaki-II, one environment tweak activates it all on systems like Grace-Hopper.
Alex: So for scientists, drop in the tools, set precision via variables, and run—weeks to days potentially. But as AI hardware keeps prioritizing low precision, is this a sign to rethink standards?
Sam: The paper suggests yes—advocating adaptive strategies to repurpose AI GPUs for HPC, maximizing centers' investments. It shows emulation unlocks throughput while tuning to needed accuracy, a meaningful step toward converging AI and science computing. Thanks for listening to ResearchPod.