# A Neural Network-Inspired Matrix Formulation of Chemical Kinetics for Acceleration on GPUs
## 3 GPU Performance Analysis
### Compute Times and Throughput  
Absolute GPU compute times for source term evaluation as a function of the leading matrix dimension (or number of cells) \(N_{C}\) are shown in Figure 4. Each curve is characterized by three sequential features present in all GPU-based profiles: the pre-saturated regime, the saturation point, and the saturated regime. In the pre-saturated regime, the compute time curve observes a near-zero slope with increasing computational complexity, where the effective knob for computational complexity for a given reaction mechanism is here available through \(N_{C}\). In other words, in the pre-saturated regime, the compute cost is independent of \(N_{C}\), implying that the GPU resources are not fully utilized. On the other hand, the saturated regime is characterized by a \"filling-up\" of the GPU resources where the compute time increases roughly linearly with increasing \(N_{C}\). Finally, the _saturation point_ is the marker that indicates the onset of saturated regime, i.e., the point \(N_{C}\) at which the curve roughly begins to adhere to the linear trend. In light of these three features, Figure 4 reveals many useful trends with regards to reaction mechanism complexity. Perhaps the most apparent is the expected behavior of increased GPU compute time with increasing mechanism complexity for any given \(N_{C}\)--in other words, as one traverses from mechanism A1 to C2 with \(N_{C}\) fixed, the compute time increases. Another more subtle trend lies in the \(N_{C}\)-locations of the indicated saturation points. Namely, the saturation point is correlated almost uniquely with the number of reactions, \(N_{R}\), as opposed to the number of species, \(N_{S}\). As \(N_{R}\) increases by an order of magnitude (as one moves from mechanism class A to B to C), the saturation point decreases in \(N_{C}\) by roughly the same order of magnitude factor. A similar trend is seen in the saturated regime, where, for a given \(N_{C}\) (say \(10^{5}\)), the average compute time for each mechanism class increases by order of magnitude intervals, i.e., in proportion to the increase in \(N_{R}\). Interestingly, the \(N_{R}\)-based correlation is absent in the pre-saturated regime;the general trend of increased compute time is indeed present, but, prior to saturation, increases in compute time are not proportional to same degree of increase in \(N_{R}\). This behavior is characterized the dominance of the computational budget in the saturated regime by dense matrix multiplications involving very large reaction matrices, and is discussed in more detail in Section 3.4 to motivate the usage of sparse algorithms. The information obtained from raw compute times in Figure 4 becomes much more valuable when contextualized with a direct representation of GPU performance relative to the theoretical limits of the hardware in question. This is the primary purpose of the Roofline model [35], which is the de-facto judge in the GPU computing literature for assessing saturation, GPU utilization, and throughput behavior for any given application. Figure 5a shows a typical Roofline plot. Before delving into the details of the figure, the basics of the model are first described. The reader already familiar with Rooflines may skip the next two paragraphs. Briefly, there are two primary goals of the Roofline model. The first is to assess whether or not a GPU kernel (or function) is bandwidth-limited or compute-limited, and the second is to inform whether or not the theoretical limits of the hardware have been reached by the kernel. The Roofline model illuminates both of these goals in a single plot through the _arithmetic intensity_ (\(x\)-axis of Figure 5) and _throughput performance_ (\(y\)-axis). For a given GPU kernel, arithmetic intensity is the ratio of floating point operations (FLOPs), as defined by the kernel arithmetic, to the amount of data (in bytes) transferred to and from the global memory source, as defined by the kernel inputs/outputs.