arXiv CS open access

Scalable High-Fidelity Macromolecular Docking for GPU-Accelerated Supercomputers

2026 · arxiv_cs

arXiv CS · Papers · 2026

cloud distributed-computing parallel-computing

Conceptio Open Archive

Analyze & explore related research in Conceptio

Connect this record directly into your research workflow or AI agent. Explore citations across open repositories, query full text, and export structured proof bundles.

Explore in Search →Connect via MCP / API ↗

Scalable High-Fidelity Macromolecular Docking for GPU-Accelerated Supercomputers Xiangyu Meng1,2,† , Peng Chen3,† , Mingzhen Li4 , Jianmin Wang5 , Sen Wang1 , Guangming Tan4 , Weile Jia4 , Mohamed Wahib3,* , Tao Luo2 , Xun Wang1,* 1

arXiv:2608.07078v1 [cs.DC] 7 Aug 2026

College of Computer Science and Technology, Shandong Key Laboratory of Intelligent Oil & Gas Industrial Software, China University of Petroleum (East China), Qingdao, China 2 A*STAR Institute of Advanced Intelligence and Computing, Singapore 3 RIKEN Center for Computational Science, Kobe, Japan 4 Institute of Computing Technology, Chinese Academy of Sciences, Beijing, China 5 Department of Computer Science and Engineering, The Chinese University of Hong Kong, China x meng0420@163.com, peng.chen@riken.jp, limingzhen@ict.ac.cn, jmwang113@hotmail.com, homletree@s.upc.edu.cn, tgm@ict.ac.cn, jiaweile@ict.ac.cn, mohamed.attia@riken.jp, luo tao@a-star.edu.sg, wangsyun@upc.edu.cn

Abstract—Flexible macromolecular docking offers high-fidelity predictions of biomolecular interactions, but remains prohibitively expensive at scale. Among existing approaches, LightDock leverages Glowworm Swarm Optimization (GSO) for accuracy, yet suffers from limited parallelism, irregular computation, and severe load imbalance, preventing efficient execution on GPU supercomputers. We present SparkleDock, a scalable GSO-based docking framework enabling near-real-time flexible docking. We redesign GSO to expose massive fine-grained parallelism at the glowworm-agent level, and restructure the dominant energy scoring computation into a Tensor Core-compatible formulation, enabling efficient execution of irregular pairwise interactions through structured matrix operations. We further introduce a performance-model-driven scheduling for load balancing and out-of-core scaling across GPUs. SparkleDock achieves 9.7× and 18.9× speedups over LightDock on single A100 and H100 GPU, and delivers over two orders of magnitude acceleration at scale. On 512 GPUs, it reduces docking time from hours to seconds, enabling large-scale, high-fidelity virtual screening previously impractical with flexible docking. Index Terms—Macromolecular docking, GPU-accelerated supercomputer, Tensor cores, Strong scaling

I. I NTRODUCTION Flexible macromolecular docking is essential for accurately modeling biomolecular interactions, including proteins [1]– [3], antibody–antigen [4], [5], membrane receptor–soluble protein [6] interactions, and drug design [7], [8]. Compared to rigid-body methods, it improves the docking success rate by about 20%–30% as it accounts for conformational flexibility that traditional rigid-body docking cannot capture. Among existing flexible docking algorithms, LightDock adopts a Glowworm Swarm Optimization (GSO) method [6], [9], [10] that leverages multiple intelligent agents (i.e. glowworm agents) to optimize and search for flexible docking poses with stable binding energy. It has gained wide adoption for its high docking accuracy with an efficient and intelligent sampling approach. While LightDock achieves high docking fidelity in † Co-first authors; Corresponding authors: Xun Wang and Mohamed Wahib

comparison to other docking approaches (as seen in Tab. I), the algorithmic characteristics of GSO limits its scalability and hinder the efficient utilization of modern GPU architectures and large-scale distributed systems. Applying such applications for virtual screening on massive protein datasets like UniProt [11] would take several years. This obstacle highlights the importance of developing high-performance solutions for large-scale flexible macromolecular docking. The swarm-based LightDock exhibits three key bottlenecks: limited parallelism, irregular computation patterns, and inherent load imbalance, all of which hinder efficient utilization of GPU architectures and large-scale distributed systems. Limited parallelism. LightDock exposes parallelism primarily at the swarm level, where each swarm is processed independently. However, GSO inherently organizes the optimization as a set of interacting glowworm agents within each swarm, where each glowworm agent updates its state based on its local neighborhood [12], [13]. This swarmlevel design fundamentally limits the degree of parallelism to the number of swarms (typically hundreds to thousands), far below the massive concurrency supported by modern GPUs. Moreover, the iterative dependency among agents within each optimization step further restricts parallel execution. Irregular compute pattern. The energy score calculation dominates the computational cost, accounting for 89% of the total runtime and over 95% of the total FLOPs. This computation involves evaluating full pairwise interactions between atoms for each glowworm agent, resulting in quadratic complexity with respect to the number of atoms. Unlike structured dense linear algebra workloads, this irregular pairwise Euclidean distance computation deviates from structured matrix operations and cannot be directly mapped onto hardware designed for dense linear algebra like Tensor Core Units (TCU) [14], necessitating a careful reformulation. Poor scalability. GSO exhibits inherent load imbalance due to heterogeneous exploration of the conformational space, where different glowworm agents incur unequal computational

costs. This imbalance is further amplified by swarm-level parallelism, which processes swarms independently without fine-grained workload balancing. Consequently, existing implementations exhibit low GPU utilization and fail to scale efficiently across multiple GPUs or distributed systems for high-throughput screening. In addition, large-scale docking tasks (e.g. PDB entry 4GAM) introduce substantial memory demands, often reaching hundreds of gigabytes, which exceed the memory capacity of individual GPUs. For instance, docking PDB entry 4GAM generates hundreds of thousands of candidate glowworm agents and corresponding complexes. Each agent evaluates approximately 19.5 million receptor–ligand atom pairs per simulation, collectively resulting in a memory footprint of hundreds of gigabytes. These factors collectively hinder scalable deployment, necessitating coordinated load balancing and out-of-core execution strategies. This paper presents SparkleDock, a scalable GSO macromolecular docking framework, which exploits TCU acceleration at the GPU level, and further scales on GPU-accelerated supercomputers. The design of SparkleDock is motivated by the growing demand to bridge the gap between the highaccuracy flexible macromolecular docking algorithm and the inherent performance and scaling limitations of GSO. Experimental results on single A100 and H100 GPU demonstrate that SparkleDock achieves 9.7× and 18.9× speedups, respectively, in comparison to LightDock. The scaling evaluation shows that SparkleDock achieves effective strong scaling on multi-GPU systems with up to 512 GPUs, approaching effective strong scaling, particularly for larger workloads. By overcoming these scalability barriers, SparkleDock enables large-scale virtual screening and time-expensive docking workloads that were previously impractical with existing flexible docking methods. The contributions of this paper are as follows: • Novel algorithmic design of GSO to expose parallelism. We construct a fine-grained, glowworm agent-level parallelization scheme to match the compute hierarchy and memory subsystem of GPUs. • Co-design of the energy scoring computation with TCUs. We restructure the dominant energy scoring computation into a TCU–compatible formulation (i.e. 89.1% of the total execution time), transforming it into structured matrix computations to fully exploit TCUs while preserving the original scoring semantics. • Scalability. We develop performance model guided scaling methods in SparkleDock for efficient load balance and chunk division under different computing scales. The rest of this paper is organized as follows. Section II reviews the background and related work. Section III presents the proposed SparkleDock algorithm. Section IV reports the experimental results. Finally, Section V concludes the paper.

Algorithm 1: Macromolecular docking using GSO Input : Receptor backbone R; Ligand backbone L; distance-energy lookup table θ Output: Glowworm agent vectors G 1 I ← I NIT S WARM (R); ▷Swarms Initialization 2 G ← I NIT G LOWWORM (R, L, I); ▷G Initialization // Simulation 3 for i ← 0 to Ns − 1 do in parallel 4 for t ← 0 to S − 1 do 5 for j ← 0 to Ng − 1 do // Prepare docking Pose 6 for x ← 0 to Nr − 1 do (i,j) 7 Ax ← U PDATE R EC P OS (Rx , G (i,j) ); 8 9

10 11 12

13 14 15

for x ← 0 to Nl − 1 do (i,j) Bx ← U PDATE L IG P OS (Lx , G (i,j) ); // Calc DFIRE score(Bottleneck) D ← C ALC PAIRWISE D IST (A(i,j) , B(i,j) ); Idx ← D IST B INNING (D); E (i,j) ← ACCUMULATION (Idx, θ); // Calc neighbors l & Movement l(i,j) ← C ALC N EIGHBORS (l(i,j) , E (i,j) ); G (i,j) ← C ALC M OVEMENT (G (i,j) , l(i,j) ); Store (Gi );

sampling-and-scoring approach: (1) generating potential complex structures (sampling) and (2) evaluating near-native candidates (scoring). LightDock improves docking flexibility and success rates via GSO (belonging to the swarm intelligence family), with three steps: swarm initialization, glowworm agent initialization, and simulation (Alg. 1). Swarm initialization. This step initializes the swarm centers I ∈ RNs ×3 on the receptor surface, where each point represents a potential receptor–ligand binding site (line 1). It first traverses all atoms in receptor and generates the backbone (i.e. atoms of type C or CA). The receptor surface area Sur is then computed using FreeSASA [29], and the number of swarms is set as Ns = Sur/d, where d denotes the surface density (Å2 /atom). Finally, surface atoms are derived from backbone atoms, and K-means clustering is applied to generate swarm centers uniformly distributed around the receptor. Glowworm agent initialization. This step initializes the glowworm agent vectors G ∈ RNs ×Ng ×(3+4+Ml +Mr ) (line 2), where Ng is the number of agents per swarm. Each agent vector G (i,j) ∈ R3+4+Ml +Mr of glowworm agent (i, j) encodes a candidate transformation of the receptor and ligand backbones for complex formation. It comprises a translation vector α ∈ R3 , a rotation vector β ∈ R4 , and an anisotropic network model (ANM) vector γ ∈ RMl +Mr . α is the movement in Euclidean space, which is randomly initialized within a sphere of radius r around I. β is the agent rotation, which is updated and initialized in four-dimensional quaternion space [30]. γ represents the deformation magnitude along each non-trivial normal mode of the receptor and ligand, for backbone flexibility [31], [32]. Simulation. This procedure runs S steps of simulation

