nalgebra VS Rust-CUDA

Ok, so this uses https://rapier.rs/ which is very cool

Rapier, alongside https://nalgebra.org/ (which it uses underneath) has seriously good documentation and some advanced features like cross-platform determinism (something made hard by the way floating point differs between platforms)

> Some GA libraries[1][2] define types for the different kind of objects (grades)

That's nice!

This reminds of me things like, linear algebra libraries that will type-check matrices so that a 2x2 matrix can't be added to a 2x3 matrix (but then you can have a dynamic matrix that will error only in runtime), like https://nalgebra.org/ and others.

Maybe start by looking at https://nalgebra.org/ to see what rust math libraries might look like

And Nalgebra, while better, also seems to have slowed down on commits and responses to issues and PRs. I have a PR there for a relatively simple wrapper type for row vectors which was explicitly requested by a maintainer, which hasn't even gotten a comment since for two weeks.

nalgebra (similar to Eigen in cpp)

nalgebra

nalgebra is for linear algebra.

Take a look into math libraries, like glam, nalgebra, and cgmath. I've only used these through game engines, though, so I can't offer per-basis reviews/advice.

If you do not need GPU then I would recommend looking into Eigen in C++, nalgebra in Rust (with a BLAS in both cases for improved performance) or one of the above options (Julia / Python+JAX).

Source code [here](https://github.com/ihawn/RTracer) if anyone is interested in taking a look or giving feedback. As a side question, does anyone have any general advise on getting GPU compute working with rust? I tried [this project](https://github.com/Rust-GPU/Rust-CUDA) but had a bunch of issues (And it doesn't look like an active repo anyways)

You have this https://github.com/Rust-GPU/Rust-CUDA

What I'm trying to do is check out https://github.com/Rust-GPU/Rust-CUDA for a class project.

Be warned, NON_BLOCKING streams do not fully synchronize with sync host to device copies. They are not guaranteed to actually finish by the time they return. Meaning its possible to initiate a copy, then initiate a kernel launch, and have the copy be unfinished by the time the kernel is launched. This caused so many confusing bugs that i personally decided to stop using NON_BLOCKING altogether in rust-cuda. https://github.com/Rust-GPU/Rust-CUDA/issues/15

- Cuda is not doing by FFI linking, instead is compiling CUDA code natively in Rust https://github.com/Rust-GPU/Rust-CUDA and even if it not complete as the C++ SDK is more than a toy

Given your criteria, you might want to consider (modern) C++.

* Fast - in many cases faster than Rust, although the difference is inconsequential relative to Python-to-Rust improvement I guess.

* _Really_ utilize CUDA, OpenCL, Vulcan etc. Specifically, Rust GPU is limited in its supported features, see: https://github.com/Rust-GPU/Rust-CUDA/blob/master/guide/src/... ...

* Host-side use of CUDA is at least as nice, and probably nicer, than what you'll get with Rust. That is, provided you use my own Modern C++ wrappers for the CUDA APIs: https://github.com/eyalroz/cuda-api-wrappers/ :-) ... sorry for the shameless self-plug.

* ... which brings me to another point: Richer offering of libraries for various needs than Rust, for you to possibly utilize.

* Easier to share than Rust. A target system is less likely to have an appropriate version of Rust and the surrounding ecosystem.

There are downsides, of course, but I was just applying your criteria.

Technically, yes. There are crates for OpenCL and CUDA, although official ROCm support does not exist yet.