Overview of the Implementation
This section provides a high-level guide to the major components of this implementation.
More...
|
Modules |
| Matrix Types |
| The matrix types module implements an internal run-time database of matrix types available to the library implementation.
|
| Kernel Implementations |
| Describes the generic, matrix type-independent kernel implementations called by the user.
|
| Tracing Module |
| This module implements a run-time database facility for keeping track of kernel calls.
|
| Tuning Module |
| This module implements a run-time manager for applying automatic tuning heuristics.
|
| Auxiliary Routines |
| Provides system-wide utilities for memory allocation, error-handling, BLAS wrappers, dynamic library loading, timers, etc.
|
Detailed Description
This section provides a high-level guide to the major components of this implementation.
Users interact with the library through a sparse matrix handle,
oski_matrix_t, implemented in this library as a pointer to a
oski_matstruct_t data structure. This structure in turn contains generic matrix properties (dimensions, number of logical non-zero elements, whether it is symmetric, Hermitian, or triangular) as well as pointers to concrete matrix representations (i.e., the actual sparse data structures). We refer to the possible concrete data structures as `matrix types'. The
Compressed Sparse Row (CSR) Format is an example of such a matrix type.
In addition, users must allocate their own dense vector and multivector arrays, and wrap these in so-called vector views, oski_vecview_t (see oski/vecview.h).
The library implementation is logically divided into the following major components:
- MATTYPES: Each available sparse data structure is referred to as a 'matrix type' and is implemented in its own module. For example, see Compressed Sparse Row (CSR) Format.
- KERNELS: Each matrix type has one or more kernel implementations associated with it. All matrix types must define the sparse matrix-vector multiply kernel, and may optionally define additional kernels (such as sparse
). - TRACING: This component defines the implicit monitoring/profiling infrastructure.
- TUNING: This component defines the heuristic model evaluation system.
- AUXIL: This component provides additional functionality to the whole library, including routines for dynamic library module loading, debugging, error handling, memory allocation, timing modules, and wrappers around the denes BLAS routines, among others.