Consider consolidating some effort with nalgebra?

[Andlon]

Hi there, I unfortunately missed the chance to comment on your Reddit announcement post in a timely manner, but I've had your efforts here in the back of my mind since then.

I'm a co-maintainer of nalgebra. I'm using nalgebra for my research on finite element methods applied to computational mechanics (elasticity, contact problems etc.). We have a number of plans for making nalgebra more suitable use for scientific computing, but we're stretched awfully thin - although we have many contributors who help out with small fixes and PRs, we have too few people with the skill set required to drive the bigger changes and to review non-trivial pull requests. My own ability to allocate time to the library is very limited these days. Given the small number of people with the necessary skill set to drive development in scientific computing, I think it would be great if we could consolidate our efforts more when our goals are shared.

I'm not asking you to contribute to nalgebra (although I'd love for that to happen) - I understand very well the allure of starting fresh and building something unhindered by backward compatibility concerns and a large code base that needs to be adapted. I also very much understand the desire for something akin to expression templates - heck, I've written no less than five prototypes for an expression system in Rust myself, but I've never been able to commit the time to going beyond a prototype. I do have many thoughts on this topic, however - it would be great to discuss that further although that is beyond the scope of this issue.

However, I would like to ask you if you would consider contributing some of your effort in a form that nalgebra can take advantage of it as well, similar to how matrixmultiply is used across the ecosystem. For example, for native factorizations it would great to have a relatively lower-level library that would provide factorizations that could be used in different higher-level linear algebra libraries across the ecosystem. This way we could consolidate efforts for the lower-level high-performance parts while having different high-level interfaces for different purposes in the form of nalgebra, householder etc.

Tangentially, your name (@tbetcke) came up during a brief discussion with @jedbrown lately. I think it would be great to have a common communication channel dedicated scientific computing in Rust, in part for the purpose of consolidating efforts like these. Something like a low-maintenance Zulip/Discord or something else maybe? nalgebra has a fairly vibrant community through the @Dimforge Discord server, but a relatively large proportion of users are (hobby) game developers, whereas I've been wanting for a dedicated community focused specifically on scientific computing. If this is of any interest to you, then please feel free to get in touch!

[tbetcke]

Hi, thanks for reaching out. I like nalgebra a lot. It is a great library.

I agree that there are benefits to contributing to nalgebra. Before starting this library I looked at how nalgebra was implementing certain routines.

The main motivation for us to start separately was to start a project that is focused around expression templates where possible. Also, our aim in the linear algebra is to provide core decmpositions as blocked multi-threaded implementations to cover the range of matrix sizes, where single-core routines such as those in nalgebra are not sufficient, but using the full Blas/Lapack stack not necessary (it comes with a lot of deployment headaches when used within mixed Python/low-level language environments).

