faer-rs VS dfdx

On the contrary, it seemingly can be used to make a BLAS implementation (example in a PR: https://github.com/sarah-ek/faer-rs/pull/37)

see the official website and the docs.rs documentation for code examples and usage instructions.

`faer` is a collection of crates that implement linear algebra routines in pure Rust. the aim is to eventually provide a fully featured library for linear algebra with focus on portability, correctness, and performance.

see the [official website](https://faer-rs.github.io) and the docs.rs documentation for code examples and usage instructions.

---

this release implements the initial design of the high level api (see https://docs.rs/faer/0.11.0/faer/), which should allow users to get started with writing easy to read code without having to deal with managing memory or multithreading settings on their own.

i also added a thin compatibility layer with ndarray and nalgebra. this way users are able to mix and match libraries if they wish to do so, or to help with migration to different libraries

Faer is comparable to Eigen in most of their benchmarks, so they are getting closer.

performance compared to openblas is shown in the benchmarks on the repository, and on the website. (ndarray is using openblas)

currently working on a very efficient linear algebra library https://github.com/sarah-ek/faer-rs

I keep checking the progress on dfdx for this reason. It does what I (and, I assume from context, you) want: Provides static checking of tensor shapes. Which is fantastic. Not quite as much inference as I'd like but I love getting compile-time errors that I forgot to transpose before a matmul.

It depends on the generic_const_exprs feature which is still, to quote, "highly experimental":

https://github.com/rust-lang/rust/issues/76560

Definitely not for production use, but it gives a flavor for where things can head in the medium term, and it's .. it's nice. You could imagine future type support allowing even more inference for some intermediate shapes, of course, but even what it has now is really nice. Like this cute little convnet example:

https://github.com/coreylowman/dfdx/blob/main/examples/night...

And for transformers, it's really early days for dfdx, but it's a library that aims to sit basically at the Pytorch level of abstraction, that the difference is it's not just coded in Rust, but it follows the Rust-y/functional-y philosophy of "if it compiles it runs".

Wow that is super interesting. I actually tried to use GATs at first to be generic over shapes, but I couldn't do it, I'm sure it would be possible in the future though. There is this library dfdx that does something similar to what you mentioned, but it feels a little clumsy to me.

Awesome, I added an issue here https://github.com/coreylowman/dfdx/issues/597. We can discuss more there! The first step will just be adding the device and implementing tensor creation methods for it.

The next release of dfdx includes a CUDA device and implements many ops. The same dev created a new crate, cudarc, for a wrapper around CUDA toolkit.

A question I have is: what are the philosophical/design differences with dfdx? As someone who's played around with dfdx and only skimmed the README of burn, it seems like dfdx leans into Rust's type system/type inference for compile time checking of as much as is possible to check at compile time. I wonder if you've gotten a chance to look at dfdx and would like to outline what you think the differences are. Thanks!