4 ms·

Sounds interesting, but it's a space with a lot of different options. Have tried doing benchmarks against other vector libraries? If I'm shopping for a vector

by tux3 2y ago

Sounds interesting, but it's a space with a lot of different options. Have tried doing benchmarks against other vector libraries? If I'm shopping for a vector library, this is one of the pieces of information that makes the decision easier.

mflaherty22 2y ago
I'd like to see what the author's motivation was for making this, but I'm not sure benchmarks would be the first thing I look for :)
- the__alchemist 2y ago
  I haven't done benchmarks, but this speculation nailed it - The exact motivation is lost, but I believe I became tilted with inconsistent mixes of JPL and Hamilton quaternion operations on the popular libs at the time. Since then, I use it as a low-friction way to conserve geometrical functions among multiple projects. I.e., it's easier to just edit the code base than go through a PR process.
  - zamalek 2y ago
    no_std seems somewhat novel, which might have been another motivating factor?
creata 2y ago
I haven't benchmarked, so these opinions might be worthless, but here's how they're laid out internally. * nalgebra uses fixed-size arrays (so a Vec4 is like [[f32; 4]; 1]) * this library seems to use fields (so a Vec4 is a struct with x,y,z,w fields) * glam uses SIMD types for some types (so a Vec4 is a __m128) I think maybe glam might win for some operations, but if you want performance, people usually SIMD in the other direction when possible, like: struct Vec4 { x: __m128, y: __m128, z: __m128, w: __m128 } According to mathbench-rs[0] (which I looked at after typing this comment...) it looks like nalgebra and ultraviolet have such types. The benchmarks have "N/A" for many of the "wide" nalgebra entries though, which might indicate that nalgebra hasn't implemented many of those functions for "wide" types. [0]: https://github.com/bitshifter/mathbench-rs https://github.com/bitshifter/mathbench-rs
- Animats 2y ago
  The glam guy wanted to go all aligned so that SIMD would work, but that would break so much code that he was talked out of it. Hint for language designers: when you design a new language, put this stuff, and multidimensional arrays, in the standard library. Multiple incompatible versions of such types is as bad for number-crunching as would be multiple incompatible string types for string manipulation. You want your standard numeric libraries to work on the standard types. This is part of why Matlab is so successful. You don't have to worry about this stuff.
  - zevets 2y ago
    It's honestly surprising so many programming languages ignore the needs of "floating point" users. Rust has ints that aren't 0, but no std type for floats that aren't NaN? In some sense, ieee754 floats are better than ints, as the float error modes have NaNs are just HW supported error tagged enum types. I think its from a CS education which treats the "naturals" as fundamental, vs an engineering background where the "reals" are fundamental, and matrix math _essential_ and people live on one side of this fence.
    - vlovich123 2y ago
      > This enables some memory layout optimization. For example, Option<NonZero<u32>> is the same size as u32 NaN doesn’t have this optimization because the optimization isn’t generic across all possible representations. Trying to make it generic gets quite complex and floats might have many such representations (eg you want NaN to be optimized, someone else needs NaN and thinks infinity works better etc). In other words: Nonzero is primarily for size optimization of Option<number>. If you want sentinels, then write your own wrapper, it’s not hard.
    - Animats 2y ago
      That was true in the past, for a few reasons. - Floating point operations used to be slow. On early PCs, you didn't even have a floating point unit. AutoCAD on DOS required an FPU, and this was controversial at the time. - Using the FPU inside system code was a no-no for a long time. Floating point usage inside the Linux kernel is still strongly discouraged.[1] System programmers tended not to think in terms of floating point. - Attempts to put multidimensional arrays in modern languages tend to result in bikeshedding. If a language has array slices, some people want multidimensional slices. That requires "stride" fields on slices, which slows down slice indexing. Now there are two factions arguing. Rust and Go both churned on this in the early days, and neither came out with a good language-level solution. It's embarrassing that FORTRAN has better multidimensional arrays. Now that the AI world, the GPU world, and the graphics world all run on floating point arrays, it's time to get past that. [1] https://www.kernel.org/doc/html/next/core-api/floating-point.html https://www.kernel.org/doc/html/next/core-api/floating-point...
exDM69 2y ago
I'm using Rust (nightly) std::simd for my 3d math stuff. It doesn't come with matrix and quaternion functions but they were relatively simple to implement based on known good algorithms. But you do get basic arithmetic operators without having to implement std::ops by hand (or with macros). What was/is not pretty is adding some generics so the same code can work with f32 and f64. I did manage to get something that works but it's so ugly that I didn't want to release it. I'm sure it could be improved but what I got works well enough and I haven't needed to touch it in a few years. std::simd is quite pleasant to work with and most importantly it allows a zero cost fallback to CPU specific intrinsics when needed.

