Suggestion Description
Hi ROCm/HIP maintainers,
I am the author of Qingming G64 NTT, an open-source HIP/ROCm implementation of a native Goldilocks-field large-domain NTT for a STARK-style LDE workload.
I am opening this feature request to ask for profiling guidance, compiler/codegen advice, and feedback on whether this workload could be useful as a future advanced ROCm crypto benchmark or example.
Repository:
https://github.com/uulong950/qingming-g64-ntt
Benchmark contract:
https://github.com/uulong950/qingming-g64-ntt/blob/main/docs/BENCHMARK_CONTRACT.md
Workload
Qingming targets a native Goldilocks/G64 workload rather than a proxy “64-bit NTT” benchmark:
- Field: Goldilocks / G64
- Modulus: p = 2^64 - 2^32 + 1 = 0xFFFFFFFF00000001
- Logical data size: 2^24
- LDE expansion: exact 8x
- Transform domain: 2^27
- Backend: AMD HIP / ROCm
- Validated GPU: AMD Radeon RX 7900 XTX
- ROCm/HIP: ROCm 7.2.4 / HIP 7.2.53211
- Host CPU: AMD Ryzen 9 9950X
The benchmark measures the native STARK-style Goldilocks LDE boundary directly: no proxy field, no reduced modulus, no scaled-down domain, and no hidden layout cost.
Current validated result
On RX 7900 XTX, the validated 2^27 fast-interface benchmark reports:
- Median latency: 19.1927 ms
- P95 latency: 19.4936 ms
- Throughput: 52.10 size-2^27 NTT/s
- Element rate: 6.99 billion elements/s
- Butterfly rate: 94.41 billion butterflies/s
- P95 / median ratio: about 1.016
The standard compatibility interface with tiled prelayout reports around 21.99 ms median.
The tiled prelayout-only stage is measured separately at around 3.14 ms median.
Correctness
Correctness gates include:
- randomized field arithmetic checks
- primitive 2^27 root contract
- explicit base-512 layout bijection
- delta-vector validation
- sampled direct evaluation against the mapped output contract
- standard/fast layout checks
- full CPU radix-2 reference comparison over the full 2^27 output
Reproduction commands
Build:
cmake -S . -B build -DCMAKE_BUILD_TYPE=Release
cmake --build build -j
Correctness:
./build/qingming --self-test
./build/qingming --interface fast --delta --sampled --sample-coeffs 4096
./build/qingming --interface standard --prelayout tiled --prelayout-check --delta --sampled --sample-coeffs 4096
./build/qingming --interface fast --cpu-reference --threads 32 --cpu-logical 16777216
Benchmark:
./build/qingming --interface fast --bench --runs 50 --warmup 1
./build/qingming --interface standard --prelayout tiled --bench --runs 50 --warmup 1
./build/qingming --prelayout tiled --prelayout-only --runs 50 --warmup 1
Scaling benchmark:
cmake --build build --target qingming_p20 qingming_p21 qingming_p22 qingming_p23 qingming_p24 qingming_p25 qingming_p26 qingming_p27 -j
cmake --build build --target bench_scaling_fast
cmake --build build --target bench_scaling_standard
Requested guidance
I would appreciate guidance on the best ROCm/HIP way to profile and present this workload:
-
Which ROCm profiler counters are most useful for an integer-heavy, memory-sensitive NTT kernel on RX 7900 XTX / gfx1100?
-
What rocprof, Omniperf, or compiler flags are recommended for analyzing LDS usage, L2 behavior, occupancy, VGPR pressure, wavefront scheduling, global-memory throughput, and integer ALU utilization?
-
What HIP/clang codegen considerations are important for 64-bit integer arithmetic, wave shuffle, LDS transpose, and fused twiddle/transpose kernels on RDNA3?
-
What is the recommended way to report achieved physical memory bandwidth versus effective logical bandwidth for this kind of staged NTT pipeline?
-
What are the recommended practices for presenting profiler results for workloads with multiple fused NTT/transpose/twiddle stages?
-
Would a reduced version of this workload be useful as an advanced HIP/ROCm crypto benchmark or example?
Thanks for any guidance.
Operating System
Ubuntu 24.04
GPU
RX 7900 XTX 24G
ROCm Component
No response
Suggestion Description
Hi ROCm/HIP maintainers,
I am the author of Qingming G64 NTT, an open-source HIP/ROCm implementation of a native Goldilocks-field large-domain NTT for a STARK-style LDE workload.
I am opening this feature request to ask for profiling guidance, compiler/codegen advice, and feedback on whether this workload could be useful as a future advanced ROCm crypto benchmark or example.
Repository:
https://github.com/uulong950/qingming-g64-ntt
Benchmark contract:
https://github.com/uulong950/qingming-g64-ntt/blob/main/docs/BENCHMARK_CONTRACT.md
Workload
Qingming targets a native Goldilocks/G64 workload rather than a proxy “64-bit NTT” benchmark:
The benchmark measures the native STARK-style Goldilocks LDE boundary directly: no proxy field, no reduced modulus, no scaled-down domain, and no hidden layout cost.
Current validated result
On RX 7900 XTX, the validated 2^27 fast-interface benchmark reports:
The standard compatibility interface with tiled prelayout reports around 21.99 ms median.
The tiled prelayout-only stage is measured separately at around 3.14 ms median.
Correctness
Correctness gates include:
Reproduction commands
Build:
cmake -S . -B build -DCMAKE_BUILD_TYPE=Release cmake --build build -jCorrectness:
Benchmark:
Scaling benchmark:
Requested guidance
I would appreciate guidance on the best ROCm/HIP way to profile and present this workload:
Which ROCm profiler counters are most useful for an integer-heavy, memory-sensitive NTT kernel on RX 7900 XTX / gfx1100?
What rocprof, Omniperf, or compiler flags are recommended for analyzing LDS usage, L2 behavior, occupancy, VGPR pressure, wavefront scheduling, global-memory throughput, and integer ALU utilization?
What HIP/clang codegen considerations are important for 64-bit integer arithmetic, wave shuffle, LDS transpose, and fused twiddle/transpose kernels on RDNA3?
What is the recommended way to report achieved physical memory bandwidth versus effective logical bandwidth for this kind of staged NTT pipeline?
What are the recommended practices for presenting profiler results for workloads with multiple fused NTT/transpose/twiddle stages?
Would a reduced version of this workload be useful as an advanced HIP/ROCm crypto benchmark or example?
Thanks for any guidance.
Operating System
Ubuntu 24.04
GPU
RX 7900 XTX 24G
ROCm Component
No response