Skip to content
Soumyajit De edited this page Jan 16, 2015 · 8 revisions

Internal linear algebra library

Motivation

Linear algebra operations form the backbone for most of the computation components in any Machine Learning library. However, writing all of the required linear algebra operations from scratch is rather redundant and undesired, especially when we have some excellent open source alternatives. In Shogun, we prefer

  • Eigen3 for its speed and simplicity at the usage level,
  • ViennaCL version 1.5 for GPU powered linear algebra operations, and
  • Lapack for its robustness and maturity.

For Shogun maintainers, however, the usage of different external libraries for different operations can lead to a painful task.

  • For example, consider some part of an algorithm originally written using Eigen3 API. But a Shogun user wishes to use ViennaCL for that algorithm instead hoping to obtain boosted performance utilizing a GPU powered platform. There is no way of doing that without having the algorithm rewritten by the developers using ViennaCL, which leads to duplication of code and effort.
  • Also, there is no way to do a performance comparison for the developers while using different external linear algebra libraries for the same algorithm in Shogun code.
  • It is also somewhat frustrating for a new developer who has to invest significant amount of time and effort to learn each of these external APIs just to add a new algorithm in Shogun.

Features of internal linear algebra library

Shogun's internal linear algebra library (will be referred as linalg hereinafter) is a work-in-progress attempt to overcome these issues. We divided the supported linear algebra operations under several modules in linalg to

  • provide a uniform API for Shogun developers to choose any supported backend without having to worry about the syntactical differences in the external libraries' operations,
  • handle native Shogun types for linear algebra operations without having to convert to external types,
  • have the backend set for each operations at compile-time (for lesser runtime overhead) and therefore intended to be used internally by Shogun developers.

The operations can be used in two ways:

Relying on globally set linalg backend

shogun::linalg::operation(arg1, ...);
  • Global setup is used whenever an operation does not specify a particular backend.
  • Preferred backend can be specified via cmake options which sets globally for all the linalg operations used in this fashion.
# this will set Eigen3 as the global linalg backend for all modules.
# Use -DUSE_VIENNACL for setting ViennaCL as global linalg backend instead
#
# [for other cmake options, please refer to the cmake wiki.]
cmake -DUSE_EIGEN3
  • Module specific global setups can also be possible which is again set via cmake options. We presently have 2 modules - Core and Redux.
# this will set Eigen3 for Redux module's global linalg backend
# and ViennaCL for Core module's global linalg backend.
cmake -DUSE_EIGEN3_REDUX -DUSE_VIENNACL_CORE
  • If no particular setup is specified via cmake options (or only one module specific setup is specified), a Default backend (Eigen3 at this moment) is used for the unspecified modules.

Using operation specific linalg backend

shogun::linalg::operation<Backend::backend_name>(arg1, ...);
  • It is possible to use a specific backend for some particular operation, which then ignores the global or module specific setup and works with that particular backend.
Clone this wiki locally