miniBUDE GPU Benchmark for Docking

• miniBUDE is a compute-bound GPU proxy that isolates BUDE’s core scoring kernel, providing a realistic benchmark for molecular docking computations.
• It preserves a nested-loop structure with high arithmetic intensity, enabling controlled cross-backend performance and portability studies.
• The benchmark’s sensitivity to fast-math optimizations highlights critical performance trade-offs in GPU arithmetic-kernel execution.

miniBUDE is a compute-bound GPU proxy for the Bristol University Docking Engine (BUDE), a molecular docking code used in drug discovery. In the reported GPU study, miniBUDE serves as the primary compute-bound benchmark without atomics, complementing Hartree–Fock as a compute-bound benchmark with atomics. It extracts and simplifies the core scoring kernel of BUDE so that the dominant docking computation can be ported and benchmarked across programming models while preserving the nested-loop structure, high arithmetic intensity, and sensitivity to fast-math optimizations that characterize realistic scientific compute kernels on accelerators (Godoy et al., 25 Sep 2025).

1. Definition and benchmark role

In BUDE and miniBUDE, the dominant computation is a per-pose accumulation over many atom pairs between a ligand molecule and a protein receptor, producing an approximate interaction energy or score for each pose. The underlying application domain is molecular docking, where large numbers of candidate ligand configurations are evaluated against a fixed receptor. miniBUDE isolates the core scoring kernel from that workflow and thereby functions as a tractable proxy for portability and performance studies on GPUs (Godoy et al., 25 Sep 2025).

The benchmark matters because it is explicitly positioned as a realistic scientific compute-bound workload. The study states that the fasten kernel has high arithmetic intensity, is representative of scientific compute-bound GPU workloads, and is sensitive to fast-math optimizations. Those properties make miniBUDE a particularly discriminating test for code generation quality in arithmetic-heavy kernels, especially where transcendental functions, divisions, and square-root-like operations are on the critical path (Godoy et al., 25 Sep 2025).

Within the benchmark suite discussed in the paper, miniBUDE occupies a specific methodological niche. The seven-point stencil and BabelStream are used as memory-bound workloads, while miniBUDE is the main compute-bound case without atomics, and Hartree–Fock extends the analysis to compute-bound behavior with atomic operations. This division allows miniBUDE to isolate arithmetic-kernel performance from atomic-update effects and to probe whether a compiler stack can approach vendor implementations for dense floating-point GPU code (Godoy et al., 25 Sep 2025).

2. Algorithmic structure and scoring formulation

The paper does not print the full BUDE scoring equations, but it specifies the computational structure of the benchmark. For each pose $p$, the code iterates over ligand atoms $i$ and protein atoms $j$, computes transformed ligand coordinates, evaluates a pairwise interaction, and accumulates that contribution into a total pose energy $E_p$. The generic form given is

$$E_p = \sum_{i \in \text{ligand}} \sum_{j \in \text{protein}} f\big(\mathbf{r}_i^p, \mathbf{r}_j, \text{types}_i, \text{types}_j, \text{FF}\big),$$

where $\mathbf{r}_i^p$ is the transformed position of ligand atom $i$ in pose $p$, $\mathbf{r}_j$ is the protein atom position, and FF denotes global forcefield tables (Godoy et al., 25 Sep 2025).

The interaction function $f$ is described as physically motivated but simplified. Its evaluation includes coordinate transforms, distance and direction computations, and pairwise interaction terms combining van der Waals and electrostatic effects, weighted by atom types and global forcefield parameters. The implementation characteristics listed in the paper include sqrt or rsqrt-type distance calculations, polynomial and rational expressions representing potential terms, and multiplications and additions that compilers may contract into FMAs (Godoy et al., 25 Sep 2025).

