Variación diurna de la Presión intraocular y del Espesor central de

Nearly every big data matrix in real-world applications is sparse. Hence, the majority of matrix elements is zero and does not need to be considered in any matrix operation. Examples are the sparse Hamiltonian matrix H, the sparse term-document matrix A, or the adjacency matrix G of a network graph, described in our application sections 2.2- 2.3.2. For readers interested in further examples of sparse matrix data, we refer to the Florida Sparse Matrix Collection (Davis and Hu, 2011).

In the context of a column-oriented database engine, one could argue that any sparse matrix con- tained in a dense representation as of Figure 3.3a or Figure 3.3b can just be compressed to obtain a space-efficient storage representation. For instance, by applying an order-preserving compression algorithm on the individual columns. However, the approach of storing a sparse matrix by using a “dense representation plus compression” is unfavorable. In the first instance, sparse matrix input data does usually not contain any zero values. Hence, it is inconvenient to artificially insert zero values just to compress them in a later step. Furthermore, a general purpose compression algorithm such as RLE generates an encrypted compressed structure that must be decompressed before the data can be further processed, e.g., in a matrix operation, adding further overhead to the total exe- cution time. In contrast, there are compressed data representations that are specially designed for sparse matrices, and most matrix algorithms directly work on these compressed data structures.

Note that we will not provide an extensive overview of every available specialized matrix struc- ture within this thesis. Instead, we first present two approaches that seamlessly integrate with the column-oriented storage layer, and revisit the topic of sparse matrix structures when we introduce our advanced matrix representation in Chapter 5. For a more complete overview and detailed de- scriptions about other sparse matrix representations we refer to the work of Saad (1994).

Triple Representation

One way to represent a sparse matrix is by a collection of triples (Fig. 3.3c), where each triple con- tains the row and column coordinate, and the value of the corresponding non-zero matrix element:

0 1 1 1 3 0 1 2 3 4 Row [0..1) [1..4) [4..5) Row Compression 0 1 4 4 0 1 2 3 4 RowPtr ₁ 0 2 3 0 0: 1: 2: 3: 4: Col

Compressed Sparse Row (CSR)

2.2 1.2 3.2 1.1 3.8 Val

Figure 3.4: The CSR representation. Left: Compression of the row container. Right: The row pointer vector (RowPtr). The access path to the first matrix row is sketched.

⟨row, col, val⟩. The unordered “triple table” corresponds to the n-tuple table for n = 2-dimensional arrays, except that only the non-zero matrix elements are stored. In the column-oriented storage layer the triple table is represented by three separate columns (Fig. 3.3c1). Additionally, a composite key constraint on the row and col attributes can be leveraged to avoid duplicate matrix elements.

The resulting internal column structure is also known as the coordinate format (COO), which is a supported sparse matrix type in some numerical libraries (e.g. NISTb, n.d., and its derivatives). Each of the columns has the length Nnz, which is equal to the number of non-zero matrix elements.

By using long integers for the row and col attributes, and double type for val, the total memory consumption is Nnz· 24 bytes. To find an element in an unsorted, non-indexed triple table a full

column scan is required in O(Nnz)time.

As mentioned before, the concept of having a unordered set of triples is obstructive for the development of efficient matrix algorithms. In particular, the triple table representation reveals ad- ditional compression and indexing opportunities, when it is sorted by one of the two coordinates. The sort generates adjacent chunks of identical numbers in the corresponding row, or col column, which can further be compressed, and replaced by an index. However, these transformations are significantly mutating the triple representation, and influence both the update and algorithmic be- havior. Hence, the compressed format is considered as a separate representation.

CSR Representation

Consider a matrix in the triple representation as of Figure 3.3c1, which is sorted according to the row major order. Due to the ordering, the row column contains adjacent chunks of identical matrix row indices. This allows us to replace the column by a smaller row pointer (RowPtr) structure that only contains the start positions of each matrix row, as shown in Figure 3.4. To put it differently, the row pointer is an effective compression of the sorted row column. However, the major role of the row pointer is to act as an index for the matrix: the physical position of a matrix row in the column and value attribute of the triple table are obtained by only two look-ups in the RowPtr. For instance, to get all elements of matrix row 1, each triple starting from position RowPtr[1] up to position RowPtr[2]-1 is returned. The row pointer vector itself has size m + 1 for a m × n matrix, where the (m + 1)th_{element denotes the end position of the last row.}

The resulting physical structure as of Figure 3.4 is identical to a widely used format for storing sparse matrices, called compressed sparse row format (CSR, aka. CRS – compressed row storage).

It first appeared in the literature as the data structure in the description of a sparse matrix multipli- cation algorithm by Gustavson (1978). Due to the simple and efficient layout, CSR remained one of the most popular sparse matrix representations supported by many numeric libraries, including the original sparse Blas NISTb (n.d.). Moreover, Vuduc (2004) found that CSR-based algorithms tend to have the best performance for sparse matrix vector multiplications. The total memory consump- tion of the CSR representation is (16Nnz+ 8(m + 1))bytes. Hence, it is lower than that of the

triple format given that (m + 1) ≤ Nnz, which is always the case except for hypersparse matrices

that contains rows of zeros (“empty” matrix rows).

A complementary format to CSR is the compressed sparse column (CSC) format (Barrett et al., 1994; Saad, 1994). Simply put, CSC is the column-major equivalent to CSR. Interestingly, the CSC representation of a matrix A is equal to the CSR representation of the transposed matrix AT_{, and}

vice versa. As a consequence, some algorithms written for CSR matrices can be used as well for CSC matrices in a slightly modified way, e.g. by a prior transformation of the operation into the transposed problem. We will address this row-major/column-major dualism in greater detail in Section 3.4.4.

Besides CSR/CSC, there are many more storage formats for sparse matrices. As mentioned be- fore, a comprehensive list of different types can be found in related work (Saad, 1994; Vuduc, 2004). However, the efficiency of a storage representation strongly depends on the specific topology of the matrix, since there are typical, recurring shapes, such as diagonal, block diagonal or blocked ma- trices. In particular, many representations are well designed for distinct non-zero patterns (the distribution of non-zero elements in the matrix), such as band or diagonal-dominated matrices, but are poorly suited for general matrices, which are rather uniformly populated. Therefore, we mostly adhere to CSR to represent homogeneous, general-purpose sparse matrices in a read-optimized way. Among the reasons for this selection are the universality, simplicity (Saad, 1994), and good perfor- mance of CSR for multiplication operations (Vuduc, 2004), but primarily that it can be seamlessly integrated into the column-oriented storage layer. Based on that, however, we will present a su- perior, heterogeneous data structure that internally consists of multiple CSR and dense arrays as substructures in Chapter 5.