## 4 Results
### Performance
#### 4.2.2 LBM Performance
To estimate overheads for computations on sparse geometries, we define the _sparse computational efficiency_  
\[\eta_{P}=\frac{P(\text{sparse geometry})}{P(\text{dense geometry})}, \tag{9}\]  
where \(P(\text{sparse geometry})\) and \(P(\text{dense geometry})\) denote measured performances for the same data layout and geometry size. It should be noted that \(\eta_{P}\) does not take into account that the number of computational nodes in the sparse geometry is lower than in the dense one which may have an additional impact on performance. However, for dense data layouts, the memory is allocated for all nodes regardless of node type. Thus, the definition in Equation (9) seems reasonable. Figure 7: Examples of sparse geometries with \(4096^{2}\) nodes and porosity \(\phi=0.4\). Pressure boundary conditions were set on the inlet (**left** wall, \(\rho=1.016\)) and outlet (**right** wall, \(\rho=1.0\)), bounce back on the top and bottom walls and on borders of obstacles, viscosity \(v=0.5\). Colours correspond to the velocity magnitude after \(10^{6}\) time steps; a logarithmic scale is used. Calculations took about half an hour per geometry. The obtained performance results are shown in Figure 8. As can be seen, for all layouts but tile, the performance gradually drops with porosity. This performance decrease shows that the geometry sparsity introduces overheads, for example, creates redundant memory traffic caused by neighbouring solid and non-solid nodes, which are visible even after using data layouts (e.g., bitmasked) eliminating explicit operations for solid nodes.It should also be noted that the performance depends not only on porosity but also on the placement of solid and non-solid nodes. For randomly placed obstacles, the measured performance was slightly higher than for the regular placement, because randomly placed circles formed large, solid areas that minimised the interlacing in memory of the data for solid and non-solid nodes. Only for the tile layout, the performance was practically constant for porosities \(\phi\geq 0.4\), which suggests that for the tile layout, other factors limit performance, as shown in Figure 6 for large geometry. The lowest performance was observed for the pointer tile layout. For porosity 0.1, the performance dropped to 25% of performance for dense geometry. However, in contrast to other layouts, performance for the pointer tile layout has the lowest differences between geometries with regularly and randomly placed obstacles. It may suggest additional overheads not connected with a sparsity of geometry, although more detailed research is needed. Figure 8: Performance of GPU simulations (**top**) and sparse performance efficiency (**bottom**) for single-precision numbers, different data layouts, and sparse geometries with 4096\({}^{2}\) nodes and different porosities. For a given data layout, the lower sequence of points shows performance for regularly placed circles, and the upper points correspond to performance for randomly placed circles. Reference performance for tile-based implementations optimised for sparse geometries is adapted from (16) (ref_A) and (17) (ref_B), accordingly. Performance for implementation from (17) is for GTX Titan XP, D3Q19 lattice arrangement and single-precision numbers, whereas work (16) uses double-precision, both D2Q9 and D3Q19 lattices, and different GPU (GTX TITAN) thus positions of markers (triangles) result from \(U_{B}\) only. Figure 8 also contains reference results from [16; 17] for high-performance, tile-based GPU implementations optimised for sparse geometries. In many cases, the tile-based implementations with low-level optimisations outperform all Taichi versions, but the presented values should be compared carefully. Performance of implementation from [17] was measured for similar geometries (randomly arranged spheres) and the same data type and GPU as in the current work, but for a different lattice arrangement (D3Q19).