This loop nest is what makes miniBUDE compute-bound. The pairwise term scales with the product of ligand and protein atom counts, and the number of floating-point operations per interaction is large relative to the associated memory traffic. A plausible implication is that miniBUDE is not merely a synthetic throughput test; it preserves a scientifically recognizable interaction pattern while remaining sufficiently regular to support controlled cross-backend comparison.

3. FLOP model, arithmetic intensity, and compute-bound behavior

The paper defines the miniBUDE performance metric in terms of kernel runtime and an analytical operation-count model:

$i$0

with

$i$1

Here, PPWI denotes poses per work item, and nligands and nproteins denote the ligand and protein atom counts (Godoy et al., 25 Sep 2025).

The decomposition of the FLOP count is explicit. There is a constant per-workgroup overhead of $i$2, a per-ligand-atom overhead of $i$3, and a per ligand–protein pair term of $i$4. Because the pair term dominates for nontrivial atom counts, the total work scales as $i$5 (Godoy et al., 25 Sep 2025).

The memory-traffic pattern is correspondingly light. The paper characterizes it as involving only a few float4 loads for the relevant atom and force-field data, while results are accumulated in registers and written out only once per pose. That leads to a high FLOP/byte ratio and places miniBUDE in the compute-bound region under the roofline model. The initial roofline figure cited in the paper places miniBUDE firmly in that region, in contrast to BabelStream and the seven-point stencil, which lie near the memory roof (Godoy et al., 25 Sep 2025).

The role of PPWI is central. Because each GPU thread handles several poses, increasing PPWI increases per-thread work and arithmetic intensity. This makes miniBUDE a useful benchmark not only for raw arithmetic throughput but also for code-generation quality under growing register-resident working sets and increasingly ALU-dense loop bodies.

4. GPU kernel organization and Mojo implementation

The paper presents the Mojo miniBUDE implementation through the fasten_kernel, parameterized by PPWI as a compile-time integer. The kernel uses a one-dimensional thread/block mapping with block_idx.x, block_dim.x, and thread_idx.x, and computes the initial pose index as

$i$9

Each thread handles PPWI poses, and PPWI is a generic parameter so that MLIR can specialize and unroll loops (Godoy et al., 25 Sep 2025).

The per-thread state includes etot as SIMD[dtype, PPWI], holding one partial energy per pose, and transform as InlineArray[Vec4f32, PPWI * 3], holding per-pose rotation, translation, and precomputed transform data. The setup phase reads transforms_0..5, computes sin and cos, and constructs the pose transforms. The kernel then enters nested loops over ligand atoms and protein atoms, updating etot[i] for each pose handled by the thread, before writing the final energies back to etotals (Godoy et al., 25 Sep 2025).

The implementation is intentionally low-level in data representation. All arrays are passed as UnsafePointer[Float32], and the paper states that the code is deliberately C-like in layout and access style. Vec4f32, SIMD, generics, compile-time constants, and InlineArray are used in ways described as being explicitly tuned to MLIR’s strengths, especially fixed sizes and static control flow (Godoy et al., 25 Sep 2025).

The host-side launch path uses the Mojo GPU standard library through gpu.host.DeviceContext, with device buffers allocated via enqueue_create_buffer[Float32], the kernel launched as fasten_kernel[PPWI] with a chosen block size and grid size, and synchronization performed afterwards. The paper further states that the Mojo implementation captures the same structure as the original C++ CUDA and HIP baseline codes and that GPU code was not fine-tuned beyond matching existing baseline configurations such as number of blocks and threads (Godoy et al., 25 Sep 2025).

A notable implementation constraint is Mojo’s lack of GPU POD struct allocation support for the original Atom representation consisting of 3-Float32 and 1-Int elements. The workaround is a flattened array of 4-Float32 elements, with the last element cast back to an integer inside the kernel. This preserves memory layout identity across devices and compilers, but requires manual indexing and casting (Godoy et al., 25 Sep 2025).

5. Experimental configuration and reported performance

