Matrix Design, Features and Performance

The linear algebra part of ojAlgo is one of its main attractions. There are several other Java libraries available that offer corresponding functionality. This page gives some information regarding how ojAlgo compares to the others in terms of design, features and performance.

The only alternative Java linear algebra library mentioned by name here is JAMA. It was developed by The MathWorks and National Institute of Standards and Technology (NIST) with the intension that it would someday be the standard matrix class (I assume) available with the core Java distribution. This did not happen, but the source code is available and released to the public domain.

The JAMA source code is part of ojAlgo. It is used to compare computation results and performance, and in some cases to access featues not available in (other parts of) ojAlgo. JAMA's main feature/contribution is that it makes available matrix decomposition algorithms – even Singular Value and Eigenvalue decompositions. The authors themselves say that JAMA is pedagogical in nature with straight forward and readable code, and that it should provide reasonable execution speed for small to moderate size applications. I find that to be mostly true. ojAlgo (or any other) matrix package must offer features or performance that JAMA does not.

Design Comparison

While JAMA simply has a "Matrix" class ojAlgo has split the design to several parts and separated between interfaces (design) and classes (implementation). This gives you, as a developer, possibilities that JAMA simply does not offer. The main linear algebra components of ojAlgo are BasicMatrix, MatrixStore / PhysicalStore and MatrixDecomposition.

ojAlgo extensively uses parameterized types (which requires Java 1.5) and simultaneously maintains matrix implementations for double (primitive), BigDecimal and ComplexNumber.

ojAlgo has no, as in zero, dependencies! Many other Java linear algebra libraries depend on one or more third party libraries. Possibly even libraries written in C or Fortran.

Features Comparison

Decompositions – which kinds are available, and for which element types?

The table below shows that ojAlgo contains the five most commen matrix decompositions, and that four of them are (also) available for BigDecimal and ComplexNumber elements. The numbers in the table's body cells indicate the number of different implementations there are for that combination of decomposition and element type.

Some linear algebra libraries don't supply any (or just limited) decomposition implementaions other than what they've borrowed from other libraries. ojAlgo has "taken" all the decompositions available with JAMA, but also supplies own implementations.

Performance Comparison

The ojAlgo project maintains performance tests that compare ojAlgo to JAMA. The reason these tests exist is to make sure ojAlgo is not unnecessarily slow. If any single operation is (significantly) slower with the "native" parts of ojAlgo than with the JAMA part, it is assumed that there is a fixable problem – and the problem is fixed. Some versions ago there were a lot of performance problems that needed fixing. Currently native ojAlgo is equivalent to or faster than JAMA on every single operation that the tests meassure – basic matrix operations, instantiation and decompositions. With matrix decompositions the difference is sometimes significant.

Matrix Decomposition Performance Comparison

This is a performance comparison for Cholesky, LU, QR & Singular Value decompositions between JAMA, which is included in ojAlgo, and ojAlgo's own/native implementations. The numbers presented stem from a test execution that was done just before releasing Version 22.

The matrices used have 1,000,000 elements. The square matrix is 1,000 x 1,000, the tall 10,000 x 100 and the fat 100 x 10,000. Each calculation is done 10 times in a loop. When solving the right hand side (RHS) is the same as the original matrix (the one that was decomposed).

JAMA's Singular Value Decomposition algorithm performs better than ojAlgo's "native" implementation on square matrices. It is roughly twice as fast in this case. That's it for JAMA...

These tests have been repeated many times with various sized matrices. You don't get the exact same result with each test run, but there is a clear pattern. Generally ojAlgo is favoured by larger matrices, and having (many) more rows than columns – tall matrices – also favours ojAlgo. The ojAlgo QR implementation performs very well on matrices of all shapes. When everything is to ojAlgo's advantage it can be 10 to 15 times faster than JAMA.

The source code for these tests is in CVS. Get the TestProj module, and look in the performance.matrix.decomposition package. There are also more complete test results available in this xml file (junit results output). As mentioned before there are tests to meassure many different aspects of performance. The results of all the current performance tests are in that same xml file and the source code is the TestProj CVS module. In no way are any of these tests designed to favour ojAlgo. The resason the tests exist is to help find areas where ojAlgo needs improvement.

Summary

Compared to JAMA; ojAlgo has significantly generalised the design, introduced new features and increased performance. The combination of those improvements, and the fact that ojAlgo actually includes JAMA, should make ojAlgo an interesting alternative to most users.

Project and site sponsored by Optimatika
Copyright © 2000 - 2008

Using JProfiler from ej-technologies