Lisp-Stat / linear-algebra

A linear algebra library for Common Lisp
https://lisp-stat.github.io/linear-algebra
Microsoft Public License
4 stars 0 forks source link

Develop backend dispatch pattern #6

Open snunez1 opened 1 year ago

snunez1 commented 1 year ago

One of the things we're going to need is a good pattern for dispatching to various backends. Here's one possible pattern that I used for a scatterplot smoother:

 ;; What about the case where both lla and linear-algebra are loaded?
            beta #+lla (lla:solve A b)
             #+linear-algebra (linear-algebra:solve A b)
                 #-(or lla linear-algebra) (solve-matrix (aops:stack-cols A b))

As I start to use it, I think it's more of an anti-pattern because:

I know that MGL-MAT has a way to automatically dispatch methods depending on whether BLAS or CUDA are available. Generally his architecture seems similar to that of linear-algebra, with various 'kernels' (lisp, CUDA, BLAS) that are operated on by lisp code. It might be worth studying.

beberman commented 1 year ago

I think there are a handful of uses cases the libraries in lisp-stat should support: 1) User who wants to do some linear algebra manipulation and doesn't want to load a pile of libraries to do it. So basic create vector, metric, solve them, products etc. So everything in pure Lisp. linear-algebra was designed for that. 2) User who needs to scale out and do much more complex algorithms and needs the power of BLAS. LLA seems like that's its point 3) User who needs to scale-up to really large matricies that can't be held in memory easily and needs to be very careful about moving data mgl-mat was designed for that. 4) User who want t use GPU to do computation (i.e. most likely doing machine learning). So they need CUDA.

NumPy and CuPy solve this through the import trick. They use the same underlying function names and then just import it into the same name

import NumPy as np or import CuPy as np

equivalent I believe to (rename-package :cucl as :numcl) assuming the libraries in CL where named cucl and numcl.

Tensorflow does what you are suggesting. I checks if CUDA is installed and then dispatches to CUDA instead of the regular libraries.

I think the rename-package approach is much easier to maintain and extend. So I would recommend designing a common function interface on top of these packages and then document how to rename.

snunez1 commented 1 year ago

That's an interesting idea. The systems could remain separate, and yet be simply swapped out. Good thinking. I'd suggest using a package-nickname or import-from or for this, as it's closer to the Python import mechanism and causes less problems for other packages.

snunez1 commented 1 year ago

This is now agreed and we can close it once we document the pattern and provide a few examples.