The study evaluates miniBUDE on an NVIDIA H100 NVL and an AMD MI300A. The device parameters reported are 60 TFLOP/s FP32 peak for the H100 NVL and 122.6 TFLOP/s FP32 peak for the MI300A. The benchmarked miniBUDE case is bm1, with num_poses = 65,536, PPWI varied from 1 to 128 in powers of two, two work-group sizes wg = 8 and wg = 64, and Float32 precision (Godoy et al., 25 Sep 2025).

On H100, the comparison includes CUDA with fast-math, CUDA without fast-math, and Mojo, which the paper states has no fast-math capability yet and is therefore comparable to strict-math execution. The reported qualitative pattern is that CUDA with fast-math is fastest, CUDA without fast-math is significantly slower, and Mojo typically lies between those two. For small PPWI and small work-group size, such as small PPWI with wg=8, Mojo can slightly outperform CUDA without fast-math. As PPWI increases and the kernel becomes more ALU-dense, the lack of fast-math becomes a strong disadvantage (Godoy et al., 25 Sep 2025).

The performance-portability metric reported for H100 miniBUDE gives a Mojo efficiency of 0.82 for PPWI=8, wg=8 and 0.59 for PPWI=4, wg=64. The arithmetic mean reported for Mojo miniBUDE is

$i$6

The paper interprets this as Mojo reaching about 54 % of the best vendor performance for the sampled miniBUDE configurations, where the best vendor implementation is CUDA fast-math on H100 (Godoy et al., 25 Sep 2025).

On MI300A, the same overall ordering is reported: HIP with fast-math is fastest, HIP without fast-math is slower, and Mojo underperforms both HIP variants. The paper gives 0.38 efficiency for Mojo relative to HIP best at both PPWI=8, wg=8 and PPWI=4, wg=64. It summarizes this as Mojo being consistently below even the strict-math HIP runs for miniBUDE on AMD. The overall miniBUDE efficiency table is described as giving the same $i$7 across both vendors (Godoy et al., 25 Sep 2025).

Configuration or metric	Reported value	Context
H100 NVL FP32 peak	60 TFLOP/s	Device parameter
MI300A FP32 peak	122.6 TFLOP/s	Device parameter
miniBUDE case	bm1	Benchmark case
Number of poses	65,536	Experimental setup
Work-group sizes	8, 64	wg values
PPWI range	1 to 128	Powers of two
H100 Mojo efficiency	0.82	PPWI=8, wg=8
H100 Mojo efficiency	0.59	PPWI=4, wg=64
MI300A Mojo efficiency	0.38	PPWI=8, wg=8
MI300A Mojo efficiency	0.38	PPWI=4, wg=64
Mean miniBUDE efficiency	0.54	$i$8

These results position miniBUDE as the main negative case in the paper’s broader performance-portability analysis. The reported means for the seven-point stencil and BabelStream are 0.92 and 0.96, respectively, whereas miniBUDE is 0.54, indicating a markedly larger gap for arithmetic-heavy code (Godoy et al., 25 Sep 2025).

6. Fast-math sensitivity, bottlenecks, and backend effects

The central bottleneck identified for miniBUDE is the lack of fast-math support in Mojo’s GPU compilation pipeline. The paper states that CUDA and HIP fast-math aggressively replace standard sin, cos, and sqrt-class operations with hardware approximate intrinsics such as __sinf, __cosf, and rsqrtf, while also allowing reassociation, FMA contraction, and relaxed denormal handling. Mojo currently cannot enable an equivalent level of relaxed math; the MLIR-to-LLVM-to-GPU path remains closer to IEEE semantics (Godoy et al., 25 Sep 2025).

This matters directly for miniBUDE because sin and cos are used in the transform setup, and standard miniBUDE implementations include distance and inverse-distance computations relying on sqrt or specialized reciprocal square roots. The paper characterizes these operations as being on the critical path. Without fast-math, they are more expensive and may require more instructions, which reduces effective GFLOP/s in a kernel whose runtime is dominated by arithmetic rather than memory movement (Godoy et al., 25 Sep 2025).

