The project is a redesign and reimplementation of the MTL library first developed by Andrew Lumsdaine, Jeremy Siek, and Lie-Quan Lee.
Code should be standards-conformant C++ with minimum of workarounds (assume in the future compilers will become more conformant).
Re-use SL and Boost -- but balance against run-time performance and compile times. Performance is very important, compile times only mildly important.
In general, elegance and adherence to generic programming principles is most important (more important than performance or compile time).
Use of SL and Boost should only cost minimal (preferably no) performance loss, and not add significant compile time.
The design/implementation may include development vs. release modes. For development mode, fast compile time is most important and execution time is secondary. For release mode, execution time is most important and compile time is secondary. End user should be able to switch between these with a preprocessor flag (e.g.), not change their code.
A set of refinements of linear algebra concepts that expose compile-time knowledge that can be exploited for optimization purposes. These concepts capture information such as
Fixed-size generic algorithms (as in FAST) and linear algebra (as in BLAIS) that can provide high performance within the Generic Algorithms. These must be available to users. Consider eliminating duplication with variable-size algorithms by having single algorithm implementations that can use fixed-size optimizations when the size happens to be encoded in a type.
These algorithms may be specialized for certain types or concept refinements, but they have a generic implementation, as opposed to being "intrinsic" to the types (e.g. begin()).
These operations produce a scalar (or iterator to a scalar)
Dense and sparse.
All matrices should be available in row-major and column-major variants.
[1] | Compressed sparse formats are defined in NIST sparse BLAS: http://math.nist.gov/spblas/ |
[2] | Work with OSL and David Wise researchers to determine specifics, including required data structures and applicability of algorithms and concepts. |
Provide mathematical notation interface to algorithms. Operators +, - (binary and unary), * (and / for scalars), as well as +=, -=, *=, /= are required. Integrating other (functional) operations into the expression template engine is optional.
[3] | This was marked optional in the last version of this document, but it's important enough to the overall success of the project that I've made it a requirement. |
Similar in spirit to the one used by ATLAS, this framework computes optimal blocking sizes and number of blocking levels through empirical tests. Effectiveness must be demonstrated for dense matrix-matrix product computation on x86 and PPC G5 processors.
Basic functions, similar to existing MTL 2 allowing access to LAPACK functions with MTL data types and element types float, double, complex<float>, complex<double>. E.g., the MTL algorithm:
template <class LapackMatA, class LapackMatB, class VectorInt> int gesv (LapackMatA& a, VectorInt& ipivot, LapackMatB& b)
will dispatch to the appropriate Fortran gesv function for the matrices' element types.
The following lapack algorithms must be supported:
Output format in HTML and PDF; source format TBD, at discretion of Boost Consulting.
Portable configuration and installation scheme; details TBD in cooperation with OSL. By default we will use GNU autotools on UNIX and InstallShield on Windows. Release packages to be produced in cooperation with OSL.
These items are considered low priority, and may be included or eliminated at the discretion of OSL at appropriate places in the process. Boost Consulting will notify OSL when those opportunities arise.