Our great sponsors
-
-
cl-blapack
cl-blapack is a set of common lisp bindings to blas and lapack. This particular repo tracks modifications of Evan Monroig's modifications of rif's cl-blapack library.
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
-
numericals
CFFI enabled SIMD powered simple-math numerical operations on arrays for Common Lisp [still experimental]
-
The first that comes to mind is numcl. This works if (i) performance is not seriously a concern, (ii) you are not annoyed by julia-like JIT/JAOT compilation delays, (iii) copy-based slicing won't be a performance issue for you. To be fair, limitation (i) might be overcome by writing a better (simd-based) backend for numcl. numcl is fast, it compiles to fairly good code, but simd can boost the performance by another 4-8 times or so.
Most of the implementations of Common Lisp support some form of calling C libraries, why not to call these libraries directly if you need them? There is a plethora of Github repositories from people who tried to wrap BLAS/LAPACK only to realise how much effort it is to write all the bindings and maintain them (e.g. here: https://github.com/blindglobe/cl-blapack ). You can take inspiration from it, though.
Then there is a question - do you actually need these libraries? You can optimize code in Common Lisp (type declarations, usage of appropriate data structures, SIMD instructions etc). See this: https://github.com/digikar99/numericals/tree/master/sbcl-numericals <- SIMD instructions used from SBCL (on x86; these are processor-family specific so Apple M1 will have different ones).
Second up is magicl, especially useful if performance is a concern. This might not be as extensive as numcl, but it's been battle tested in the industry over the last decade or so. Because this uses generic functions, so long as you are using not-very-small arrays, performance should not be a concern for you. And even if you are, you could write your own functions that use the low-level functions that magicl's backends define. Otherwise performance can be at par with numpy.
If performance is absolutely not a concern, then third option is using python libraries through py4cl/2. To put it differently, if calling python from lisp is not the bottleneck, then this is a feasible option.
If performance is absolutely not a concern, then third option is using python libraries through py4cl/2. To put it differently, if calling python from lisp is not the bottleneck, then this is a feasible option.