A second factor is backend maturity on AMD. The paper states that on NVIDIA, Mojo is at least competitive with strict-math CUDA in miniBUDE, whereas on MI300A Mojo falls below both fast- and non-fast-math HIP. This is attributed to AMD GPU support in Mojo being new and less optimized, summarized in the paper’s conclusion that “gaps exist on AMD GPUs … for fast-math compute-bound kernels” (Godoy et al., 25 Sep 2025).

The paper also mentions additional, more tentative factors. The need to emulate the Atom struct via flattened float4 arrays and manual casting may inhibit some aliasing or vectorization optimizations that CUDA and HIP can exploit more naturally, although this is not quantified. It also notes that, in other kernels, Mojo sometimes uses more registers per thread than CUDA, reducing occupancy; while no specific miniBUDE register metrics are reported, the paper presents this as a plausible contributing factor for compute-heavy kernels (Godoy et al., 25 Sep 2025).

From a numerical perspective, the paper does not report detailed accuracy comparisons between strict-math and fast-math miniBUDE variants. Fast-math versus non-fast-math is treated primarily as a performance dimension, not as a physics-validation issue. The suggestion that Mojo may be more numerically conservative is explicitly left unquantified (Godoy et al., 25 Sep 2025).

7. Portability implications and relation to the Python ecosystem

miniBUDE is used to evaluate not only absolute performance but also performance portability. One of the paper’s core observations is that the same Mojo miniBUDE source runs on both H100 and MI300A without source code changes; only the build and device-selection side changes. This demonstrates functional portability of the exact same kernel across NVIDIA and AMD GPU ISAs (Godoy et al., 25 Sep 2025).

At the same time, miniBUDE shows that functional portability does not imply uniform performance portability. On NVIDIA, Mojo generally sits between fast-math and strict-math CUDA. On AMD, it trails even strict-math HIP. This suggests that miniBUDE is an especially sensitive probe of backend maturity and math-library quality because its bottlenecks are concentrated in arithmetic execution rather than in bandwidth saturation or synchronization overhead (Godoy et al., 25 Sep 2025).

The MLIR-based compilation model is materially relevant here. Because PPWI is a compile-time integer in fasten_kernel[PPWI], MLIR can specialize and unroll loops over range(PPWI) and accesses into InlineArray[Vec4f32, PPWI*3]. The SIMD[dtype, PPWI] energy vector is also statically sized. The paper presents these as optimizable features that align with MLIR’s strengths in fixed-size and static-control transformations. However, it also makes clear that such structural optimization does not compensate for the absence of fast-math in transcendental-heavy kernels (Godoy et al., 25 Sep 2025).

In the broader context of the Python ecosystem, miniBUDE is used as evidence that a CUDA-style, low-level GPU kernel can be written directly in Mojo, interoperating with Python while targeting multiple vendors. The paper frames this as part of the convergence of scientific computing and AI, but also states that the learning curve and programming requirements remain fairly low-level. miniBUDE in Mojo uses manual pointers, explicit layout control, and workaround-based atom representations, making the current style closer to CUDA and HIP than to high-level Python (Godoy et al., 25 Sep 2025).

The benchmark therefore supports a qualified conclusion. miniBUDE demonstrates that MLIR-based portable GPU code generation can express and execute a realistic docking kernel across vendors, and that a relatively direct port can capture the same algorithmic structure as established CUDA and HIP baselines. At the same time, it highlights concrete limitations: missing fast-math controls, less mature AMD backend optimization, and the absence of POD struct support on GPU memory. A plausible implication is that miniBUDE will remain a useful regression benchmark for any future attempt to improve fast-math handling, backend-specific tuning, and higher-level abstractions for per-thread multi-pose mappings such as PPWI (Godoy et al., 25 Sep 2025).