A couple of applications, a test-program, a benchmarker, and the Conjugated Gradient algorithm above, are built to use the SymPLA library. These applications can be moved between the architectures at will. The only customizations needed is due to differences in the standard include files which the program might need (i.e., timing), and in the compilation and build procedures.
By compiling the applications and linking them with the library, which includes the architecture specific scopes, they can be run with no difficulties on all the supported architectures. It may also be possible to use the same application object code and link it with different versions of the library on the same architecture, although at present this is neither encouraged nor has been tested.
The library and the test-applications are compiled for these compilers:
The applications have been tested on:
This shows that SymPLA is portable to a host of different computers, architectures, and compilers, as well as different numerical libraries, and as have been shown earlier, without much overhead in a number of core operations.
The internal structure of SymPLA allows the user to develop his own implementations. Among these can be using other numerical libraries, other architectures, a true client/server implementation with a central computer working as a server, an SPMD version of the code calling SymPLA, contributing their own matrices to the global operation. All of these may be implemented without much, or any change in the top level interface of SymPLA, although some changes in their use may be needed.
User extensions of the SymPLA are presently limited to redefinitions of the scope classes, and using the top-level classes as members or base classes in user classes. Potentially, extensions of functionality may be handled by a structure as the one below, which allows a developer to implement extensions in the SymPLA, while providing the same interface as the class Matrix already has.
template <class Userclass>
class CustomMatrixHandler : public MatrixHandler, Userclass{
// Declarations
};
template <class Userclass>
class CustomMatrix : public CustomMatrixHandler<Userclass>{
public:
CustomMatrixHandler<Userclass> T;
// Declarations
};
This structure does not quite handle submatrices as it should, but a small template extension of the MatrixHandler class may be enough to fix the problem.