# Ozaki scheme, maybe support FP128? - DGEMM without FP64 Arithmetic – Using FP64 Emulation and FP8 Tensor Cores with Ozaki Scheme
**URL:** https://discourse.julialang.org/t/ozaki-scheme-maybe-support-fp128-dgemm-without-fp64-arithmetic-using-fp64-emulation-and-fp8-tensor-cores-with-ozaki-scheme/138382
**Category:** Internals & Design
**Created:** [July 21, 2026, 12:25am UTC](https://discourse.julialang.org/t/ozaki-scheme-maybe-support-fp128-dgemm-without-fp64-arithmetic-using-fp64-emulation-and-fp8-tensor-cores-with-ozaki-scheme/138382 "2026-07-21T00:25:52Z")
**Posts on this page:** 3
**Page:** 1
### Author:  [@Palli](https://discourse.julialang.org/u/Palli)
#### Post date: [July 21, 2026, 12:25am UTC](https://discourse.julialang.org/t/ozaki-scheme-maybe-support-fp128-dgemm-without-fp64-arithmetic-using-fp64-emulation-and-fp8-tensor-cores-with-ozaki-scheme/138382/1 "2026-07-21T00:25:52Z")
This scheme was new to me:
[https://arxiv.org/pdf/2508.00441](https://arxiv.org/pdf/2508.00441)
It’s about GPUs. Got me thinking maybe this would also work for FP128, on CPUs (or GPUs). [EDIT: has been done, _for matrices_, see my follow-up post.]
~~It doesn’t supports scalars~~ (or well), pays off with a large enough matrix. Probably Julia can’t do Float64 faster on CPUs, using Float32, I suppose all CPUs have as many units for, or half as fast bandwidth wise.
>
>
> Extended precision types are occasionally useful in prototyping codes and develo…ping numerical intuition of an algorithm. I am thinking here of double-double/quad-double from the QD package \[1\]. These are statically sized with reasonable performance. The downside is supporting them via LAPACK/BLAS and other libraries; this would definitely be a value-added component of the Julia environment.
>
> \[1\] http://crd-legacy.lbl.gov/~dhbailey/mpdist/
@photor
> **[GitHub - UoB-HPC/PortableFP128: Shim header to provide portable access to IEEE...](https://github.com/UoB-HPC/PortableFP128)**
>
> Shim header to provide portable access to IEEE 128b floats in C.
---
### Author:  [@Oscar\_Smith](https://discourse.julialang.org/u/Oscar_Smith)
#### Post date: [July 21, 2026, 4:45am UTC](https://discourse.julialang.org/t/ozaki-scheme-maybe-support-fp128-dgemm-without-fp64-arithmetic-using-fp64-emulation-and-fp8-tensor-cores-with-ozaki-scheme/138382/2 "2026-07-21T04:45:22Z")
For CPU it will be a lot slower than Quadmath.jl / libquadmath. CPUs have fast 64\*64-\>128 multiply which is a much faster way to do 128 bit math.
---
### Author:  [@Palli](https://discourse.julialang.org/u/Palli)
#### Post date: [July 22, 2026, 12:26am UTC](https://discourse.julialang.org/t/ozaki-scheme-maybe-support-fp128-dgemm-without-fp64-arithmetic-using-fp64-emulation-and-fp8-tensor-cores-with-ozaki-scheme/138382/3 "2026-07-22T00:26:18Z")
I’m was thinking of for BLAS like in the paper (I wasn’t clear on that), I thought this scheme would be possible for Float128 too, and I see I’m right since it has already been done for CPUs:
[https://dl.acm.org/doi/fullHtml/10.1145/3472456.3472493](https://dl.acm.org/doi/fullHtml/10.1145/3472456.3472493)
> Compared to this previous study, this paper provides the following contributions.
>
> - We apply the Ozaki scheme to high-precision (binary128) computations in environments where high-precision operations are not supported on hardware.
> - We present specific optimization methods to compute binary128 using binary64.
> - We present an implementation and evaluation on x86 hardware, while the previous study targeted NVIDIA GPUs.
>
> ..
> Oz-b128 outperformed MP-b128 in all cases, and MP-dd was comparable to Oz-b128 when _R_ = 64. Note that the DD arithmetic in the QD library used in MP-dd is not SIMD-optimized,
In short from the other paper:
> The Ozaki scheme [28], proposed by Ozaki et al. in 2012, is a method that enables high-precision matrix multiplication to be computed using low-precision matrix multiplications.
i.e. OpenBLAS and MKL do not support Float128, but maybe Julia should, and then it can be implemented with such libraries (on Float64, or lesser on GPUs).
Julia doesn’t strictly need to support this for matrices (or scalars), since a library can. I just got exited about this relatively new research I didn’t know of; and the scheme, yes 12 years old, I guess you knew of it.
I believe the scheme can split Float128 into 3 Float64, or 5 Float32, or 10 Float16. And you use k^2 BLAS operations, so at least 9 times slower done with Float64 as opposed to “ **2x to 5x slower** ” for scalars with libquadmath, but since the scalars don’t work with BLAS you will end up faster, given large enough matrix.
> [@Oscar\_Smith](#):
>
> For CPU it will be a lot slower than [Quadmath.jl](https://juliaregistries.github.io/General/packages/redirect_to_repo/Quadmath) / libquadmath. CPUs have fast 64\*64-\>128 multiply which is a much faster way to do 128 bit math.
I think you have in mind only the scalar (integer) case::
> 64-bit to 128-bit multiplication **actually takes exactly 1 instruction** , but on ARM64 processors, it requires **exactly 2 instructions**.
But that excludes unpacking floats and repacking in software, killing performance, and can’t use BLAS libraries like OpenBLAS.