II. BACKGROUND & R ELATED W ORK A. Macromolecular Docking using GSO Macromolecular docking predicts new complexes from two known macromolecules (the receptor and ligand) using a

TABLE I: Related work comparison. SMD = Simulated Molecular Dynamics annealing; MC = Monte Carlo based method; TCU = Tensor Core; Success Rate = percentage of Top-10 predicted complexes. Method Alg. Addr. Flexibility Benchmark System Accelerator TCU Scaling Success Rate Runtime PIPER [15] FFT BM2 BlueGene/L PowerPC 512 nodes 9/42 (21%) 2 min PIPER-GPU [16] FFT BM2 GPU Tesla C1060 1 GPU 9/42 (21%) 4h ClusPro [17] FFT CAPRI Rds.1335 GPU Tesla K20C 1 GPU 19/42 (45%) 40.8 min pyDOCK [18] FFT BM5.2(deduplicate) CPU Intel Xeon 32 cores 11/55 (20%) 1h MEGADOCK [19] FFT BM4 TSUBAME 2.5 Tesla K20X 1K GPUs 8/176 (4%) 0.04 sec ZDOCK [20]–[23] FFT BM5(deduplicate) CPU – – 15/55 (27%) 1.5 h HADDOCK [24] SMD CASP-CAPRI CPU – – 16/25 (64%) ≥100 h RosettaDock [25], [26] MC BM5.2 CPU – – 41/88 (47%) 65 h SwarmDock [27], [28] SI BM5.2(deduplicate) CPU – – 22/55(38.18%) ≥36 h LightDock [9], [10] GSO BM5.2(deduplicate) CPU AMD Opteron 48 cores 51/55 (92.7%) 3.3 h LightDock-Rust [6] GSO BM5.2(deduplicate) CPU Intel Xeon 10 cores 51/55 (92.7%) 1.9 h SparkleDock (ours) GSO BM5.2(deduplicate) GPU Tesla A100 512 GPUs 51/55 (92.7%) 7 sec

to optimize each glowworm agent according to the energy score and identifies Ns × Ng energetic minima (i.e. potential receptor-ligand complex structures). Each step includes docking pose preparation, energy score calculation, neighbor list construction, and movement. In docking pose preparation (lines 6-9), LightDock retrieves each atom in the receptor and ligand backbones to calculate receptor poses A ∈ RNs ×Ng ×Nr ×3 and ligand poses B ∈ RNs ×Ng ×Nl ×3 of Ns × Ng glowworm agents with the corresponding G. The receptor and ligand poses denote the specific conformations and orientations transformed by G. In energy score calculation (lines 10-12), LightDock adopts the distance-scaled, finite, ideal-gas reference state (DFIRE) [33] to calculate the interaction energy score for each docking pose. It begins by computing the full pairwise distances D ∈ RNr ×Nl (line 10). For agent (i, j), let A(i,j) ∈ RNr ×3 and B (i,j) ∈ RNl ×3 denote the transformed receptor and ligand pose. Then, D is denoted as v u 3 u X (i,j) (i,j) (Ax,k − By,k )2 . Dx,y = t

also support FP64 calculation, providing the opportunity for accelerating scientific applications. In warp level, the TCU maps the MMA into three register fragment layouts, denoted as fragA, fragB, and fragC. WMMA exposes these fragments through warp-level abstractions [14], [46], but provides limited control over register layouts and data movement. In contrast, PTX mma offers finer-grained register-level control at a lower abstraction level. CuTe [47] provides C++ abstractions for tensor layouts and MMA operations, enabling flexible thread– data mappings and register configurations without directly managing low-level PTX instructions. While TCUs offer substantial acceleration opportunities, they demand structured computation patterns tailored to specific matrix operations. Given the diversity of the computing workloads, this specialization is often poorly aligned with many scientific applications. As a result, this mismatch limits the achieved peak performance and practical scalability of scientific computing on TCUs. Recent works have explored using TCUs beyond the standard MatMul, such as reductions and scans [37], stencil computations [38], [39], BreadthFirst Search (BFS) [40], FFT [41], and scientific computing applications with irregular computational patterns [48]. In LightDock, however, the dominant bottleneck lies in the more complicated pairwise distance calculation for docking energy scoring, which requires computing distances between every atom pair across the docking macromolecules. However, TCUs require highly structured matrix computations, which are fundamentally mismatched with the irregular pairwise interaction patterns in GSO-based docking. This mismatch necessitates careful reformulation to enable the efficient utilization of TCU.

(1)

k=1

Each distance value is then constructed into an index (binning) to retrieve its corresponding energy value from the premeasured distance-energy lookup table θ (line 11). Finally, the total energy score E of the agent j in swarm i is obtained by accumulating all energy values (line 12). In neighbor list construction and movement, LightDock first builds the neighbor list l ∈ RNg for each agent vector G (i,j) , containing the IDs of agents in swarm i with lower energy scores (line 13). Each agent then randomly selects a neighbor ′ Gi,j from li,j and updates its α, β, and γ. α is updated via a gradient step, β via Spherical Linear Interpolation (SLERP) [34], and γ via ProDy [35].

C. Related Work Rigid body docking. FFT-based rigid-body docking fixes one molecule and samples the other on a grid to evaluate interaction energies [49]. This formulation enables efficient high-throughput screening. Representative methods include FTDock [50], ZDOCK [23], and PIPER [15], which improve accuracy through enhanced scoring functions while retaining high computational efficiency. Flexible docking. Flexible docking accounts for conformational changes upon binding, achieving higher accuracy at the

B. Tensor Core Units Modern GPU supercomputers equipped with NVIDIA Tensor Core GPUs provide unprecedented computational capability for scientific applications [36]–[43]. They feature specialized accelerators, Tensor Core Units (TCUs), designed to boost the performance of standard matrix multiplication and accumulation (MMA). In Ampere and above [44], [45], TCUs

CUDA Kernels

Molecule Preparation

1. prepare_rec_pose 2. prepare_lig_pose Init Swarms 3. calc_dfire 4. calc_neighbors 5. movement Init Agents

Accelerated Simulation with Agent-Level Parallelism

1 Agent-level Parallelization for(i=0;i<swarms;i++) for(t=0;t<steps;t++) for(j=0;j<agents;j++)

for(t=0;t<steps;t++) for(i=0;i<swarms;i++) for(j=0;j<agents;j++)

Swarm 0 Swarm n Agent … Agent Agent … Agent m m 0 0

Agent Agent … Agent 0 1 m

2 TCU Accelerated Energy Score Calculation Rec Pose 𝓐 Lig Pose 𝓑

cp.async

Global Memory

Buffer 0 Buffer 1 Buffer 2

LDS

Complex

Workload

Receptor Ligand

