Paper deep dive
Scalable High-Fidelity Macromolecular Docking for GPU-Accelerated Supercomputers
Xiangyu Meng, Peng Chen, Mingzhen Li, Jianmin Wang, Sen Wang, Guangming Tan, Weile Jia, Mohamed Wahib, Tao Luo, Xun Wang
Intelligence
Status: succeeded | Model: Gemma-4-26B-A4B | Prompt: intel-v1 | Confidence: 90%
Last extracted: 8/10/2026, 4:10:22 AM
Summary
The paper introduces SparkleDock, a scalable macromolecular docking framework designed for GPU-accelerated supercomputers. It addresses the scalability limitations of existing GSO-based methods like LightDock by redesigning the algorithm for fine-grained agent-level parallelism and restructuring energy scoring computations to leverage NVIDIA Tensor Core Units (TCUs). SparkleDock achieves significant speedups (9.7x on A100, 18.9x on H100) and enables near-real-time flexible docking on up to 512 GPUs.
Entities (8)
Relation Signals (7)
SparkleDock → improvesperformanceover → LightDock
confidence 95% · SparkleDock achieves 9.7× and 18.9× speedups over LightDock on single A100 and H100 GPU
SparkleDock → usesalgorithm → Glowworm Swarm Optimization
confidence 92% · SparkleDock, a scalable GSO-based docking framework
LightDock → usesalgorithm → Glowworm Swarm Optimization
confidence 92% · LightDock leverages Glowworm Swarm Optimization (GSO) for accuracy
SparkleDock → utilizeshardware → Tensor Core Units
confidence 90% · restructure the dominant energy scoring computation into a Tensor Core-compatible formulation
SparkleDock → runson → NVIDIA A100
confidence 88% · SparkleDock achieves 9.7× ... speedups over LightDock on single A100
SparkleDock → runson → NVIDIA H100
confidence 88% · SparkleDock achieves ... 18.9× speedups over LightDock on ... H100 GPU
LightDock → usesscoringfunction → DFIRE
confidence 85% · LightDock adopts the distance-scaled, finite, ideal-gas reference state (DFIRE) [33] to calculate the interaction energy score
Cypher Suggestions (0)
No Cypher suggestions yet.
Abstract
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 $\times$ and 18.9 $\times$ 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.
Tags
Links
- Source: https://arxiv.org/abs/2608.07078v1
- Canonical: https://arxiv.org/abs/2608.07078v1
Trouble viewing inline? Open PDF directly →
Full Text
72,481 characters extracted from source content.
Expand or collapse full text
Scalable High-Fidelity Macromolecular Docking for GPU-Accelerated Supercomputers Xiangyu Meng 1,2,† , Peng Chen 3,† , Mingzhen Li 4 , Jianmin Wang 5 , Sen Wang 1 , Guangming Tan 4 , Weile Jia 4 , Mohamed Wahib 3,* , Tao Luo 2 , Xun Wang 1,* 1 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, luotao@a-star.edu.sg, wangsyun@upc.edu.cn Abstract—Flexible macromolecular docking offers high-fidelity predictions of biomolecular interactions, but remains pro- hibitively expensive at scale. Among existing approaches, Light- Dock leverages Glowworm Swarm Optimization (GSO) for accu- racy, 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 su- percomputer, Tensor cores, Strong scaling I. INTRODUCTION 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 ex- isting flexible docking algorithms, LightDock adopts a Glow- worm 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 applica- tions 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 inher- ent load imbalance, all of which hinder efficient utilization of GPU architectures and large-scale distributed systems. Limited parallelism. LightDock exposes parallelism pri- marily at the swarm level, where each swarm is processed independently. However, GSO inherently organizes the op- timization 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 swarm- level 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 be- tween atoms for each glowworm agent, resulting in quadratic complexity with respect to the number of atoms. Unlike struc- tured dense linear algebra workloads, this irregular pairwise Euclidean distance computation deviates from structured ma- trix 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 SC26, November 15-20, 2026, Chicago, Illinois, USA 979-8-3195-4789-7/26/$31.00 ©2026 IEEE arXiv:2608.07078v1 [cs.DC] 7 Aug 2026 costs. This imbalance is further amplified by swarm-level parallelism, which processes swarms independently without fine-grained workload balancing. Consequently, existing im- plementations 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, dock- ing PDB entry 4GAM generates hundreds of thousands of can- didate 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 macro- molecular docking framework, which exploits TCU accelera- tion 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 high- accuracy flexible macromolecular docking algorithm and the inherent performance and scaling limitations of GSO. Experi- mental 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 par- allelization 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 to- tal execution time), transforming it into structured matrix computations to fully exploit TCUs while preserving the original scoring semantics. • Scalability. We develop performance model guided scal- ing methods in SparkleDock for efficient load balance and chunk division under different computing scales. The rest of this paper is organized as follows. Section I reviews the background and related work. Section I presents the proposed SparkleDock algorithm. Section IV reports the experimental results. Finally, Section V concludes the paper. I. BACKGROUND & RELATED WORK A. Macromolecular Docking using GSO Macromolecular docking predicts new complexes from two known macromolecules (the receptor and ligand) using a Algorithm 1: Macromolecular docking using GSO Input : Receptor backbone R; Ligand backbone L; distance-energy lookup table θ Output: Glowworm agent vectors G 1 I ← INITSWARM(R); ▷Swarms Initialization 2 G ← INITGLOWWORM(R,L,I ); ▷G Initialization // Simulation 3 for i← 0 to N s − 1 do in parallel 4for t← 0 to S− 1 do 5for j ← 0 to N g − 1 do // Prepare docking Pose 6for x← 0 to N r − 1 do 7A (i,j) x ← UPDATERECPOS (R x ,G (i,j) ); 8for x← 0 to N l − 1 do 9B (i,j) x ← UPDATELIGPOS (L x ,G (i,j) ); // Calc DFIRE score(Bottleneck) 10D ← CALCPAIRWISEDIST (A (i,j) ,B (i,j) ); 11Idx← DISTBINNING (D); 12E (i,j) ← ACCUMULATION (Idx,θ); // Calc neighbors l & Movement 13l (i,j) ← CALCNEIGHBORS (l (i,j) ,E (i,j) ); 14G (i,j) ← CALCMOVEMENT (G (i,j) ,l (i,j) ); 15Store (G i ); sampling-and-scoring approach: (1) generating potential com- plex structures (sampling) and (2) evaluating near-native can- didates (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 cen- ters I ∈R N s ×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 N s = 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 ∈R N s ×N g ×(3+4+M l +M r ) (line 2), where N g is the number of agents per swarm. Each agent vector G (i,j) ∈R 3+4+M l +M r of glowworm agent (i,j) en- codes a candidate transformation of the receptor and ligand backbones for complex formation. It comprises a transla- tion vector α ∈R 3 , a rotation vector β ∈R 4 , and an anisotropic network model (ANM) vector γ ∈R M l +M r . α 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 2 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. MethodAlg.Addr. FlexibilityBenchmarkSystemAcceleratorTCUScalingSuccess RateRuntime PIPER [15]FFTBM2BlueGene/LPowerPC512 nodes9/42 (21%)2 min PIPER-GPU [16]FFTBM2GPUTesla C10601 GPU9/42 (21%)4 h ClusPro [17]FFTCAPRI Rds.1335GPUTesla K20C1 GPU19/42 (45%)40.8 min pyDOCK [18]FFTBM5.2(deduplicate)CPUIntel Xeon32 cores11/55 (20%)1 h MEGADOCK [19]FFTBM4TSUBAME 2.5Tesla K20X1K GPUs8/176 (4%)0.04 sec ZDOCK [20]–[23]FFTBM5(deduplicate)CPU–15/55 (27%)1.5 h HADDOCK [24]SMDCASP-CAPRICPU–16/25 (64%)≥100 h RosettaDock [25], [26]MCBM5.2CPU–41/88 (47%)65 h SwarmDock [27], [28]SIBM5.2(deduplicate)CPU–22/55(38.18%)≥36 h LightDock [9], [10]GSOBM5.2(deduplicate)CPUAMD Opteron48 cores51/55 (92.7%)3.3 h LightDock-Rust [6]GSOBM5.2(deduplicate)CPUIntel Xeon10 cores51/55 (92.7%)1.9 h SparkleDock (ours)GSOBM5.2(deduplicate)GPUTesla A100512 GPUs51/55 (92.7%)7 sec to optimize each glowworm agent according to the energy score and identifies N s × N g energetic minima (i.e. potential receptor-ligand complex structures). Each step includes dock- ing 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 calcu- late receptor poses A ∈R N s ×N g ×N r ×3 and ligand poses B ∈R N s ×N g ×N l ×3 of N s × N g 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 ∈R N r ×N l (line 10). For agent (i,j), let A (i,j) ∈ R N r ×3 and B (i,j) ∈R N l ×3 denote the transformed receptor and ligand pose. Then, D is denoted as D x,y = v u u t 3 X k=1 (A (i,j) x,k −B (i,j) y,k ) 2 .(1) Each distance value is then constructed into an index (binning) to retrieve its corresponding energy value from the pre- measured 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 ∈R N g 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 G ′ i,j from l i,j and updates its α, β, and γ. α is updated via a gradient step, β via Spherical Linear Interpolation (SLERP) [34], and γ via ProDy [35]. B. Tensor Core Units Modern GPU supercomputers equipped with NVIDIA Ten- sor Core GPUs provide unprecedented computational capa- bility for scientific applications [36]–[43]. They feature spe- cialized accelerators, Tensor Core Units (TCUs), designed to boost the performance of standard matrix multiplication and accumulation (MMA). In Ampere and above [44], [45], TCUs 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 spe- cific 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], Breadth- First 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 fun- damentally mismatched with the irregular pairwise interaction patterns in GSO-based docking. This mismatch necessitates careful reformulation to enable the efficient utilization of TCU. 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 conforma- tional changes upon binding, achieving higher accuracy at the 3 Agent-level Parallelization Chunk Division Workload 1 Scaling on Multi-GPU Systems 4 . . . 푛 푤 푤 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++) Fuse Last Loop ... Agent 0 Agent m Agent 1 Swarm 0 ... Agent 0 Agent m Swarm n ... Agent 0 Agent m TCUAccelerated Energy Score Calculation 푭풓풂품푨 Distance Mat 퓓 Energy Score Global Memory Registers TCUs Registers Global Memory Warp shuffle 2 LDS cp.async Buffer 0 Buffer 1 Buffer 2 Buffer 3 Shared Memory Rec Pose 퓐 Lig Pose 퓑 3 Performance Modeling Hardware Params Algorithm Params 퐵푊 !"# , 푁 $!%& 푇퐻 (!(&)|)+),|+)#|-(.)) 푀푒푚 $!% , 훽 푁 ('|)|*|+) , 푀 (*|+) , 휇, 푀 (-..|/0/*) Memory Budget Model: 푀푒푚 0(012 Performance Budget Model: 푇 0(012 mma Binning & Reduction MPI Load Balancing Model: 푇 0(012 Model: 푀푒푚 0(012 Performance Prediction Load Balance & Chunk Division CUDA Kernels 1.prepare_rec_pose 2.prepare_lig_pose 3.calc_dfire 4.calc_neighbors 5.movement Init Swarms Init Agents Accelerated Simulation with Agent-Level Parallelism Receptor LigandComplex Molecule Preparation 푭풓풂품푩 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 dock- ing accuracy across diverse macromolecules, enabling robust docking across proteins, peptides, and DNA. Performance and accuracy. Tab. I compares representa- tive 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, en- abling 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, HAD- DOCK 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. I. DESIGN OF SPARKLEDOCK Fig. 1 illustrates the design of the SparkleDock framework, including four stages: (1) Molecule preparation for data load- ing and pre-processing. (2) Swarm initialization. (3) Glow- worm 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 fine- grained, 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 Algorithm 2: Agent-level parallelization (same input & output as Alg. 1) // Swarm and glowworms initialization 1 for t← 0 to S− 1 do // Agent parallelism with five CUDA kernels 2for (i,j)← (0, 0) to (N s − 1,N g − 1) do in parallel // --- 3D grid computations --- 3 A (i,j) ← <GRID3D> prepare recpose(R,G (i,j) ) ; 4 B (i,j) ← <GRID3D> prepareligpose(L,G (i,j) ) ; 5E (i,j) ← <GRID3D> calcdfire(A (i,j) ,B (i,j) ) ; // --- 1D grid computations --- 6l (i,j) ← <GRID1D> calcneighbors(l (i,j) ,E (i,j) ) ; 7 G (i,j) ← <GRID1D> movement(G (i,j) ,l (i,j) ) ; 8 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, Mem total , and a performance budget model, T total , to predict memory footprint and docking perfor- mance. Finally, guided by Mem total and T total , we propose MPI load balancing and out-of-core chunk division strategies to improve the scalability on multi-GPU systems. A. Fine-grained Agent-level Parallelism The agent vectors G at each step are updated from the previous step, so the N s swarm loops and the N g 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 agent- level parallelism in Alg. 2 to accelerate the time-consuming 4 10 16 16 4 4 Frag 퐀 ퟎ X0 C0, C1 TensorCoreUnits(m8n8k4) a + + Calc Distance Squared Norm Squared Norm X0 C0,C1 퐸 #,% Warp-level Reduction 10 2 1 Lookup Table ... ... V0 V0 0 Accumulation Binning V1 b c X0 X0 X0 C0, C1 C0, C1 C0, C1 Frag 퐀 ퟏ Frag 퐁 ퟎ Frag 퐁 ퟏ Frag 퐂 ퟎ,ퟎ Frag 퐂 ퟎ,ퟏ Frag 퐂 ퟏ,ퟎ Frag 퐂 ퟏ,ퟏ Y0Z0 0 X0 Y0 Z0 0 X0 Y0 Z0 0 Frag 퐂 C0, C1 Dist Value Fig. 2: Implementation of the TCU-accelerated calcdfire 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 reorder- ing 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 N g 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 pairwise distance calculation in Eqn 1, we expand it as follows: D x,y = v u u u t 3 X k=1 (A (i,j) x,k ) 2 + 3 X k=1 (B (i,j) y,k ) 2 − 2· 3 X k=1 A (i,j) x,k ·B (i,j) y,k , (2) where the underlined term is the tall-skinny matrices multipli- cation, and the remaining terms are the squared norm(i.e. sums of squares) for matricesA andB. 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 data- independent, enabling simultaneously execution of (1) on TCUs and (2) on CUDA cores [55]. TCU kernel implementation. Based on Eqn. 2, we refor- mulate 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 N s , the gridDim.y unrolls the glow- worm agent loop N g , 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, 5 0123 C0 C1 C0 C1 C0 C1 C0 C1 C0 C1 C0 C1 C0 C1 C0 C1 C0 C1 C0 C1 C0 C1 C0 C1 C0 C1 C0 C1 C0 C1 C0 C1 a0a1a2a3 0123 a0a1a2a3 a0a1a2a3 a0a1a2a3 v0v0v0v0 v1v1v1v1 0123 v0 v1 v0 v1 v0 v1 v0 v1 v0 v1 v0 v1 v0 v1 v0 v1 v2 v3 v2 v3 v2 v3 v2 v3 v2 v3 v2 v3 v2 v3 v2 v3 v4 v5 v4 v5 v4 v5 v4 v5 v4 v5 v4 v5 v4 v5 v4 v5 v6 v7 v6 v7 v6 v7 v6 v7 v6 v7 v6 v7 v6 v7 v6 v7 a0a1a2a3 0123 a0a1a2a3 a0a1a2a3 a0a1a2a3 v0v0v0v0 v1v1v1v1 0123 0123 v0 v0v0v0 v1 v1v1v1 v0 v0v0v0 v1 v1v1v1 v6v6v6v6 v7v7v7v7 0123 Shuffle Sum of SquaresPackingWarp-level Transposev#Row/Col Sum of Squares (a) Layout of Accumulator (b) Row SquaredNorm Calculation (c) Column SquaredNorm Calculation(Column-major) v6v6v6v6 v7v7v7v7 v6v7v6v7v6v7v6v7 . . . . . . . . . . . . . . . . . . . . v6v7v6v7v6v7v6v7 . . . . 0 1 6 7 2 3 4 5 0 1 6 7 2 3 4 5 0 1 6 7 2 3 4 5 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. 1 template<typename T> 2 __device__ T shuflsumsquares(T src, int K) 3 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 squarednorm(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 sumsquares(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 all computations within the calcdfire are performed on- chip, 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 ap- proximately 23 cycles, whereas a warp shuffle takes only 2 cycles. This motivates our design to perform squared norm WaitC 0 G (0) S (0) G (1) S (1) S (0,0) R (0,0) S (0,3) R (0,3) MMA MMA ... ... Wait C 1 S (1,0) R (1,0) MMA Wait C 2 ... MMA ... T 0 (A b (0),B b (0))T 1 (A b (0), B b (1))Prologue MMA S (2,0) R (2,0) MMA G (2) S (2) S (1,3) R (1,3) S (2,3) R (3,3) T 2 (A b (1), B b (0)), T 3 (A b (1), B b (1)) cp.async: C 0 (A b (0), B b (0)) cp.async: C 1 (B b (1)) cp.async: C 2 (A b (1)) Sum of Squares / Binning / Accumulation share mem to registers TCU pipe G: Global Mem S: Shared Mem R: Register ~ ~ ~ ~ ~ ~ T 2 CUDA pipe T 3 ~ ~ ~ ~ ~ ~ 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 pro- pose a shuffle sumofsquares() method to efficiently compute the row squared norm of A, as shown in List. 1. In this algorithm, shuflsync(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 addi- tional mismatch with fragC. Since each thread corre- sponds to two column elements in fragC, we design a column-wise squared norm computation with a regis- ter packing strategy in Fig. 3(c). Specifically, we design a col squarednorm procedure in List. 1. This func- tion first invokes shufflesumofsquares() to com- pute the column-wise sum of squares for each thread (line 16). It then applies a packing approach to com- bine two column registers into one thread. Specifically, shuflupsync(4,8) shifts the even columns into the odd, while theshufldownsync(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 en- ables multi-stage asynchronous copy pipelines with explicit synchronization. We exploit this capability to overlap memory transfers with TCU computation, as illustrated in Fig. 4. 6 TABLE I: Performance model parameters for SparkleDock. DescriptionParameters Algorithm Swarm/agent numN [s/g] Receptor/ligand backbone atoms numN [r/l] ANM vector sizeM [l/r] lookup table / intermediate variables sizeM [ener/imm] Moving maskμ Hardware Throughput of CUDA kernelsTH [ener/nei/move/pose] BandwidthBW pci Number of the GPUsN gpus Memory footprint of a doubleb fp Following the above warp-level partitioning, each CUDA thread block processes a 64 × 64 tile of the pairwise- distance matrix, which is divided into four 32× 32 pipeline buffers. Let A b ,B b ∈R 64×3 denote the correspond- ing receptor and ligand coordinate tiles executed by the CUDA thread block. Then, the four pipelines are denoted as T 0 (A b (0),B b (0)), T 1 (A b (0),B b (1)), T 2 (A b (1),B b (0)), and T 3 (A b (1),B b (1)), where A b (i),B b (i) ∈R 32×3 are receptor and ligand sub-matrices in each pipeline. Within each execu- tion 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 trans- fers into three asynchronous-copy groups: C 0 (A b (0),B b (0)), C 1 (B b (1)), C 2 (A b (1)). The first C 0 (A b (0),B b (0)) load A b (0) and B b (0) from global memory to shared memory. After C 0 (A b (0),B b (0)) is finished, S 0 begins the computation while the second group, C 1 (B b (1)), asynchronously loads B b (1) to the shared memory. When C 1 (B b (1)) completes, S 1 and cp(A b (1)) are issued concurrently. After cp(A b (1)) completes, the remaining stages (S 2 , S 3 ) can proceed. The S 3 pipeline calculation requires A b (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. 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. I. Memory footprint modeling. The memory footprint of the framework comprises four components: docking poses, glowworm agent vectors, lookup table with the array length of M ener , and intermediate variables with array length of M imm . The memory footprint of docking poses is denoted as Mem pose = 3· b fp · N s · N g · (N r + N l ),(3) while the agent vectors are Mem g = b fp · N s · N g · (7 + M l + M r ).(4) Combining these, the total GPU memory budget is Mem total = Mem pose + Mem g + b fp · (M imm + M ener ). (5) Here, M imm and M ener are constant values. Therefore, the Mem total provides a closed-form estimate of the memory budget given to a specific docking task. Runtime modeling. Benefiting from agent-level paral- lelism, the maximum parallel degree is N s × N g . For each agent, we divide the framework into four modules to construct the performance budget model T total : (1) DFIRE score calculation (bottleneck): The projected runtime for agent g is T g ener = (8· N l · N r /TH ener +⌈log 2 (N l · N r )⌉/TH ener )·μ, (6) where 8· N l · N r represents pairwise distance computation, binning and indexing, the ⌈log 2 (N l · N r )⌉ 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 recpose and prepareligpose kernels for each agent g, denoted as T g pose = (3· (N l + N r )· (7 + M l + M r ))/TH pose ,(7) (3) Agent neighbor construction and movement: This mod- ule constructs the total runtime of calcneighbors and move- ment for each agent g, denoted as T g other = N g · M nei /TH nei + M move /TH move ,(8) where M nei denotes the computational cost of constructing the neighbor list and M move denotes the computational cost of movement update. (4) Data transfer: This module quantifies CPU–GPU com- munication cost, denoted as T data = (3· b fp · (N r + N l ) + Mem g )/BW pci ,(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 T p i of swarm i can be denoted as T p i = N g −1 X g S−1 X t (T g pose + T g ener + T g other ) + T data .(10) MPI can unroll the swarm loops in parallel. Therefore, the overall model in the multi-GPU environment is T total = max 0≤p<N gpus N p s −1 X i=0 T p i , (11) where N p s is the swarm size assigned by MPI rank p. In T total , TH [·] and BW pci can be obtained through micro- benchmarks, while μ of each step can be expressed by the generated docking random seed. Thus, we can project the total docking runtime using T total given to the workload of each MPI rank. Insights from the performance model. We list observa- tions from the performance model analysis. (1) Performance prediction: T total 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 7 Algorithm 3: Performance Model Guided Static Load Balancing Algorithm Input : Workload queue Q[N gpus ]; agent vectors G Output: Q[N gpus ] 1 for p← 0 to N gpus − 1 do 2 Q[p].t← 0; Q[p].idx←∅ 3 for i← 0 to N s − 1 do 4 p ⋆ ←−1; T min ←∞ 5for p← 0 to N gpus − 1 do 6if Q[p].t < T min then 7T min ← Q[p].t; p ⋆ ← p; 8 Q[p ⋆ ].t← Q[p ⋆ ].t + T p ⋆ i ▷ Update via Eqn 10 9 enqueue(Q[p ⋆ ].idx,i) load balanced workload division strategy for each MPI rank. (3) Memory chunk division: Mem total can effectively express the total memory footprint of each MPI rank. For large-scale docking tasks with massive memory demand, Mem total can guide the automatic out-of-core chunk division of each MPI docking workload to handle larger tasks within a limited GPU memory. 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 T p i in Eqn 10, we implement the MPI setup function in Alg. 3 to statically distribute the total workload among N gpus MPI ranks. This function first initializes the computing workload Q[N gpus ] 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 dock- ing tasks, each MPI consumes substantial GPU memory, often leading to out-of-memory (OOM) errors. We devise an auto- matic chunk division method to enable SparkleDock to adapt to various GPU memory budgets on multi-GPU environments using Mem total . As shown in Fig. 5, for each MPI rank, we extract the algorithm parameters to construct Mem total . Then, we retrieve the available GPU memory f using the cudaMemGetInfo. Based on Mem total 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 Swarm0 Swarm1 Swarm2 Swarm3 Swarmm ... Computational Workloadper MPI Rank Automatic Chunk Dvision Ligand Atoms: 푵 풍 Number of Agents: 푵 품 Chunk 0 Chunk 1 Chunk k Number of Swarms: 푵 풔 Memory budget 푴풆풎 풕풐풕풂풍 Swarm0 Swarm1 Swarm0 Swarm1 Swarm0Swarm1 ... Receptor Atoms: 푵 풓 Algorithm parameters: GPU Free Memory: 풇 // 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 ; Fig. 5: Performance model guided out-of-core automatic chunk division. TABLE I: Complexes used in the evaluation. Dataset2VXT3VLB2A1A2GTP2X9A1RKE4GAM4JCV4LW4 CategoryAEIESOGOROXEROXES Swarms Num.4023362712981302941245695558 Rec Atoms Num.300230522039251675720301730760326058 Lig Atoms Num.12741658144010614811256112517661138 chunk size is determined, SparkleDock uses the memory pool to manage GPU memory and execute the docking process for each chunk. IV. EVALUATION 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 pre- diction [59], and membrane protein modeling [6]. LightDock- Rust 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 im- plementation. 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 Affin- ity Benchmark Version 2 (BM5.2) [60] are used to evalu- ate our framework, which consists of 55 realistic unbound structures: antibody-antigen (A); enzyme–inhibitor (EI); en- zyme–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 per- formance assessment, including docking tasks with smaller computational scales, like 2X9A, and larger docking tasks like 4GAM. Tab. I shows the details of these complexes. 8 TABLE IV: Summary of speedup. The baseline on CPU runs LightDock-Rust uses 40 threads; A100 and H100 GPU runs the proposed SparkleDock. DevicesMetrics2VXT3VLB2A1A2GTP2X9A1RKE4GAM4JCV4LW4MaxAvg. CPU Speedup1×1×1×1×1×1×1×1×1×1×1× Throughput72.555.586.594.4432.2100.35215.928.542.8432.2103.2 A100 Speedup9.5×9.5×10.6×10.1×9.9×9.9×8.9×9.3×9.2×10.6×9.7× Throughput691.9525.6916.6954.54281.0989.8142.0266.0392.14281.01017.7 Chunk Division✔-- H100 Speedup17.5×18.6×19.2×19.9×20.0×19.4×18.2×18.5×18.7×20.0×18.9× Throughput1269.21031.01660.21875.28652.41946.6289.5527.0802.08652.42005.9 Chunk Division✔-- 10 1 10 0 10 1 10 2 Arithmetic Intensity (Flops/Byte) 10 0 10 1 10 2 10 3 10 4 Perf. (GFLOP/s) 5.6 Measured Peak 8.7 TFLOP/s Peak Stream Bandwidth 1.6TB/s prepare_rec_pose (2.81,1055) prepare_lig_pose (6.62,3117) calc_difire (221.72,2448) calc_neighbors (11.94,69) movement (0.64,111) Fig. 6: Roofline analysis of SparkleDock kernels at double precision on A100. 2VXT 3VLB2A1A 1RKE 2GTP 4GAM 2X9A 4JCV 4LW4 2VXT 3VLB2A1A 1RKE 2GTP 4GAM 2X9A 4JCV 4LW4 0 2 4 6 0 1 2 3 4 5 Perf. (TFLOP/s) Speedup TCUTCU+RRTCU+R+POTCU+R (Speedup)TCU+R+PO (Speedup) A100H100 Fig. 7: Step-wise breakdown of the impact of different optimizations applied to the hotspot calcdfire kernel. Here, TCU denotes the TCU-based reformulation, R denotes register remapping, and PO denotes pipeline overlapping. 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. B. End-to-End Performance Evaluation on a Single GPU In this section, we evaluate the end-to-end docking per- formance of SparkleDock on nine representative structures using NVIDIA A100 and H100 GPUs. Since the LightDock- Rust 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 end- to-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 au- tomatic out-of-core chunk division approach can effectively split the workload into smaller chunks, preventing OOM errors during docking. C. Roofline Analysis of CUDA kernels 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 2VXT 3VLB2A1A 1RKE 2GTP 4GAM 2X9A 4JCV 4LW4 2VXT 3VLB2A1A 1RKE 2GTP 4GAM 2X9A 4JCV 4LW4 0 2 4 6 0 1 2 3 Perf. (TFLOP/s) Speedup(TCU Vs. CUDA)TCU Speedup CUDA A100H100 Fig. 8: Performance improvement of TCU-accelerated calc dfire(TCU) compared to CUDA core implementa- tions(CUDA). by NVIDIA Nsight Compute (NCU) for these CUDA kernels on an A100 GPU. According to Fig. 6, prepare ligpose and calcdfire are the compute-bound kernels achieving over 25% of the measured peak performance. The prepare recpose is the memory-bound kernel, achieving 92% memory occupancy according to the NCU. The performance of remaining kernels movement and calcneighbors 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 satu- rate 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. D. Breakdown Analysis of Energy Score Calculation For the bottleneck calc dfire, we implement a fused TCU kernel design (TCU), register remapping for TCU(R), and pipeline overlapping (PO). To evaluate the performance im- 9 RGS1and activated Gi alpha 1 (PDB ID: 2GTP) (a) IL-18 and 125-2H (PDB ID:2VXT) (b) L-RMSD=0.606 Runtime=93.5s L-RMSD=1.695 Runtime= 192.3s Fig. 9: SparkleDock’s prediction, run on A100 GPU. The magenta ligand is experimental (X-ray crystallography); cyan is the prediction. Top-1Top-5 Top-10Top-20Top-50 Top-100 0 20 40 60 80 100 Success Rate (%) LightDock SparkleDock Fig. 10: Success rate comparison versus LightDock [10]. provement of each approach, we conduct a step-by-step break- down 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 calcdfire 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 R, 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 R 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, R 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 R 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. 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 implemen- tation 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 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, indi- cating 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 im- plementation. Overall, the visualization, L-RMSD, and DockQ results demonstrate that SparkleDock preserves the docking accuracy of LightDock while substantially improving its com- putational performance. 10 TABLE V: Model accuracy validation. DatasetT dfire (s)T pose (s)T other (s)T data (s)T total (s)Measured runtime(s) 2VXT13.700.390.020.0314.1317.107 4GAM215.995.940.050.39222.37198.934 4JCV65.971.290.030.0967.3758.6159 4LW434.280.990.020.0735.3533.318 1248163264128256512 0 1000 2000 3000 1 2 4 8 16 32 64 128 256 512 Number of A100 GPUs Runtime(s) Speedup 4GAM [T] 4JCV [T] 4LW4 [T] 4GAM [S] 4JCV [S] 4LW4 [S] 2VXT [S] 2VXT [T] Fig. 11: Strong scaling evaluation of SparkleDock on four complexes, where T and S denote the runtime and speedup. G. Validation of the Performance Model To evaluate the accuracy of T total , 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, T total provides sufficiently accurate estimates to guide the workload distribution strategy described in Sec. I-D. H. Scalability Evaluations 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, rel- ative 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 effective- ness 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. 0128256384512 6.6 6.8 7.0 MPI Rank ID Runtime(s) STD=0.0072 0128256384512 15.0 15.5 16.0 MPI Rank ID Runtime(s) STD=0.0078 0128256384512 8.50 8.55 8.60 8.65 MPI Rank ID Runtime(s) STD=0.0041 0128256 6.0 6.2 6.4 6.6 MPI Rank ID Runtime(s) STD=0.0035 2VXT 4GAM 4JCV4LW4 Fig. 12: Load balance evaluation of MPI ranks (The green bars denote the runtime in each MPI rank). 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 re- mains 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. V. CONCLUSION We introduce SparkleDock, a scalable framework for flexi- ble macromolecular docking. It incorporates efficient design strategies, including fine-grained parallelism, Tensor Core (TCU) mapping, pipeline optimization, and MPI-based scal- ing. To our knowledge, SparkleDock is the first flexible docking framework capable of multi-GPU scaling while uti- lizing 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. ACKNOWLEDGMENT This work was supported by the National Key Re- search 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). 11 REFERENCES [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, p. 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, p. 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, p. 1–30, 2020. [Online]. Available: https://doi.org/10.1186/s12929-019-0592-z [6] J. Roel-Touris, B. Jim ́ enez-Garc ́ ıa, and A. M. Bonvin, “Integrative modelingofmembrane-associatedproteinassemblies,”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, p. 1301–1313, 2015. [Online]. Available: https://doi.org/10.1517/17460441.2015.1094458 [8] P. ́ Sled ́ z and A. Caflisch, “Protein structure-based drug design: from docking to molecular dynamics,” Current opinion in structural biology, vol. 48, p. 93–102, 2018. [Online]. Available: https: //doi.org/10.1016/j.sbi.2017.10.010 [9] B. Jim ́ enez-Garc ́ ıa, J. Roel-Touris, M. Romero-Durana, M. Vidal, D. Jim ́ enez-Gonz ́ alez, and J. Fern ́ andez-Recio, “Lightdock: a new multi-scale approach to protein–protein docking,” Bioinformatics, vol. 34, no. 1, p. 49–55, 2018. [Online]. Available: https: //doi.org/10.1093/bioinformatics/btx555 [10] J. Roel-Touris, A. M. Bonvin, and B. Jim ́ enez-Garc ́ ıa, “Lightdock goes information-driven,” Bioinformatics, vol. 36, no. 3, p. 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, p. 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, p. 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, p. 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, p. 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, p. 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, p. 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, p. 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, vol. 68, no. 2, p. 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, p. 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, p. 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, p. 511–520, 2007. [Online]. Available: https://doi.org/10.1002/prot.21502 [23] R. Chen, L. Li, and Z. Weng, “Zdock: an initial-stage protein- docking algorithm,” Proteins: Structure, Function, and Bioinformatics, vol. 52, no. 1, p. 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, p. 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, p. 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, p. 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, p. 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, p. 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, p. 245–254. [Online]. Available: https://doi.org/10.1145/325165.325242 [31] P. Doruker, A. R. Atilgan, and I. Bahar, “Dynamics of proteins predictedbymoleculardynamicssimulationsandanalytical approaches: Application to α-amylase inhibitor,” Proteins: Structure, Function, and Bioinformatics, vol. 40, no. 3, p. 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, p. 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, p. 1212–1219, 2008. [Online]. Available: https://doi.org/10.1110/ps.033480.107 [34] J. Morrison, “Quaternion interpolation with extra spins,” in Graphics Gems I (IBM Version). Elsevier, 1992, p. 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, p. 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 12 Micro, vol. 41, no. 2, p. 29–35, 2021. [Online]. Available: https://doi.org/10.1109/M.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, p. 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, p. 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, p. 1–12. [Online]. Available: https://doi.org/10.1145/3524059.3532392 [40] Y. Niu and M. Casas, “Berrybees: Breadth first search by bit-tensor- cores,” in Proceedings of the 30th ACM SIGPLAN Annual Symposium on Principles and Practice of Parallel Programming, 2025, p. 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, p. 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, p. 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, p. 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, p. 9–17, 2023. [Online]. Available: https://doi.org/10.1109/M.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, p. 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, p. 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, p. 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, p. 1731–1737, 2003. [Online]. Available: https: //doi.org/10.1021/ja026939x [52] B. Jim ́ enez-Garc ́ ıa, J. Roel-Touris, and D. Barradas-Bautista, “The light- dock server: Artificial intelligence-powered modeling of macromolecular interactions,” Nucleic acids research, vol. 51, no. W1, p. W298–W304, 2023. [Online]. Available: https://doi.org/10.1093/nar/gkad327 [53] N. R. Adiga, G. Alm ́ asi, 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, p. 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, p. 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, p. 549–565. [Online]. Available: https://doi.org/10.1145/3620665.3640360 [56] H. Abdelkhalik, Y. Arafa, N. Santhi, and A.-H. A. Badawy, “Demysti- fying the nvidia ampere architecture through microbenchmarking and instruction-level analysis,” in 2022 IEEE High Performance Extreme Computing Conference (HPEC).Ieee, 2022, p. 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, p. 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. J ̈ anis, T. Parkkinen, N. Hakulinen, and J. Rouvinen, “Structural insights into ternary immunocomplex formation and cross-reactivity: binding of an anti- immunocomplex fabb12 to fab220-testosterone complex,” The FEBS Journal, vol. 291, no. 21, p. 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. Jim ́ enez-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, p. 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, p. 2024–05, 2024. [Online]. Available: https://doi.org/10.1093/bioinformatics/btae586 13