---
title: miniBUDE GPU Benchmark for Docking
url: https://www.emergentmind.com/topics/minibude
type: topic
---

# miniBUDE GPU Benchmark for Docking

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 [2509.21039].

## 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 [2509.21039].

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 [2509.21039].

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 [2509.21039].

## 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 [2509.21039].

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 [2509.21039].

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:

$$
\text{miniBUDE-total}_{\text{gflops}} =
\frac{\text{total}_{ops}}{\text{time}_{kernel} \cdot 1\text{E-}9},
$$

with

$$
\begin{aligned}
ops_{workgroup} &= 28\,PPWI \\
&\quad + n_{\text{ligands}} \cdot \Big[ 2 + 18\,PPWI \\
&\qquad + n_{\text{proteins}} \cdot (10 + 30\,PPWI ) \Big], \\
total_{ops} &= ops_{workgroup} \cdot \frac{\text{poses}}{PPWI}.
\end{aligned}
$$

Here, `PPWI` denotes poses per work item, and `nligands` and `nproteins` denote the ligand and protein atom counts [2509.21039].

The decomposition of the FLOP count is explicit. There is a constant per-workgroup overhead of \(28 \cdot PPWI\), a per-ligand-atom overhead of \(2 + 18 \cdot PPWI\), and a per ligand–protein pair term of \(10 + 30 \cdot PPWI\). Because the pair term dominates for nontrivial atom counts, the total work scales as \(O(\text{poses} \cdot n_{\text{ligand}} \cdot n_{\text{protein}})\) [2509.21039].

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 [2509.21039].

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

```mojo
var ix = block_idx.x * block_dim.x * PPWI + thread_idx.x
```

Each thread handles `PPWI` poses, and `PPWI` is a generic parameter so that MLIR can specialize and unroll loops [2509.21039].

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` [2509.21039].

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 [2509.21039].

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 [2509.21039].

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 [2509.21039].

## 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 [2509.21039].

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 [2509.21039].

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

$$
\overline{\Phi}_{\text{Mojo, miniBUDE}} = 0.54.
$$

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 [2509.21039].

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 \(\overline{\Phi}=0.54\) across both vendors [2509.21039].

| 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 | \(\overline{\Phi}\) |

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 [2509.21039].

## 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 [2509.21039].

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 [2509.21039].

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” [2509.21039].

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 [2509.21039].

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 [2509.21039].

## 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 [2509.21039].

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 [2509.21039].

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 [2509.21039].

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 [2509.21039].

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` [2509.21039].

Source: https://www.emergentmind.com/topics/minibude