Memory Budget Model: 𝑀𝑒𝑚0(012

Performance Budget Model: 𝑇0(012

Binning & Reduction

𝑭𝒓𝒂𝒈𝑨

Distance Mat 𝓓

mma 𝑭𝒓𝒂𝒈𝑩

Buffer 3

3 Performance Modeling Algorithm Params Hardware Params 𝑁('|)|*|+) , 𝑀(*|+) , 𝐵𝑊!"# , 𝑁$!%& 𝑇𝐻(!(&)|)+),|+)#|-(.)) 𝜇, 𝑀(-..|/0/*) 𝑀𝑒𝑚$!% , 𝛽

Warp shuffle

Shared Memory Registers

Registers TCUs

4 Scaling on Multi-GPU Systems

Energy Score

Performance Prediction

Global Memory

Model: 𝑀𝑒𝑚0(012

Model: 𝑇0(012

.. .

Fuse Last Loop

𝑤

MPI Load Balancing

𝑛

Chunk Division

𝑤 Load Balance & Chunk Division

Fig. 1: Overview of the SparkleDock framework. SparkleDock consists of molecule preparation, swarm initialization, agent initialization, and simulation (bottleneck). To accelerate the simulation, we devise agent-level parallelization, TCU accelerated energy score calculation, and performance model-guided scaling optimization.

cost of significantly increased computation. Methods such as SwarmDOCK [28], HADDOCK [51], and RosettaDock [26] employ stochastic optimization or sampling-based strategies. LightDock [9], [10], [52] further improves robustness using Glowworm Swarm Optimization (GSO) to achieve high docking accuracy across diverse macromolecules, enabling robust docking across proteins, peptides, and DNA. Performance and accuracy. Tab. I compares representative macromolecular docking methods. Rigid-body docking is computationally efficient and often accelerated on GPUs or many-core CPUs. For example, PIPER and MEGADOCK complete docking in 2 minutes and 0.04 seconds on the BlueGene/L [53] and TSUBAME 2.5 [54] supercomputers, enabling high-throughput screening. In contrast, flexible docking provides higher accuracy (e.g. over 47% Top-10 success rate) but incurs orders-of-magnitude higher computational cost, often requiring hours to days per docking. For example, HADDOCK may take hundreds of hours, while LightDock requires several hours even with parallel execution [6]. SparkleDock bridges this gap, enabling nearly real-time flexible docking on GPU-accelerated supercomputers.

Algorithm 2: Agent-level parallelization (same input & output as Alg. 1) // Swarm and glowworms initialization for t ← 0 to S − 1 do // Agent parallelism with five CUDA kernels 2 for (i, j) ← (0, 0) to (Ns − 1, Ng − 1) do in parallel // --- 3D grid computations --3 A(i,j) ← <G RID 3D> prepare rec pose(R, G (i,j) ) ; 4 B(i,j) ← <G RID 3D> prepare lig pose(L, G (i,j) ) ; 5 E (i,j) ← <G RID 3D> calc dfire(A(i,j) , B(i,j) ) ; // --- 1D grid computations --6 l(i,j) ← <G RID 1D> calc neighbors(l(i,j) , E (i,j) ) ; 7 G (i,j) ← <G RID 1D> movement(G (i,j) , l(i,j) ) ;

Store (G) ;

energy score calculation (over 89% of the total runtime) to exploit the TCU acceleration and also introduce optimized CUDA kernels that do partial computation that results from the reformulation. Based on the optimized designs and hardware parameters measured by microbenchmarks, we construct a memory budget model, M emtotal , and a performance budget model, Ttotal , to predict memory footprint and docking performance. Finally, guided by M emtotal and Ttotal , we propose MPI load balancing and out-of-core chunk division strategies to improve the scalability on multi-GPU systems.

III. D ESIGN OF S PARKLE D OCK Fig. 1 illustrates the design of the SparkleDock framework, including four stages: (1) Molecule preparation for data loading and pre-processing. (2) Swarm initialization. (3) Glowworm agent initialization. (4) Accelerated simulation with agent-level parallelism. Among them, the simulation stage accounts for over 99% of the total runtime. To leverage the computational power of multi-GPU systems, we provide several optimizations for SparkleDock. We first devise a finegrained, agent-level parallelization algorithm (step-1 in Fig. 1) to enhance the parallelism and exploit the compute throughput of the individual GPU. Next, we reformulate the hotspot

A. Fine-grained Agent-level Parallelism The agent vectors G at each step are updated from the previous step, so the Ns swarm loops and the Ng agent loops can be unrolled with each agent executing the GSO simulation independently. We exploit the parallelization opportunity to perform loop reordering (step-1 in Fig. 1) and introduce agentlevel parallelism in Alg. 2 to accelerate the time-consuming

a TensorCoreUnits(m8n8k4) X0

Frag 𝐁𝟎

pairwise distance calculation in Eqn 1, we expand it as follows:

v u 3 3 3 uX X X u (i,j) (i,j) (i,j) (i,j) Ax,k · By,k , (2) (By,k )2 − 2 · Dx,y = t (Ax,k )2 +

Frag 𝐁𝟏

k=1

Frag 𝐀𝟎

C0, C1

Frag 𝐀𝟏

C0, C1

Frag 𝐂𝟏,𝟏

Frag 𝐂𝟎,𝟏

c Accumulation

Squared Norm

b Calc Distance X0 X0

Lookup Table

Y0 Y0

10 2 10 …

0 1 V0

Z0 Z0 0 0

Squared Norm

X0 Y0 Z0 0

C0,C1

+ Frag 𝐂

𝐸#,% … V0 V1 Warp-level

C0, C1

k=1

where the underlined term is the tall-skinny matrices multiplication, and the remaining terms are the squared norm(i.e. sums of squares) for matrices A and B. Based on the derivation, the pairwise distance calculation can be decomposed into three steps: (1) Matrix multiplication C = A × B T adapted for TCU. (2) Calculate Row-wise and column-wise squared norms of A and B. (3) Element-wise combination of these terms to construct the distance matrix. Note that in this formulation, (1) and (2) are dataindependent, enabling simultaneously execution of (1) on TCUs and (2) on CUDA cores [55]. TCU kernel implementation. Based on Eqn. 2, we reformulate the energy score calculation into a TCU-accelerated kernel called calc dfire. Fig. 2 shows the design of the TCU kernel in warp level. Based on the agent-level parallelization, we use a 3D grid with 1D blocks (128 threads per block), where the gridDim.z unrolls the swarm loop Ns , the gridDim.y unrolls the glowworm agent loop Ng , and the gridDim.x tiles the data block of matrix A and matrix B. Each block is decomposed into four warps to perform the TCU-accelerated calc dfire kernel using mma simultaneously. Each warp then launches four mma instructions to compute a 16 × 16 tile, improving SM occupancy. Fig. 2(a) illustrates the specific partition in warp level. The k dimension of the receptor pose A and ligand pose B is 3, which is lower than the minimum dimension of the m8n8k4 fragment in FP64 mma (i.e. k=4). Therefore, we allocate 16 × 4 shared memory tiles for both A and B, and employ a strided memory copy to pad zeros along the k dimension to 4. Following the above partition, we propose a monolithic design to consolidate the entire energy score calculation into a single CUDA kernel. Based on the derivation in Eqn. 2, we first leverage the FP64 mma instruction, allowing each warp to execute the m8n8k4 matrix multiplication. TCUs and CUDA cores share the same register files. During the mma calculation, each thread can directly load the relevant elements from its allocated register fragments fragA and fragB to compute the squared norms, and subsequently accesses its accumulated results in accumulator fragC to calculate the pairwise distances D. Using get slice(threadIdx.x) in CuTe allows each thread to obtain its assigned registers in mma. Finally, the distance values are discretized into indices through DistBinning in Alg. 1. These indices are subsequently employed to query the lookup table θ, yielding the DFIRE energy contributions. These values are finally accumulated to obtain the final DFIRE energy score of each agent. We devise an efficient warp-level reduction using shared memory to accumulate the final energy score. Based on our design,

Frag 𝐂𝟏,𝟎

Frag 𝐂𝟎,𝟎

Binning

C0, C1

Reduction

Dist Value

Fig. 2: Implementation of the TCU-accelerated calc dfire kernel. (a) TCU-aware warp-level partition. (b) Thread-level distance calculation. (c) Accumulate the energy scores.

simulation. As shown in Fig. 1, we first perform loop reordering between the swarm and simulation loops. We then merge and unroll the swarm and agent loops, mapping them onto CUDA threads to derive the Alg 2. This algorithm begins with a simulation loop that executes S GSO steps (line 1). For each GSO step, we devise five efficient CUDA kernels with dedicated thread blocks to execute the agent-level GSO optimization(line 2-7 in Alg.2). Docking pose preparation and DFIRE score calculation exhibit high parallelism at the atom level. Therefore, we map these calculations onto a 3D grid with 1D block. The neighbor calculation and movement exhibit limited scalability at the glowworm level. We use the 1D grid with 1D block to unroll the swarm and glowworm loops. Compared to swarm-level parallelization, it increases parallelism by more than Ng times. B. Restructuring Energy Scoring into TCU Formulation The energy score calculation is the hotspot of the docking simulation, occupying over 89% of the total execution time. We developed a TCU-accelerated CUDA kernel using CuTe from CUTLASS. Restructuring energy scoring for TCUs. Based on the

0 1 2 3 4 5 6 7

Shuffle Sum of Squares

Packing

0 C0 C1 C0 C1

3 C0 C1 C0 C1

C0 C1 C0 C1

1 C0 C1 C0 C1

C0 C1 C0 C1

.. ..

2 C0 C1 C0 C1

C0 C1 C0 C1

(a) Layout of Accumulator

0 1 2 3 4 5 6 7

0 1 2 3 a0 a1 a2 a3

0 1 2 3 v0 v0 v0 v0

. . . .

v1 v1 v1 v1

a0 a1 a2 a3

a0 a1 a2 a3 a0 a1 a2 a3

. . . .

v6 v6 v6 v6 v7 v7 v7 v7

Warp-level Transpose 0 1 2 3 4 5 6 7

0 a0 a0

a0 a0

1 a1 a1

a1 a1

.. ..

2 a2 a2

a2 a2

3 a3 a3

a3 a3

Prologue

v# Row/Col Sum of Squares 0 v0 v1

v6 v7

1 v0 v1

v6 v7

.. ..

2 v0 v1

3 v0 v1

G(0)

G(1) G(2)

v6 v7

0 1 2 3 v0 v1 v0 v1 v0 v1 v0 v1 v0 v1 v0 v1 v0 v1 v0 v1

0 1 2 3 v0 v1 v2v3 v4v5 v6v7 v0 v1 v2v3 v4v5 v6v7

v6v7 v6v7 v6v7 v6v7 v6v7 v6v7 v6v7 v6v7

v0 v1 v2v3 v4v5 v6v7 v0 v1 v2v3 v4v5 v6v7 v0 v1 v2v3 v4v5 v6v7 v0 v1 v2v3 v4v5 v6v7 v0 v1 v2v3 v4v5 v6v7 v0 v1 v2v3 v4v5 v6v7

T2(Ab(1), Bb(0)), T3(Ab(1), Bb(1))

T1(Ab(0), Bb(1))

G: Global Mem S: Shared Mem cp.async: C2(Ab(1)) R: Register

cp.async: C1(Bb(1))

S(1) S(2)

share mem S R … S(0,3) R(0,3) S(1,0) R(1,0) … S(1,3) R(1,3) S(2,0) R(2,0) ~~ ~~ S(2,3) R(3,3) to registers (0,0) (0,0) ~~ TCU pipe

(b) Row Squared Norm Calculation

. . . .

S(0)

T0(Ab(0),Bb(0)) cp.async: C0(Ab(0), Bb(0))

MMA

… MMA

CUDA pipe

Wait C0

Wait C1

MMA

…

MMA

~ ~ ~ ~ ~ ~

MMA

Sum of Squares / Binning / Accumulation Wait C2

Fig. 4: Overlapping the memory and calculation pipeline using cp.async. Each CUDA thread block is extended into four pipeline stages, where each stage handles a 32×32 tile.

computation entirely at the register level, avoiding costly memory accesses. Fig. 3(b) shows the register remapping for fragA. We propose a shuffle sum of squares() method to efficiently compute the row squared norm of A, as shown in List. 1. In this algorithm, shufl sync(i,k) is used to broadcast the value of column i to register s of all threads within the same row (i.e. line 5 of List. 1). Each thread then calculates the squared values of s and accumulates in sum. After the above method, each thread holds the row sum of squares, which can be directly added to C in element-wise. For fragB, the column-major layout introduces additional mismatch with fragC. Since each thread corresponds to two column elements in fragC, we design a column-wise squared norm computation with a register packing strategy in Fig. 3(c). Specifically, we design a col squared norm procedure in List. 1. This function first invokes shuffle sum of squares() to compute the column-wise sum of squares for each thread (line 16). It then applies a packing approach to combine two column registers into one thread. Specifically, shufl up sync(4,8) shifts the even columns into the odd, while the shufl down sync(4,8) shifts the odd columns into the even columns. After packing, each thread holds two column registers, forming a column-major 8 × 4 squared norm matrix. We perform a warp-level transpose operation (lines 20-24) to convert it into an 8 × 4 row-major squared norm matrix matching the fragC layout. Finally, the accumulator fragC performs an element-wise addition of the two squared norm matrices to obtain the D. Each thread loads one row of A(four elements) and two columns of B(eight elements) from shared memory to fragA and fragB and computes the sum of squares in the intuitive design, consuming around 276 cycles. However, only 12 warp shuffle instructions are required in register remapping with 24 cycles. This optimization theoretically accelerates by 12×. Pipeline optimization. On Ampere and later GPUs, the cp.async instruction enables direct asynchronous copying from global to shared memory, bypassing the register file. This mechanism eliminates the register-level dependencies and enables multi-stage asynchronous copy pipelines with explicit synchronization. We exploit this capability to overlap memory transfers with TCU computation, as illustrated in Fig. 4.

Fig. 3: Register remapping for sum of squares calculation. (a) The mma.m8n8k4 register layout. (b) Register remapping for fragment A. (c) Register remapping for fragment B.

Listing 1: Design of the squared norm calculations. template<typename T> __device__ T shufl sum squares(T src, int K){ T sum = 0; 4 for i = 0 to K-1 5 T s = _shufl_sync(MASK, src, i, K); 6 sum += s * s; 7 return sum; 8 } 9 10 template<typename T> 11 __device__ col squared norm(T dst[2],T src,int K){ 12 int lane = threadIdx.x % 32; 13 int row = lane % 8; 14 int col = lane / 8; 15 int idx = row * 8 + col; 16 T sum = shufl sum squares(src, K); 17 // Column packing 18 dst[0] = _shfl_up_sync(MASK,sum,4,8); 19 dst[1] = _shfl_down_sync(MASK,sum,4,8); 20 // Warp-level transpose 21 T m = _shfl_sync(MASK,dst[0],idx,32); 22 dst[0] = m; 23 m = _shfl_sync(MASK,dst[1],idx,32); 24 dst[1] = m; 25 } 1

2 3

all computations within the calc dfire are performed onchip, avoiding redundant data movements, and improving SM utilization. Efficient register remapping for TCU. In FP64 mma operation(Fig. 2(a)), fragA follows a row-major layout and fragB follows a column-major layout, where each thread holds one element (i.e. register). The accumulator fragC is organized in a row-major layout, where each thread holds two elements(i.e. Fig. 3(a)). These heterogeneous layout designs introduce mismatches across fragments, leading to additional data movement when computing the squared norm. We devise a lightweight register-level remapping strategy based on warp shuffle to replace these redundant data movements. Through micro-benchmark [56] evaluation on the A100 GPU, loading a 64-bit value from shared memory to a register takes approximately 23 cycles, whereas a warp shuffle takes only 2 cycles. This motivates our design to perform squared norm

Hardware

Algorithm

TABLE II: Performance model parameters for SparkleDock.

Runtime modeling. Benefiting from agent-level parallelism, the maximum parallel degree is Ns × Ng . For each agent, we divide the framework into four modules to construct the performance budget model Ttotal : (1) DFIRE score calculation (bottleneck): The projected runtime for agent g is

Description Parameters Swarm/agent num N[s/g] Receptor/ligand backbone atoms num N[r/l] ANM vector size M[l/r] lookup table / intermediate variables size M[ener/imm] Moving mask µ Throughput of CUDA kernels T H[ener/nei/move/pose] Bandwidth BWpci Number of the GPUs Ngpus Memory footprint of a double bf p

g Tener = (8 · Nl · Nr /T Hener + ⌈log2 (Nl · Nr )⌉/T Hener ) · µ, (6)

where 8 · Nl · Nr represents pairwise distance computation, binning and indexing, the ⌈log2 (Nl · Nr )⌉ represents parallel reduction in energy scoring. The binary mask µ ∈ {0, 1} randomly indicates whether agent g moves at step t: if µ = 0, the agent stays and its energy score is unchanged. (2) Docking pose preparation: It express the total runtime of prepare rec pose and prepare lig pose kernels for each agent g, denoted as

Following the above warp-level partitioning, each CUDA thread block processes a 64 × 64 tile of the pairwisedistance matrix, which is divided into four 32 × 32 pipeline buffers. Let Ab , B b ∈ R64×3 denote the corresponding receptor and ligand coordinate tiles executed by the CUDA thread block. Then, the four pipelines are denoted as T0 (Ab (0),B b (0)), T1 (Ab (0),B b (1)), T2 (Ab (1),B b (0)), and T3 (Ab (1),B b (1)), where Ab (i), B b (i) ∈ R32×3 are receptor and ligand sub-matrices in each pipeline. Within each execution pipeline, the CUDA block further computes on four 16 × 16 subtiles in Fig. 2(a) (i.e. four warps per block). To supply the four compute stages, we organize the required data transfers into three asynchronous-copy groups: C0 (Ab (0),B b (0)), C1 (B b (1)), C2 (Ab (1)). The first C0 (Ab (0),B b (0)) load Ab (0) and B b (0) from global memory to shared memory. After C0 (Ab (0),B b (0)) is finished, S0 begins the computation while the second group, C1 (B b (1)), asynchronously loads B b (1) to the shared memory. When C1 (B b (1)) completes, S1 and cp(Ab (1)) are issued concurrently. After cp(Ab (1)) completes, the remaining stages (S2 , S3 ) can proceed. The S3 pipeline calculation requires Ab (1) and B b (1), both of which are already resident in shared memory, thereby avoiding additional data transfers. Note that four pipeline buffers are used due to the limited shared memory capacity per SM.

g Tpose = (3 · (Nl + Nr ) · (7 + Ml + Mr ))/T Hpose ,

(3) Agent neighbor construction and movement: This module constructs the total runtime of calc neighbors and movement for each agent g, denoted as g Tother = Ng · Mnei /T Hnei + Mmove /T Hmove ,

Tdata = (3 · bf p · (Nr + Nl ) + M emg )/BWpci ,

(9)

where the first term is the projected data movement time (receptor, ligand, and agent vector) from CPU to GPU, and the second term is the projected data movement time from GPU to CPU. Combining the above components, the total S steps GSO runtime Tip of swarm i can be denoted as Ng −1 S−1

Tip =

X X g

g g g ) + Tdata . (Tpose + Tener + Tother

(10)

MPI can unroll the swarm loops in parallel. Therefore, the overall model in the multi-GPU environment is Nsp −1

Ttotal =

max

0≤p<Ngpus

Tip ,

(11)

i=0

where Nsp is the swarm size assigned by MPI rank p. In Ttotal , T H[·] and BWpci can be obtained through microbenchmarks, while µ of each step can be expressed by the generated docking random seed. Thus, we can project the total docking runtime using Ttotal given to the workload of each MPI rank. Insights from the performance model. We list observations from the performance model analysis. (1) Performance prediction: Ttotal can predict the runtime before docking, enabling users to plan computing resources effectively. (2) MPI load balancing: Based on Eqn 10, we can devise a

(3)

while the agent vectors are M emg = bf p · Ns · Ng · (7 + Ml + Mr ).

(8)

where Mnei denotes the computational cost of constructing the neighbor list and Mmove denotes the computational cost of movement update. (4) Data transfer: This module quantifies CPU–GPU communication cost, denoted as

C. Performance Model We build a performance model [57] to characterize both latency and memory usage of SparkleDock, with the aim of identifying the scaling constraints. The definitions of all parameters are summarized in Tab. II. Memory footprint modeling. The memory footprint of the framework comprises four components: docking poses, glowworm agent vectors, lookup table with the array length of Mener , and intermediate variables with array length of Mimm . The memory footprint of docking poses is denoted as M empose = 3 · bf p · Ns · Ng · (Nr + Nl ),

(7)

(4)

Combining these, the total GPU memory budget is M emtotal = M empose + M emg + bf p · (Mimm + Mener ). (5)

Here, Mimm and Mener are constant values. Therefore, the M emtotal provides a closed-form estimate of the memory budget given to a specific docking task.

Algorithm 3: Performance Model Guided Static Load Balancing Algorithm

Computational Workload per MPI Rank

Input : Workload queue Q[Ngpus ]; agent vectors G Output: Q[Ngpus ] 1 for p ← 0 to Ngpus − 1 do 2 Q[p].t ← 0; Q[p].idx ← ∅

Algorithm parameters:

Swarm 0 Receptor Atoms: 𝑵𝒓

Swarm 3

Swarm 2

Swarm 1

Ligand Atoms: 𝑵𝒍

Number of Swarms: 𝑵𝒔

for i ← 0 to Ns − 1 do p⋆ ← −1; Tmin ← ∞ 5 for p ← 0 to Ngpus − 1 do 6 if Q[p].t < Tmin then 7 Tmin ← Q[p].t; p⋆ ← p;

8 9

⋆

⋆ ].t + Tip

Q[p ].t ← Q[p enqueue(Q[p⋆ ].idx, i)

GPU Free Memory: 𝒇

Automatic Chunk Dvision

Chunk 1

Chunk 0

Chunk k

Swarm 0 Swarm 1 Swarm 0 Swarm 1

▷ Update via Eqn 10

Number of Agents: 𝑵𝒈

// init chunk size n_s = m; // init chunk number k = 1; // divide chunks While(mem(n_r,n_l,n_s)>=f) { k++; n_s = (m+k-1)/k; } return k,n_s ;

Memory budget 𝑴𝒆𝒎𝒕𝒐𝒕𝒂𝒍

… Swarm m

… Swarm 0 Swarm 1

Fig. 5: Performance model guided out-of-core automatic chunk division. TABLE III: Complexes used in the evaluation.

load balanced workload division strategy for each MPI rank. (3) Memory chunk division: M emtotal can effectively express the total memory footprint of each MPI rank. For large-scale docking tasks with massive memory demand, M emtotal can guide the automatic out-of-core chunk division of each MPI docking workload to handle larger tasks within a limited GPU memory.

Dataset

2VXT 3VLB 2A1A 2GTP 2X9A 1RKE 4GAM 4JCV 4LW4

Category A EI ES OG Swarms Num. 402 336 271 298 Rec Atoms Num. 3002 3052 2039 2516 Lig Atoms Num. 1274 1658 1440 1061

OR OX ER OX ES 130 294 1245 695 558 757 2030 17307 6032 6058 481 1256 1125 1766 1138

chunk size is determined, SparkleDock uses the memory pool to manage GPU memory and execute the docking process for each chunk.

D. Scaling SparkleDock on multi-GPU Platform Based on the design on single GPU and the performance model, we further design an MPI parallelization scheme to tile the swarm loop, enabling multi-GPU acceleration. Static MPI load balancing. Guided by the performance model Tip in Eqn 10, we implement the MPI setup function in Alg. 3 to statically distribute the total workload among Ngpus MPI ranks. This function first initializes the computing workload Q[Ngpus ] of each MPI rank, including the total latency Q.t, and swarm task index queue Q.idx (line 1-2). For each swarm i, the Q[p⋆ ] with the minimal current runtime is selected (line 4-7). The execution time of task i is then estimated via Eq. 10 and added to Q[p⋆ ] (line 8), while the task index i is appended to Q[p⋆ ].idx (line 9). After this setup, each MPI rank p fetches tasks from its own task queue Q[p].idx, achieving balanced workload distribution. Since the SparkleDock involves an embarrassingly parallel in swarm loop, this setup can be seamlessly integrated into the docking initialization process to achieve a static workload dispatch before simulation. Automatic out-of-core chunk division. In large-scale docking tasks, each MPI consumes substantial GPU memory, often leading to out-of-memory (OOM) errors. We devise an automatic chunk division method to enable SparkleDock to adapt to various GPU memory budgets on multi-GPU environments using M emtotal . As shown in Fig. 5, for each MPI rank, we extract the algorithm parameters to construct M emtotal . Then, we retrieve the available GPU memory f using the cudaMemGetInfo. Based on M emtotal and f , an automatic chunk division approach is designed to iteratively divide the MPI workload into multiple chunks until the memory requirement of the single chunk is less than the available GPU memory. Note that the chunk division is automatic. Once the

IV. E VALUATION A. Experimental Setup Baselines. We compare SparkleDock with LightDock-Rust, an optimized CPU implementation of LightDock that is widely used in applications such as drug discovery [58], structural prediction [59], and membrane protein modeling [6]. LightDockRust achieves an 8–10× speedup over the original Python implementation [6] and serves as a strong CPU baseline. We further devise a CUDA core implementation of the energy score computation to generalize the SparkleDock framework to GPUs without FP64 TCU support. This implementation preserves the same computational formulation but is executed entirely on standard CUDA cores, also serving as a controlled GPU baseline to evaluate the performance of the TCU implementation. All methods are evaluated using FP64 precision to ensure numerical consistency with LightDock and enable a fair comparison across CPU, CUDA-core, and TCU-based implementations. Datasets. The Protein-Protein Benchmark 5 and Affinity Benchmark Version 2 (BM5.2) [60] are used to evaluate our framework, which consists of 55 realistic unbound structures: antibody-antigen (A); enzyme–inhibitor (EI); enzyme–substrate (ES); enzyme complex with a regulatory or accessory chain (ER); others, G-protein containing (OG); others, receptor containing (OR); others, miscellaneous (OX). We select nine representative spanning all category for performance assessment, including docking tasks with smaller computational scales, like 2X9A, and larger docking tasks like 4GAM. Tab. III shows the details of these complexes.

Devices

Metrics 2VXT 3VLB 2A1A 2GTP 2X9A 1RKE 4GAM 4JCV 4LW4 Max Avg. Speedup 1× 1× 1× 1× 1× 1× 1× 1× 1× 1× 1× CPU Throughput 72.5 55.5 86.5 94.4 432.2 100.352 15.9 28.5 42.8 432.2 103.2 Speedup 9.5× 9.5× 10.6× 10.1× 9.9× 9.9× 8.9× 9.3× 9.2× 10.6× 9.7× A100 Throughput 691.9 525.6 916.6 954.5 4281.0 989.8 142.0 266.0 392.1 4281.0 1017.7 Chunk Division ✔ ✔ Speedup 17.5× 18.6× 19.2× 19.9× 20.0× 19.4× 18.2× 18.5× 18.7× 20.0× 18.9× H100 Throughput 1269.2 1031.0 1660.2 1875.2 8652.4 1946.6 289.5 527.0 802.0 8652.4 2005.9 Chunk Division ✔ -

TCU

TCU+RR

TCU+RR+PO

104 Measured Peak 8.7 TFLOP/s B/s 1.6T idth w d 3 10 Ban am Stre eak P 102 prepare_rec_pose (2.81,1055) prepare_lig_pose (6.62,3117) 1 calc_difire (221.72,2448) 10 calc_neighbors (11.94,69) movement (0.64,111) 100 5.6 101 10 1 100

Arithmetic Intensity (Flops/Byte)

102

Fig. 6: Roofline analysis of SparkleDock kernels at double precision on A100.

TCU+RR (Speedup)

TCU+RR+PO (Speedup)

5 4

3 2

A100

4LW4

4JCV

2X9A

4GAM

2GTP

1RKE

2A1A

3VLB

2VXT

4LW4

4JCV

2X9A

4GAM

2GTP

1RKE

2A1A

3VLB

0 2VXT

Speedup

Perf. (TFLOP/s)

Perf. (GFLOP/s)

TABLE IV: Summary of speedup. The baseline on CPU runs LightDock-Rust uses 40 threads; A100 and H100 GPU runs the proposed SparkleDock.

H100

Fig. 7: Step-wise breakdown of the impact of different optimizations applied to the hotspot calc dfire kernel. Here, TCU denotes the TCU-based reformulation, RR denotes register remapping, and PO denotes pipeline overlapping.

CUDA

B. End-to-End Performance Evaluation on a Single GPU

TCU

Speedup(TCU Vs. CUDA)

A100

4LW4

4JCV

2X9A

2GTP

4GAM

2A1A

1RKE

3VLB

2VXT

4JCV

4LW4

2X9A

4GAM

2GTP

1RKE

2A1A

3VLB

2VXT

Perf. (TFLOP/s)

Speedup

Environments. For baseline LightDock-Rust, we test on two 10-core Intel Xeon Silver 4210 CPUs with 40 threads. For SparkleDock, we test an NVIDIA H100-80GB GPU workstation and a multi-GPU system of up to 800 NVIDIA A100-40GB GPUs (200 nodes, each with 4 GPUs). We use CUDA 12.4 to compile SparkleDock.

H100

In this section, we evaluate the end-to-end docking performance of SparkleDock on nine representative structures using NVIDIA A100 and H100 GPUs. Since the LightDockRust baseline only supports CPU execution, we run it with 40 CPU threads. For all methods and structures, each docking simulation comprises 100 steps, and we report the mean endto-end execution time across 5 times repeated runs(after 2 times warm-up). Tab. IV shows the detailed speedup and the computation throughput of SparkleDock compared to the baseline. According to the results, SparkleDock achieves an average speedup of 9.7× and 18.9×, with corresponding throughputs of 1017.7 and 2005.9 agents/s on A100 and H100 GPUs, respectively, compared to LightDock-Rust. Meanwhile, for larger protein docking tasks like 4GAM, 4JCV, the automatic out-of-core chunk division approach can effectively split the workload into smaller chunks, preventing OOM errors during docking.

Fig. 8: Performance improvement of TCU-accelerated calc dfire(TCU) compared to CUDA core implementations(CUDA).

C. Roofline Analysis of CUDA kernels

D. Breakdown Analysis of Energy Score Calculation

We further measure the peak performance of the designed CUDA kernels. We use the representative 2VXT to perform one-step simulation and carry out roofline analysis generated

For the bottleneck calc dfire, we implement a fused TCU kernel design (TCU), register remapping for TCU(RR), and pipeline overlapping (PO). To evaluate the performance im-

by NVIDIA Nsight Compute (NCU) for these CUDA kernels on an A100 GPU. According to Fig. 6, prepare lig pose and calc dfire are the compute-bound kernels achieving over 25% of the measured peak performance. The prepare rec pose is the memory-bound kernel, achieving 92% memory occupancy according to the NCU. The performance of remaining kernels movement and calc neighbors is lower than others. The reason is that the total computations of these two modules are quite small, and the launched thread blocks are insufficient to saturate the available resources on A100. However, these kernels are not time-intensive, consuming less than 1% of the time, which results in a negligible impact on overall performance.

L-RMSD=0.606 Runtime=93.5s

100

Success Rate (%)

L-RMSD=1.695 Runtime= 192.3s

LightDock SparkleDock

Fig. 9: SparkleDock’s prediction, run on A100 GPU. The magenta ligand is experimental (X-ray crystallography); cyan is the prediction.

provement of each approach, we conduct a step-by-step breakdown analysis on A100 and H100 GPUs to compare the performance improvements of each design for nine datasets. Fig. 7 shows the detailed evaluation results. Effectiveness of fused TCU kernel design. After applying the TCU design, the calc dfire kernel achieves 669 (A100) and 1,220 (H100) GFLOP/s peak performance. Compared with the theoretical peak performance of A100 and H100, these results still show a performance gap. Further analysis revealed that the main cause of this gap to be the misalignment between the tensor core and CUDA core patterns at the register level, which introduces additional shared memory movement overhead. Effectiveness of register remapping for TCU. By further incorporating RR, calc dfire achieves up to approximately 2.7× and 3.2× speedups over the TCU design on the A100 and H100 GPUs, respectively, reaching computational throughputs of 1.80 TFLOP/s on the A100 and 3.93 TFLOP/s on the H100. These results indicate that using RR can effectively align the sum of squares computing pattern with the FP64 TCUs at the register level. By keeping intermediate operands and results in registers, RR avoids redundant data transfers through shared memory, reduces data-movement overhead, and more fully exploits the computational capability of FP64 Tensor Cores. Effectiveness of pipeline optimization. By further applying PO, calc dfire achieves up to approximately 1.3× and 1.2× speedup compared to the RR implementation on A100 and H100 GPUs, achieving the computational throughputs of 2.27 TFLOP/s and 4.60 TFLOP/s, respectively. The above results demonstrate that PO further improves the kernel performance by overlapping data transfers from global memory to shared memory with computation.

Top-100

Top-50

Top-20

Top-10

(b)

Top-5

(a)

IL-18 and 125-2H (PDB ID:2VXT)

Top-1

RGS1 and activated Gi alpha 1 (PDB ID: 2GTP)

Fig. 10: Success rate comparison versus LightDock [10].

single H100 GPU. These results demonstrate that the proposed TCU reformulation can significantly enhance the bottleneck calc dfire kernel. The performance gain on the H100 GPU is more pronounced. We analyze that the Hopper SM architecture executes Tensor Core MMA instructions and auxiliary CUDA Core instructions more efficiently, potentially improving their overlap and reducing pipeline stalls.

F. Docking Accuracy We evaluate the docking accuracy of SparkleDock. We first conduct the docking visualization evaluations for the 2GTP and 2VXT datasets as shown in Fig. 9. The magenta ligands represent the experimentally determined structures obtained by X-ray crystallography, whereas the cyan ligands represent the conformations predicted by SparkleDock. For both complexes, the predicted ligand conformations closely align with the corresponding experimental structures, indicating that SparkleDock can accurately reproduce the native binding poses. We quantify the docking accuracy using ligand root-mean-square deviation (L-RMSD), which measures the structural deviation between the predicted ligand pose and the corresponding ground-truth pose determined by X-ray crystallography. The L-RMSD values for both 2GTP and 2VXT are below 2.0 Å, demonstrating that the predicted conformations are highly consistent with the experimentally determined structures. In addition, we evaluate the docking success rates of the nine selected complexes at different ranking thresholds using DockQ [61]. According to Fig. 10, the success rates at top ranks 1, 5, 10, 20, 50, 100 of SparkleDock reach 55.6%, 88.9%, 88.9%, 88.9%, 88.9%, and 88.9%, respectively. These results are identical to those obtained by the LightDock implementation. Overall, the visualization, L-RMSD, and DockQ results demonstrate that SparkleDock preserves the docking accuracy of LightDock while substantially improving its computational performance.

E. Performance Evaluation of TCU Reformulation In this section, we further evaluate the performance of the proposed TCU-accelerated calc dfire kernel. Fig. 8 shows the detailed performance comparison between the TCU implementation and the CUDA core implementation. According to the results, the TCU-accelerated kernel achieves around 1.99× speedup on single A100 GPU and 2.43× acceleration on

TABLE V: Model accuracy validation.

STD=0.0035

Dataset Tdf ire (s) Tpose (s) Tother (s) Tdata (s) Ttotal (s) Measured runtime(s) 0.03 0.39 0.09 0.07

14.13 222.37 67.37 35.35

17.107 198.934 58.6159 33.318

6.4

6.2

2VXT

6.0 0

1000

4GAM [T]

4GAM [S]

4JCV [T]

4JCV [S]

4LW4 [T] 2VXT [T]

4LW4 [S] 2VXT [S]

128

256

15.5

4GAM

15.0 256

128

256

MPI Rank ID

STD=0.0041

STD=0.0072

8.60

8.55

4JCV 0

16.0

384

512

7.0

6.8

4LW4

6.6

8.50

0 1

128

8.65

Runtime(s)

2000

512 256 128 64 32 16 8 4 2 1

Speedup

Runtime(s)

3000

Runtime(s)

0.02 0.05 0.03 0.02

Runtime(s)

0.39 5.94 1.29 0.99

Runtime(s)

2VXT 13.70 4GAM 215.99 4JCV 65.97 4LW4 34.28

STD=0.0078

6.6

512

Number of A100 GPUs

128

256

MPI Rank ID

384

512

128

256

MPI Rank ID

384

512

Fig. 12: Load balance evaluation of MPI ranks (The green bars denote the runtime in each MPI rank).

Fig. 11: Strong scaling evaluation of SparkleDock on four complexes, where T and S denote the runtime and speedup.

We further evaluate the load balance across MPI ranks for the four datasets in Fig. 12 at the largest evaluated scale in Fig. 11. We find the computation time of each MPI rank remains consistent, with the standard deviation (STD) of 0.0035, 0.0078, 0.0041, and 0.0072 for the 2VXT, 4GAM, 4JCV, and 4LW4 datasets. These small variations demonstrate that the proposed performance model guided MPI load balancing strategy effectively spreads the workload across MPI ranks, thereby reducing synchronization delays at large GPU scales.

G. Validation of the Performance Model To evaluate the accuracy of Ttotal , we use the representative 2VXT, 4GAM, 4LW4, and 4JCV complexes to conduct the experiments on 16 A100 GPUs. According to Tab. V, the predicted docking time closely matches the measured time, with the mean absolute percentage errors (MAPEs) of 12.55%. Despite minor prediction errors caused by runtime factors such as MPI initialization and resource setup overheads that are not explicitly captured by the model, Ttotal provides sufficiently accurate estimates to guide the workload distribution strategy described in Sec. III-D.

V. C ONCLUSION

H. Scalability Evaluations

We introduce SparkleDock, a scalable framework for flexible macromolecular docking. It incorporates efficient design strategies, including fine-grained parallelism, Tensor Core (TCU) mapping, pipeline optimization, and MPI-based scaling. To our knowledge, SparkleDock is the first flexible docking framework capable of multi-GPU scaling while utilizing TCUs, enabling large-scale virtual screening. Beyond docking, we introduce an efficient design of pairwise distance computation, which is crucial in fields like machine learning and data mining. Future work will extend SparkleDock to other distributed systems(ARM-based platforms like Fugaku), and explore TCU reformulation to other domains.

In this section, we use the 2VXT, 4GAM, 4JCV, and 4LW4 to evaluate the scalability of SparkleDock. Fig. 11 shows the strong scaling evaluations for these four complexes. SparkleDock achieves 183.1×, 94.4×, and 67.0× speedups for 4GAM, 4JCV, and 4LW4 for 512 GPU scaling, respectively, and a 32.1× speedup for 2VXT for 256 GPU scaling, relative to a single A100 GPU. Compared to LightDock-Rust, SparkleDock delivers over two orders of magnitude speedup, allowing the most flexible macromolecular docking tasks to complete within one minute. For large macromolecules like 4GAM and 4JCV, SparkleDock adaptively scales across 1 to 4 GPUs without OOM issues, demonstrating the effectiveness of automatic chunk division. The variation in scaling efficiency among the four complexes is primarily attributed to the differences in workload size. In particular, the 4GAM contains substantially more computation workload, allowing each MPI rank to receive sufficient computation and better overlap initialization, data movement, and synchronization with GPU-accelerated computation. In contrast, the 2VXT has a much smaller workload. In large-scale scaling, the amount of computation assigned to each MPI rank becomes too limited to exploit the GPU acceleration and overlap the fixed communication and synchronization overheads, limiting the scaling efficiency.

ACKNOWLEDGMENT This work was supported by the National Key Research and Development Program (2025YFB4507000), the National Natural Science Foundation of China (Grant Nos. 61972416, 62272479), Taishan Scholarship (tstp20240506, tsqn202408087), Natural Science Foundation of Shandong Province (ZR2022LZH009), National Research Foundation Singapore (NRF), and the Ministry of Digital Development and Information (MDDI) under the AI Visiting Professorship (Award No. AIVP-2025-005).

R EFERENCES

vol. 68, no. 2, pp. 503–515, 2007. [Online]. Available: https: //doi.org/10.1002/prot.21419 [19] M. Ohue, Y. Matsuzaki, N. Uchikoga, T. Ishida, and Y. Akiyama, “Megadock: an all-to-all protein-protein interaction prediction system using tertiary structure data,” Protein and peptide letters, vol. 21, no. 8, pp. 766–778, 2014. [Online]. Available: https://doi.org/10.2174/ 09298665113209990050 [20] B. G. Pierce, Y. Hourai, and Z. Weng, “Accelerating protein docking in zdock using an advanced 3d convolution library,” PloS one, vol. 6, no. 9, p. e24657, 2011. [Online]. Available: https://doi.org/10.1371/journal.pone.0024657 [21] B. Pierce, W. Tong, and Z. Weng, “M-zdock: a grid-based approach for c n symmetric multimer docking,” Bioinformatics, vol. 21, no. 8, pp. 1472–1478, 2005. [Online]. Available: https: //doi.org/10.1093/bioinformatics/bti229 [22] J. Mintseris, B. Pierce, K. Wiehe, R. Anderson, R. Chen, and Z. Weng, “Integrating statistical pair potentials into protein complex prediction,” Proteins: Structure, Function, and Bioinformatics, vol. 69, no. 3, pp. 511–520, 2007. [Online]. Available: https://doi.org/10.1002/prot.21502 [23] R. Chen, L. Li, and Z. Weng, “Zdock: an initial-stage proteindocking algorithm,” Proteins: Structure, Function, and Bioinformatics, vol. 52, no. 1, pp. 80–87, 2003. [Online]. Available: https: //doi.org/10.1002/prot.10389 [24] S. J. De Vries, M. Van Dijk, and A. M. Bonvin, “The haddock web server for data-driven biomolecular docking,” Nature protocols, vol. 5, no. 5, pp. 883–897, 2010. [Online]. Available: https: //doi.org/10.1038/nprot.2010.32 [25] S. Lyskov and J. J. Gray, “The rosettadock server for local protein– protein docking,” Nucleic acids research, vol. 36, no. suppl 2, pp. W233–W238, 2008. [Online]. Available: https://doi.org/10.1093/nar/ gkn216 [26] N. A. Marze, S. S. Roy Burman, W. Sheffler, and J. J. Gray, “Efficient flexible backbone protein–protein docking for challenging targets,” Bioinformatics, vol. 34, no. 20, pp. 3461–3469, 2018. [Online]. Available: https://doi.org/10.1093/bioinformatics/bty355 [27] M. Torchala, I. H. Moal, R. A. Chaleil, J. Fernandez-Recio, and P. A. Bates, “Swarmdock: a server for flexible protein–protein docking,” Bioinformatics, vol. 29, no. 6, pp. 807–809, 2013. [Online]. Available: https://doi.org/10.1093/bioinformatics/btt038 [28] I. H. Moal and P. A. Bates, “Swarmdock and the use of normal modes in protein-protein docking,” International journal of molecular sciences, vol. 11, no. 10, pp. 3623–3648, 2010. [Online]. Available: https://doi.org/10.3390/ijms11103623 [29] S. Mitternacht, “Freesasa: An open source c library for solvent accessible surface area calculations,” F1000Research, vol. 5, p. 189, 2016. [Online]. Available: https://doi.org/10.12688/f1000research.7931.1 [30] K. Shoemake, “Animating rotation with quaternion curves,” in Proceedings of the 12th annual conference on Computer graphics and interactive techniques, 1985, pp. 245–254. [Online]. Available: https://doi.org/10.1145/325165.325242 [31] P. Doruker, A. R. Atilgan, and I. Bahar, “Dynamics of proteins predicted by molecular dynamics simulations and analytical approaches: Application to α-amylase inhibitor,” Proteins: Structure, Function, and Bioinformatics, vol. 40, no. 3, pp. 512–524, 2000. [Online]. Available: https://doi.org/10.1002/1097-0134(20000815)40: 3⟨512::AID-PROT180⟩3.0.CO;2-M [32] A. R. Atilgan, S. Durell, R. L. Jernigan, M. C. Demirel, O. Keskin, and I. Bahar, “Anisotropy of fluctuation dynamics of proteins with an elastic network model,” Biophysical journal, vol. 80, no. 1, pp. 505–515, 2001. [Online]. Available: https://doi.org/10.1016/S0006-3495(01)76033-X [33] Y. Yang and Y. Zhou, “Ab initio folding of terminal segments with secondary structures reveals the fine difference between two closely related all-atom statistical energy functions,” Protein science, vol. 17, no. 7, pp. 1212–1219, 2008. [Online]. Available: https://doi.org/10.1110/ps.033480.107 [34] J. Morrison, “Quaternion interpolation with extra spins,” in Graphics Gems III (IBM Version). Elsevier, 1992, pp. 96–97. [Online]. Available: https://doi.org/10.1016/B978-0-08-050755-2.50031-2 [35] A. Bakan, L. M. Meireles, and I. Bahar, “Prody: protein dynamics inferred from theory and experiments,” Bioinformatics, vol. 27, no. 11, pp. 1575–1577, 2011. [Online]. Available: https://doi.org/10.1093/ bioinformatics/btr168 [36] J. Choquette, W. Gandhi, O. Giroux, N. Stam, and R. Krashinsky, “Nvidia a100 tensor core gpu: Performance and innovation,” IEEE

[1] J. De Las Rivas and C. Fontanillo, “Protein–protein interaction networks: unraveling the wiring of molecular machines within the cell,” Briefings in functional genomics, vol. 11, no. 6, pp. 489–496, 2012. [Online]. Available: https://doi.org/10.1093/bfgp/els036 [2] U. Stelzl, U. Worm, M. Lalowski, C. Haenig, F. H. Brembeck, H. Goehler, M. Stroedicke, M. Zenkner, A. Schoenherr, S. Koeppen et al., “A human protein-protein interaction network: a resource for annotating the proteome,” Cell, vol. 122, no. 6, pp. 957–968, 2005. [Online]. Available: https://doi.org/10.1016/j.cell.2005.08.029 [3] J. Wang, X. Wang, Y. Chu, C. Li, X. Li, X. Meng, Y. Fang, K. T. No, J. Mao, and X. Zeng, “Exploring the conformational ensembles of protein–protein complex with transformer-based generative model,” Journal of Chemical Theory and Computation, 2024. [Online]. Available: https://doi.org/10.1021/acs.jctc.4c00255 [4] K. P. Kilambi and J. J. Gray, “Structure-based cross-docking analysis of antibody–antigen interactions,” Scientific reports, vol. 7, no. 1, p. 8145, 2017. [Online]. Available: https://doi.org/10.1038/s41598-017-08414-y [5] R.-M. Lu, Y.-C. Hwang, I.-J. Liu, C.-C. Lee, H.-Z. Tsai, H.-J. Li, and H.-C. Wu, “Development of therapeutic antibodies for the treatment of diseases,” Journal of biomedical science, vol. 27, pp. 1–30, 2020. [Online]. Available: https://doi.org/10.1186/s12929-019-0592-z [6] J. Roel-Touris, B. Jiménez-Garcı́a, and A. M. Bonvin, “Integrative modeling of membrane-associated protein assemblies,” Nature communications, vol. 11, no. 1, p. 6210, 2020. [Online]. Available: https://doi.org/10.1038/s41467-020-20076-5 [7] D. A. Antunes, D. Devaurs, and L. E. Kavraki, “Understanding the challenges of protein flexibility in drug design,” Expert opinion on drug discovery, vol. 10, no. 12, pp. 1301–1313, 2015. [Online]. Available: https://doi.org/10.1517/17460441.2015.1094458 [8] P. Śledź and A. Caflisch, “Protein structure-based drug design: from docking to molecular dynamics,” Current opinion in structural biology, vol. 48, pp. 93–102, 2018. [Online]. Available: https: //doi.org/10.1016/j.sbi.2017.10.010 [9] B. Jiménez-Garcı́a, J. Roel-Touris, M. Romero-Durana, M. Vidal, D. Jiménez-González, and J. Fernández-Recio, “Lightdock: a new multi-scale approach to protein–protein docking,” Bioinformatics, vol. 34, no. 1, pp. 49–55, 2018. [Online]. Available: https: //doi.org/10.1093/bioinformatics/btx555 [10] J. Roel-Touris, A. M. Bonvin, and B. Jiménez-Garcı́a, “Lightdock goes information-driven,” Bioinformatics, vol. 36, no. 3, pp. 950–952, 2020. [Online]. Available: https://doi.org/10.1093/bioinformatics/btz642 [11] U. Consortium, “Uniprot: a hub for protein information,” Nucleic acids research, vol. 43, no. D1, pp. D204–D212, 2015. [Online]. Available: https://doi.org/10.1093/nar/gku989 [12] B. Wu, C. Qian, W. Ni, and S. Fan, “The improvement of glowworm swarm optimization for continuous optimization problems,” Expert systems with applications, vol. 39, no. 7, pp. 6335–6342, 2012. [Online]. Available: https://doi.org/10.1016/j.eswa.2011.12.017 [13] K. Krishnanand and D. Ghose, “Glowworm swarm optimization for simultaneous capture of multiple local optima of multimodal functions,” Swarm intelligence, vol. 3, no. 2, pp. 87–124, 2009. [Online]. Available: https://doi.org/10.1007/s11721-008-0021-5 [14] S. Markidis, S. W. Der Chien, E. Laure, I. B. Peng, and J. S. Vetter, “Nvidia tensor core programmability, performance & precision,” in 2018 IEEE international parallel and distributed processing symposium workshops (IPDPSW). IEEE, 2018, pp. 522–531. [Online]. Available: https://doi.org/10.1109/IPDPSW.2018.00091 [15] D. Kozakov, R. Brenke, S. R. Comeau, and S. Vajda, “Piper: an fft-based protein docking program with pairwise potentials,” Proteins: Structure, Function, and Bioinformatics, vol. 65, no. 2, pp. 392–406, 2006. [Online]. Available: https://doi.org/10.1002/prot.21117 [16] B. Sukhwani and M. C. Herbordt, “Gpu acceleration of a production molecular docking code,” in Proceedings of 2nd workshop on general purpose processing on graphics processing units, 2009, pp. 19–27. [Online]. Available: https://doi.org/10.1145/1513895.1513898 [17] R. Landaverde and M. C. Herbordt, “Gpu optimizations for a production molecular docking code,” in 2014 IEEE High Performance Extreme Computing Conference (HPEC). IEEE, 2014, pp. 1–6. [Online]. Available: https://doi.org/10.1109/HPEC.2014.7040981 [18] T. M.-K. Cheng, T. L. Blundell, and J. Fernandez-Recio, “pydock: Electrostatics and desolvation for effective scoring of rigid-body protein– protein docking,” Proteins: Structure, Function, and Bioinformatics,

Micro, vol. 41, no. 2, pp. 29–35, 2021. [Online]. Available: https://doi.org/10.1109/MM.2021.3061394 [37] A. Dakkak, C. Li, J. Xiong, I. Gelado, and W.-m. Hwu, “Accelerating reduction and scan using tensor core units,” in Proceedings of the ACM International Conference on Supercomputing, 2019, pp. 46–57. [Online]. Available: https://doi.org/10.1145/3330345.3331057 [38] Y. Chen, K. Li, Y. Wang, D. Bai, L. Wang, L. Ma, L. Yuan, Y. Zhang, T. Cao, and M. Yang, “Convstencil: Transform stencil computation to matrix multiplication on tensor cores,” in Proceedings of the 29th ACM SIGPLAN Annual Symposium on Principles and Practice of Parallel Programming, 2024, pp. 333–347. [Online]. Available: https://doi.org/10.1145/3627535.3638476 [39] X. Liu, Y. Liu, H. Yang, J. Liao, M. Li, Z. Luan, and D. Qian, “Toward accelerated stencil computation by adapting tensor core unit on gpu,” in Proceedings of the 36th ACM International Conference on Supercomputing, 2022, pp. 1–12. [Online]. Available: https://doi.org/10.1145/3524059.3532392 [40] Y. Niu and M. Casas, “Berrybees: Breadth first search by bit-tensorcores,” in Proceedings of the 30th ACM SIGPLAN Annual Symposium on Principles and Practice of Parallel Programming, 2025, pp. 339–354. [Online]. Available: https://doi.org/10.1145/3710848.3710859 [41] B. Li, S. Cheng, and J. Lin, “tcfft: A fast half-precision fft library for nvidia tensor cores,” in 2021 IEEE International Conference on Cluster Computing (CLUSTER). IEEE, 2021, pp. 1–11. [Online]. Available: https://doi.org/10.1109/Cluster48925.2021.00035 [42] D. Wu, P. Chen, X. Wang, I. Lyngaas, T. Miyajima, T. Endo, S. Matsuoka, and M. Wahib, “Real-time high-resolution x-ray computed tomography,” in Proceedings of the 38th ACM International Conference on Supercomputing, ser. ICS ’24. New York, NY, USA: Association for Computing Machinery, 2024, p. 110–123. [Online]. Available: https://doi.org/10.1145/3650200.3656634 [43] B. Gallet and M. Gowanlock, “Leveraging gpu tensor cores for double precision euclidean distance calculations,” in 2022 IEEE 29th International Conference on High Performance Computing, Data, and Analytics (HiPC), 2022, pp. 135–144. [Online]. Available: https://doi.org/10.1109/HiPC56025.2022.00029 [44] J. Choquette, E. Lee, R. Krashinsky, V. Balan, and B. Khailany, “3.2 the a100 datacenter gpu and ampere architecture,” in 2021 IEEE International Solid-State Circuits Conference (ISSCC), vol. 64, 2021, pp. 48–50. [Online]. Available: https://doi.org/10.1109/ISSCC42613. 2021.9365803 [45] J. Choquette, “Nvidia hopper h100 gpu: Scaling performance,” IEEE Micro, vol. 43, no. 3, pp. 9–17, 2023. [Online]. Available: https://doi.org/10.1109/MM.2023.3256796 [46] R. Fan, W. Wang, and X. Chu, “Dtc-spmm: Bridging the gap in accelerating general sparse matrix multiplication with tensor cores,” in Proceedings of the 29th ACM International Conference on Architectural Support for Programming Languages and Operating Systems, Volume 3, 2024, pp. 253–267. [Online]. Available: https: //doi.org/10.1145/3620666.3651378 [47] C. Cecka, “CuTe Layout Representation and Algebra,” arXiv preprint arXiv:2603.02298, 2026. [Online]. Available: https://doi.org/10.48550/ arXiv.2603.02298 [48] H. Han, K. Li, F. Ju, Q. Li, H. An, Y. Chen, Y. Zhang, T. Cao, and M. Yang, “Matrix is all you need: Rearchitecting quantum chemistry to scale on ai accelerators,” in Proceedings of the International Conference for High Performance Computing, Networking, Storage and Analysis, ser. SC ’25. New York, NY, USA: Association for Computing Machinery, 2025, p. 2126–2142. [Online]. Available: https://doi.org/10.1145/3712285.3759829 [49] I. T. Desta, K. A. Porter, B. Xia, D. Kozakov, and S. Vajda, “Performance and its limits in rigid body protein-protein docking,” Structure, vol. 28, no. 9, pp. 1071–1081, 2020. [Online]. Available: https://doi.org/10.1016/j.str.2020.06.006 [50] H. A. Gabb, R. M. Jackson, and M. J. Sternberg, “Modelling protein docking using shape complementarity, electrostatics and biochemical information,” Journal of molecular biology, vol. 272, no. 1, pp. 106–120, 1997. [Online]. Available: https://doi.org/10.1006/jmbi.1997.1203 [51] C. Dominguez, R. Boelens, and A. M. Bonvin, “Haddock: a protein- protein docking approach based on biochemical or biophysical information,” Journal of the American Chemical Society, vol. 125, no. 7, pp. 1731–1737, 2003. [Online]. Available: https: //doi.org/10.1021/ja026939x

[52] B. Jiménez-Garcı́a, J. Roel-Touris, and D. Barradas-Bautista, “The lightdock server: Artificial intelligence-powered modeling of macromolecular interactions,” Nucleic acids research, vol. 51, no. W1, pp. W298–W304, 2023. [Online]. Available: https://doi.org/10.1093/nar/gkad327 [53] N. R. Adiga, G. Almási, G. S. Almasi, Y. Aridor, R. Barik, D. Beece, R. Bellofatto, G. Bhanot, R. Bickford, M. Blumrich et al., “An overview of the bluegene/l supercomputer,” in SC’02: Proceedings of the 2002 ACM/IEEE Conference on Supercomputing. IEEE, 2002, pp. 60–60. [Online]. Available: https://doi.org/10.1109/SC.2002.10017 [54] S. Matsuoka, T. Aoki, T. Endo, H. Sato, S. Takizawa, A. Nomura, and K. Sato, “Tsubame2.0: The first petascale supercomputer in japan and the greatest production in the world,” in Contemporary High Performance Computing. Chapman and Hall/CRC, 2017, pp. 525–555. [Online]. Available: https://doi.org/10.1201/9781351104005-20 [55] Z. Liu, W. Ni, J. Leng, Y. Feng, C. Guo, Q. Chen, C. Li, M. Guo, and Y. Zhu, “Juno: Optimizing high-dimensional approximate nearest neighbour search with sparsity-aware algorithm and ray-tracing core mapping,” in Proceedings of the 29th ACM International Conference on Architectural Support for Programming Languages and Operating Systems, Volume 2, 2024, pp. 549–565. [Online]. Available: https://doi.org/10.1145/3620665.3640360 [56] H. Abdelkhalik, Y. Arafa, N. Santhi, and A.-H. A. Badawy, “Demystifying the nvidia ampere architecture through microbenchmarking and instruction-level analysis,” in 2022 IEEE High Performance Extreme Computing Conference (HPEC). Ieee, 2022, pp. 1–8. [Online]. Available: https://doi.org/10.1109/HPEC55821.2022.9926299 [57] A. Snavely, L. Carrington, N. Wolter, J. Labarta, R. Badia, and A. Purkayastha, “A framework for performance modeling and prediction,” in SC’02: Proceedings of the 2002 ACM/IEEE Conference on Supercomputing. IEEE, 2002, pp. 21–21. [Online]. Available: https://doi.org/10.1109/SC.2002.10023 [58] M. Chatzifrangkeskou, T. Stanly, D. Koennig, L. Campos-Soares, M. Eyres, A. Hasson, A. Perdiou, I. Vendrell, R. Fischer, S. Das et al., “Atr-hippo drives force signaling to nuclear f-actin and links mechanotransduction to neurological disorders,” Science Advances, vol. 11, no. 7, p. eadr5683, 2025. [Online]. Available: https: //doi.org/10.1126/sciadv.adr5683 [59] V. Eronen, K. Takkinen, A. Torni, K. Peng, J. Jänis, T. Parkkinen, N. Hakulinen, and J. Rouvinen, “Structural insights into ternary immunocomplex formation and cross-reactivity: binding of an antiimmunocomplex fabb12 to fab220-testosterone complex,” The FEBS Journal, vol. 291, no. 21, pp. 4744–4756, 2024. [Online]. Available: https://doi.org/10.1111/febs.17258 [60] T. Vreven, I. H. Moal, A. Vangone, B. G. Pierce, P. L. Kastritis, M. Torchala, R. Chaleil, B. Jiménez-Garcı́a, P. A. Bates, J. Fernandez-Recio et al., “Updates to the integrated protein–protein interaction benchmarks: docking benchmark version 5 and affinity benchmark version 2,” Journal of molecular biology, vol. 427, no. 19, pp. 3031–3041, 2015. [Online]. Available: https://doi.org/10.1016/j.jmb.2015.07.016 [61] C. Mirabello and B. Wallner, “Dockq v2: Improved automatic quality measure for protein multimers, nucleic acids, and small molecules,” Bioinformatics, pp. 2024–05, 2024. [Online]. Available: https://doi.org/10.1093/bioinformatics/btae586

Scalable High-Fidelity Macromolecular Docking for GPU-Accelerated Supercomputers

Analyze & explore related research in Conceptio

Related documents