# A Neural Network-Inspired Matrix Formulation of Chemical Kinetics for Acceleration on GPUs
## 3 GPU Performance Analysis
### Improving Speedup for Large Mechanisms
The implication is that the primary reason for the rise in Component 4 budget, and thus the main contributor to the diminishing speedup for large mechanisms observed in Figure 6, is the sparsity. Figure 10 shows that the sparsity: (a) is quite significant (roughly 60%) even for small mechanisms; and (b) converges to nearly 100% with increasing \(N_{R}\). The high sparsity for large mechanisms implies an abundance of wasted arithmetic taking place in cuBLAS-based DGEMMs, which are dense operations, used for the large reaction matrix mutiplications involving the stoichiometric matrices. Therefore, a natural step is to consider different matrix multiplication algorithms that are tailored towards sparse-dense matrix products for the larger mechanisms. This brings forward one of the most useful qualities of the matrix-oriented formulations of Section 2.1--the mechanism sparsity can be integrated into the source term computation without altering the underlying matrix-based methodology. Instead, the backend used for the matrix multiplications affected by sparsity (i.e., Equations (2) and (4)) can simply be changed from cuBLAS [24] to cuSPARSE [36], a GPU-based linear algebra library optimized for sparse computations. The speedup achieved when moving to a sparse (driven by cuSPARSE) from a dense (driven by cuBLAS) matrix multiplication algorithm for Equation (2) is shown in Figure 10 (right). (Sparse-dense matrix multiplications are actively researched in the field of GPU computing, and there are many algorithms available. The one used here is based on the double-precision block sparse row-format matrix-multiplication (DBSRMM).) Note that the speedup shown in Figure 10 (right) compares two routines both executed on the GPU. Without delving into the specifics, the ultimate goal when switching to sparsity-based routines is that the savings in FLOPs should outweigh the new costs arising from algorithmic complexities and data retrieval. Based on these constraints, a general rule-of-thumb is to only use sparse algorithms when the sparsity is roughly above 95%. This quality is observed in Figure 10, which showcases significant matrix multiplication speedups for Mechanisms C1 (2\(\times\)) and C2 (4\(\times\)) in the saturated regime. Note that, when computing the sparse-to-dense speedup, the sparse compute times also include a necessary matrix transpose operation due to the fact that the cuSPARSE algorithm supports sparse-dense  
Figure 9: Computational budget (routine time normalized by total compute time) for the preprocessing routine (Component 1, blue curve), forward rate constant routine (Component 2, green curve), equilibrium rate constant routine (Component 3, red curve), and net production rate routine (Component 4, yellow curve). The results are shown for the same three mechanisms as in Figure 7.  
and not dense-sparse matrix multiplications (i.e., Equation (2) is transposed in order to use the cuSPARSE algorithm, and then the output is again transposed to conform to the data structures used in the authors' API--all of this is taken into account when computing the speedup in Figure 10). The translation of the results in Figure 10 into overall GPU-to-CPU speedup analogous to the original Figure 6--but instead using cuSPARSE as the backend for operations involving stoichiometric matrices--is shown in Figure 11. The results show that taking into account the mechanism sparsity alleviates the speedup deterioration seen before for the larger mechanisms of Class C. More importantly, all mechanisms regardless of size converge to similar speedup values in the saturated regime. Overall, it is encouraging that the relatively simple cuSPARSE backend modification significantly improves the GPU behavior for larger mechanisms. This warrants a more detailed analysis of the sparse algorithms themselves in relation to the stoichiometric matrix sparsity structures, since the distribution of non-zero values in the sparse matrix also affects the speedup. Such an analysis is left for future work.