We have some external funding available for Householder and develop it very much as a Rust replacement for Eigen for ours (and hopefully other people's) needs.

But especially in terms of dense decomposition there may be lots of allure to try to come up with a package similar to matrixmultiply that has a generic interface to share across projects, can replace Lapack bindings and is sufficiently performant for many use cases (we won't beat Lapack, but that would not be the goal). I would be fully behind such a project and happy to contribute and use that as backend for Householder.

Setting up a discussion channel to exchange ideas about linear algebra stacks in Rust would be great. I am very much in favour.

I was also discussing at some point with @jedbrown to start organising some online meetups about Rust for Scientific Computing. A meet-up on core linear algebra stacks might be a great start to such a series.

[Andlon]

Thanks for the very swift response, and for elaborating on your goals with householder. It's really great to see external funding dedicated to building out the scientific computing ecosystem in Rust. I'm also relieved that you're open to the idea of consolidating some efforts in lower-level packages.

What you're describing is also a bit of a sweet spot that I've also been wanting for. Typically I don't necessarily need maximum performance, but something close without the hassle and inherent issues of BLAS/LAPACK depedencies. I'm excited to see what comes out of householder!

I'd be 100% behind those online meetups, and I can think of a few colleagues/friends who'd likely want to join as well. Coupling occasional synchronous meetups with a more permanent asynchronous channel (Discord/Zulip/whatever) sounds like a good match. I'd be happy to set aside a little bit of time for setting up such a channel if this could be helpful - though we'd have to decide on the technology stack first. Perhaps @jedbrown also has some thoughts on the matter here.

[jedbrown]

I guess I'm less stressed about the BLAS dependency since BLIS (https://github.com/blas-lapack-rs/blis-src/) has been pretty pain-free if you have a C compiler. But I live in a world where some C code is unavoidable right now and making true research/production use possible feels more urgent than enabling a pure Rust stack (nice for teaching and first steps).

I use Zulip a lot more than Discord so would lean that way. There is a Rust-ML Zulip (some related to linfa, some discussion of AD tools like Enzyme; :wave: @ZuseZ4, who has been doing great work with Enzyme and may be interested in broader Rust scientific computing community). We could join Rust-ML or make a new RustSciComp or RustHPC. And I think we should coordinate a virtual event in the spring.

[ZuseZ4]

Hi and thanks for the ping. I have been thinking about the Blas issue too and while I first didn't cared that much, I have been talking to a few Julia lang developers and generally started to re-consider my opinion. The question they brought up often wasn't whether more experienced Julia / Rust devs, often with a C/C++ background are able to set things up, but rather if those who are coming to python can handle it. I would love some Rust based BLAS which then could even be used by both ndarray and nalgebra (keeping both around is something important for me). We are however a smaller group compared to julia labs + julia computing, so I guess it is worth discussing where we want to invest our time.

I am currently working on moving the Rust+Enzyme autodiff prototype into the nightly compiler, s.t. all Rust functions become differentiable. That and the contributions to Enzyme proper will probably keep me busy for now, but I would also be interested in discussing any related Rust + HPC / ML subjects. As a side note, I'll graduate tomorrow and apply for PhD positions in the Scientific Computing area. There I'll likely have some time to work on Rust related projects there too, so I will would be happy to have meetups with anyone in the broader area. In https://rust-ml.zulipchat.com/ we had bi-weekly meetups and discussions in the past, maybe there is enough overlap to use it? I also wouldn't mind using another zulip / discourse / ...

ping @Bytesnake, who also works on the rust-enzyme frontend and linfa. They also discussed Blas issues quite a bit at linfa.

[Andlon]

@jedbrown:

I guess I'm less stressed about the BLAS dependency since BLIS (https://github.com/blas-lapack-rs/blis-src/) has been pretty pain-free if you have a C compiler. But I live in a world where some C code is unavoidable right now and making true research/production use possible feels more urgent than enabling a pure Rust stack (nice for teaching and first steps).

Last time I looked at BLIS it looked problematic to compile on Windows. I don't use Windows myself but some of my colleagues do, so it's important for me to have something that works smoothly on Windows. Has the Windows support improved? I can't see any "warnings" in the README anymore... That'd be great!

I use Zulip a lot more than Discord so would lean that way. There is a Rust-ML Zulip (some related to linfa, some discussion of AD tools like Enzyme; wave @ZuseZ4, who has been doing great work with Enzyme and may be interested in broader Rust scientific computing community). We could join Rust-ML or make a new RustSciComp or RustHPC. And I think we should coordinate a virtual event in the spring.

(also in response to @ZuseZ4) I'd personally prefer a separate channel or server for scientific computing. ML and sci comp often get conflated (for example on the Rust community Discord), and in my experience this means that scientific computing stuff often gets lost among all the ML content, given the huge number of ML researchers/practitioners compared to scientific computing people. Doubly so for those of us who are not working on ML!

[tbetcke]

Hi,

I agree with @Andlon that we should have a dedicated group for Rust Scientific Computing Discussions. With regards to BLIS, etc. The matrixmultiply project is a wonderful start. I had a discussion with Barry Smith from the PETSc project yesterday about Rust for Scientific Computing. His suggestion with regards to Rust native BLAS was to simply start with some current Fortran Lapack functions and translate them into native Rust as a lot of the heavy lifting with regards to BLAS3 is already done by matrixmultiply.

But such discussions about strategy would be perfect for a dedicated Scientific Computing Channel. There are lots of other things to work through. One important topic is the role of async/await in Scientific Computing, great tool to build complex task graphs but little experience about use in CPU intensive tasks. Nevertheless, Barry mentioned a number of algorithmic problems that would benefit from proper async support.

A dedicated group would also allow us to coordinate Resources better. We have some decent resources now on our side with a new computational researcher @mscroggs and some Research Software Engineers who are keen to get into Rust Scientific Computing and will support this work. But we need to find good coordination across the various efforts.

I am happy with Zulip and Discord and have no preference.

[Andlon]

A quick note on Zulip / Discord: one thing that irks me about Discord is that it doesn't support LaTeX rendering. I have precious little experience with Zulip, but it looks like it supports TeX, which may be useful for a community focused on science...

[jedbrown]

Yeah, we've been using Zulip heavily for a few years, in part due to the math support and code snippet integration (it can automatically link code snippets to the appropriate playground). Any preference on names? rust-scicomp? scicomp-rs? rust-cse?

BLIS is tested in Appveyor on Windows, though it needs mingw. I guess it could be added to Chocolatey (which we use out of convenience in rsmpi testing). I get your point that it isn't automatic. While translating Fortran Lapack is possible, it just seems like a lot of developer effort. Note that one needs a lot more than GEMM for things like eigensolvers so there would be additional work at the BLAS level (probably emulating BLIS).

I think async/await could be really useful for GPU offload and overlapping communication with computation.

[Andlon]

@jedbrown: I'd say rust-scicomp is the most descriptive, at least. It also uses a naming scheme consistent with the aforementioned rust-ml, which is probably also a minor bonus. I can't think of any particular arguments for the other alternatives.

[jedbrown]

Cool, please sign up here. https://rust-scicomp.zulipchat.com/join/uznofpa3bvfjkw4nzpj3qfyn/

[bytesnake]

Hi all, it's great to see the numerics community in Rust gain traction!

Like @ZuseZ4 said, we had our issues with the BLAS/LAPACK dependencies. They are easy to use for experienced users but we got frequent requests from newbies who weren't able to set up their system libraries correctly. Also cross-compiling to embedded devices is no fun with LAPACK. @YuhanLiin ported mportant routines to pure Rust for ndarray, you can find it at rust-ml/linfa-linalg and we use them now as a slower default. What I would wish for is a crate with minimal dependencies and generics, similar to matrixmultiply but for linear algebra routines. Though we have a decade of development to catch on, I think that the network effects of cargo and superb tooling can give an edge to established languages. I think that the Rust language itself does not bring much new to the menu for numerical computation.

But I'm super thrilled to see better einops for ndarray/nalgebra, AD with enzyme, simple configuration of complex experiments with serde etc. play together and see the effects of this on other communities.

The matrixmultiply project is a wonderful start.

has anyone experience using polly in LLVM, there is a port of the polybench with mixed results here and I was wondering how that would compete against matrixmultiply

[..] and in my experience this means that scientific computing stuff often gets lost among all the ML content, given the huge number of ML researchers/practitioners compared to scientific computing people.

people using Rust for machine learning are normally a bit insane and not your day-to-day ML practitioners :wink: my hope for the future is that we find a niche with people deeply caring about solving problems and ML libraries with strong background in statistics.

I have precious little experience with Zulip, but it looks like it supports TeX, which may be useful for a community focused on science...

like you said TeX support is necessary to be even practical but what makes a real difference as well are how Zulip organizes everything into topics, the model feels much more like mailing lists (you can actually use it like this) and supports the use with sane shortcuts and fast interface

Also make sure to check out the https://rust-edu.org/ website and Zulip channel, they had recently their first workshop on how to teach Rust paradigms in academia!

[Andlon]

Thanks for your input, @bytesnake! I'm particularly curious to hear about people sharing their expectations/ambitions/visions for the Rust scientific computing ecosystem. I hope the new Zulip server that @jedbrown set up can be a great place to do just that :-)