Choice of a linear algebra library

[TrueDoctor]

Moving forward, we will need some kind of math library for Graphite.
Graphite is a 2D raster and vector graphics editor.

We have gathered a few criteria that seemed important to us:

• performance for 2D applications important
• Minimal sub-dependencies
• Popularity such that any projects that depend on Graphite/Graphite depends on might already use this library
• Simplicity for our codebase
• Sufficient features for future usage
• Small build size (for the release including lto)
• Small addition to compile time
• Overall lightweightness
• Likelihood of long-lived support
• Performance in SIMD and multithreading (threading ideally via rayon to allow easy use in wasm)
• Performance and low footprint in Embark's Rust GPU for shaders
• Compilation to wasm

There will be more things that we didn't think of, but this should give a general direction.
But feel free to ask further questions about the requirements.

We have been primarily looking at glam (@bitshifter) and nalgebra (@sebcrozet).
It would be great if you could give us further insight to help with the decision.

[sebcrozet]

Hey! Both glam an nalgebra sound good for this purpose.

Here are some additional info:

• nalgebra and glam don't work with SIMD the same way. glam uses internal SIMD optimization: Vec2 + Vec2 (EDIT: this isn't actually true for 2D vectors see @bitshifter comment bellow) explicitly uses one SIMD instruction for adding two vectors. nalgebra on the other hand allows AoSoA SIMD optimization (i.e. Vector2<f32x4> + Vector2<f32x4> for adding two set of four vectors) and relies on auto-vectorization for Vector2<f32> + Vector2<f32>. So if you need AoSoA SIMD, then nalgebra will be a better fit. Otherwise, glam will be better because you have more guarantee that the intrenal SIMD vectorization will actually happen (even in debug mode).
• nalgebra has a much worse performance in debug mode than glam. In release mode with lto enabled and codegen-units = 1, both glam and nalgebra should perform about the same in 2D.
• glam is much smaller/lightweight than nalgebra (is you compare the number of line of code, I don't think you will get different binary size once your project is compiled).
• nalgebra has much more features than glam. So I would suggest taking a look at glam's documentation and see if you find everything you need (or if you don't, ask @bitshifter if they plan to add it). If glam has everything you need, you probably want to use glam as it will be easier to learn and its rustdoc-generated documentation is easier to browse (especially nowadays because of multiple rustdoc regressions affecting nalgebra's generated docs in a negative way…)
• nalgebra is more strongly typed than glam. nalgebra has dedicated types for points, isometries, unit-quaternions, etc. Some people like it, some find this overkill. There is also the nalgebra-glm crate built on top of nalgebra which as less types and is very similar to the C++ glm library.
• I don't know which is more popular than the other. I would think that glam is more popular within the gamedev community (because glam is being used by, e.g., Bevy, macroquad, etc.) whereas nalgebra is more popular within the scientific community (simulation, research, etc.)
• I think that glam is already explicitly supported by rust-gpu.
• In term of long-term maintenance: nalgebra is one of the core projects I built my company on, and I know of at least one research lab and CAD company actively using it, so it will be maintained/improved in the long term. I think glam is also something that will live in the long-term (it is in a very good track at least), but I'll let @bitshifter confirm that.
• In case you need geometric operations (intersection test, distance computation, etc.), nalgebra is being used by the parry2d crate which is also a long-term project. I don't know if there is something similar based on glam.

So I think that if your priority is ease of use, lightweightness, and already-existing integration with rust-gpu, pick glam.
If you need more features, stronger types, and crates like parry (assuming there is no glam-based equivalent, I may be wrong), pick nalgebra.

Also no matter the library you choose, keep in mind that conversion between glam and nalgebra types is possible using the standard library's From/Into traits (by enabling the convert-glam015 feature of nalgebra).

[TrueDoctor]

Thank you @sebcrozet very much for such a quick and comprehensive reply! This will make the process already much easier.
I do think we will need intersections at some point, but I'll let @Keavon confirm that.

[bitshifter]

Hi there!

I think glam fits well with some of your goals such as small sub dependencies, small build size, small compile time, a simple API and light-weightness goals. These things have always been a focus of the library.

glam has explicit support for SIMD, but only SSE2 on x86 at the moment (as that is all that is stable in Rust) although I intend to add other architectures such as wasm m128 support at some stage. As @sebcrozet points out glam's SIMD support is to accelerate scalar math, not AoSoA, so you don't get the full potential benefits of SIMD. The example of using SIMD for Vec2 + Vec2 above isn't correct however, that's just regular f32 math in glam (there was no benefit in performance for Vec2 to use SIMD).

I can't speak to sufficient features, that depends on what you need. nalgebra is definitely more feature rich than glam and @sebcrozet also develops the parry and rapier crates on top of nalgebra.

While glam isn't 1.0 yet I don't expect to add a lot more features to it, it has a narrow focus of common functionality needed in games generally. glam is a personal time project for me but the scope is small enough that I don't see future maintenance being an issue.

While I couldn't commit to expanding the feature set greatly (e.g. intersection) some community crates may appear. For example bevy are building some simple primitives and intersection tests, potentially those could be made standalone once they have matured.

rust-gpu is currently being built on glam however it is their long term goal to be math library agnostic.

I don't think there should be any limitation with either library using rayon or targetting wasm.

Hope that helps!

[Keavon]

Thank you both for the in-depth answers, it was very helpful! We ended up deciding on glam for its overall simplicity, but if we end up needing the increased features of nalgebra in the future, we may reevaluate.