by tux3 2y ago

mflaherty22 2y ago

I'd like to see what the author's motivation was for making this, but I'm not sure benchmarks would be the first thing I look for :)

the__alchemist 2y ago
I haven't done benchmarks, but this speculation nailed it - The exact motivation is lost, but I believe I became tilted with inconsistent mixes of JPL and Hamilton quaternion operations on the popular libs at the time. Since then, I use it as a low-friction way to conserve geometrical functions among multiple projects. I.e., it's easier to just edit the code base than go through a PR process.
- zamalek 2y ago
  no_std seems somewhat novel, which might have been another motivating factor?

creata 2y ago

I haven't benchmarked, so these opinions might be worthless, but here's how they're laid out internally. * nalgebra uses fixed-size arrays (so a Vec4 is like [[f32; 4]; 1]) * this library seems to use fields (so a Vec4 is a struct with x,y,z,w fields) * glam uses SIMD types for some types (so a Vec4 is a __m128) I think maybe glam might win for some operations, but if you want performance, people usually SIMD in the other direction when possible, like: struct Vec4 { x: __m128, y: __m128, z: __m128, w: __m128 } According to mathbench-rs[0] (which I looked at after typing this comment...) it looks like nalgebra and ultraviolet have such types. The benchmarks have "N/A" for many of the "wide" nalgebra entries though, which might indicate that nalgebra hasn't implemented many of those functions for "wide" types. [0]: https://github.com/bitshifter/mathbench-rs https://github.com/bitshifter/mathbench-rs

Animats 2y ago
The glam guy wanted to go all aligned so that SIMD would work, but that would break so much code that he was talked out of it. Hint for language designers: when you design a new language, put this stuff, and multidimensional arrays, in the standard library. Multiple incompatible versions of such types is as bad for number-crunching as would be multiple incompatible string types for string manipulation. You want your standard numeric libraries to work on the standard types. This is part of why Matlab is so successful. You don't have to worry about this stuff.
- zevets 2y ago
  It's honestly surprising so many programming languages ignore the needs of "floating point" users. Rust has ints that aren't 0, but no std type for floats that aren't NaN? In some sense, ieee754 floats are better than ints, as the float error modes have NaNs are just HW supported error tagged enum types. I think its from a CS education which treats the "naturals" as fundamental, vs an engineering background where the "reals" are fundamental, and matrix math _essential_ and people live on one side of this fence.
  - vlovich123 2y ago
    > This enables some memory layout optimization. For example, Option<NonZero<u32>> is the same size as u32 NaN doesn’t have this optimization because the optimization isn’t generic across all possible representations. Trying to make it generic gets quite complex and floats might have many such representations (eg you want NaN to be optimized, someone else needs NaN and thinks infinity works better etc). In other words: Nonzero is primarily for size optimization of Option<number>. If you want sentinels, then write your own wrapper, it’s not hard.
  - Animats 2y ago
    That was true in the past, for a few reasons. - Floating point operations used to be slow. On early PCs, you didn't even have a floating point unit. AutoCAD on DOS required an FPU, and this was controversial at the time. - Using the FPU inside system code was a no-no for a long time. Floating point usage inside the Linux kernel is still strongly discouraged.[1] System programmers tended not to think in terms of floating point. - Attempts to put multidimensional arrays in modern languages tend to result in bikeshedding. If a language has array slices, some people want multidimensional slices. That requires "stride" fields on slices, which slows down slice indexing. Now there are two factions arguing. Rust and Go both churned on this in the early days, and neither came out with a good language-level solution. It's embarrassing that FORTRAN has better multidimensional arrays. Now that the AI world, the GPU world, and the graphics world all run on floating point arrays, it's time to get past that. [1] https://www.kernel.org/doc/html/next/core-api/floating-point.html https://www.kernel.org/doc/html/next/core-api/floating-point...

exDM69 2y ago

I'm using Rust (nightly) std::simd for my 3d math stuff. It doesn't come with matrix and quaternion functions but they were relatively simple to implement based on known good algorithms. But you do get basic arithmetic operators without having to implement std::ops by hand (or with macros). What was/is not pretty is adding some generics so the same code can work with f32 and f64. I did manage to get something that works but it's so ugly that I didn't want to release it. I'm sure it could be improved but what I got works well enough and I haven't needed to touch it in a few years. std::simd is quite pleasant to work with and most importantly it allows a zero cost fallback to CPU specific intrinsics when needed.