SIMD-Accelerated Saturated Cast to i32/i64? And other compression things...

[recatek]

Hi! I'm interested in putting together some optimized methods for serializing Vector 3 and Quaternion types for network encoding, mainly for multiplayer game servers. The typical approach I've seen and am following for float encoding is to:

1. Multiply by 10^P, where P is the digits of precision you want (e.g. 2, to round to the nearest .01).
2. Round.
3. Cast to an i32 (for f32) or i64 (for f64).
4. Encode using varint encoding.

I've been working on optimizing these steps for singular f32 and f64 types. For (2), I've found that these methods can significantly outperform Rust's built-in libm call for f32/f64::round(). For (3), I'd like to stick to the same saturating cast behavior that the as keyword does (see reference), and for (4) I'm using a variation on the optimized prefix-byte varint encoding that the speedy library uses to reduce the write operation to just a few shifts.

I'd like to expand this to a SIMD-accelerated version for Vector 3 and Quaternion, and so I've been exploring ways to achieve a "shopping list" of SIMD operations. In particular, I need:

1. An as-fast-as-possible 4-wide SIMD saturated cast from f32 to i32, or f64 to i64, ideally with the same semantics as as.
2. An efficient SIMD rounding function with the same behavior as f32/f64::round on edge cases, and one that plays nicely with the casting in (1).

This is all pretty borderline for glam's scope, certainly, but I'd be curious to see if this would be an interesting set of things to add or support for glam, or if you had any thoughts on how to go about implementing them. I'll also need to figure out ways to do some other things, if they're even possible:

1. SIMD-accelerated "smallest three" compression for quaternions (see "Optimizing Orientation" here).
2. The actual varint encoding process, mostly bit shifts and counting.

Thanks!

[recatek]

Here's a rough and untested example of what I'm talking about: https://rust.godbolt.org/z/r17xrsa9e

[bitshifter]

Within the context of glam, would you lose performance gains because IVec* are not SIMD backed or 16 byte aligned? You might get the gains from the SIMD optimized routine but they lose them when storing the results.

[recatek]

This is aiming more for Vec3A I believe, so taking in an _m128 and converting it to a discretized/rounded _m128i to then pass off for serialization.

[bitshifter]

I would be happy to accept PRs for SIMD optimised casts where is makes sense. The current implementations of Vec3A::as_ivec3 and Vec4::as_ivec4 just as f32 as i32 internally right now. Any PR should be accompanied by tests to demonstrate behaviour is the same as as and benchmarks showing a performance improvement.

At the moment I haven't written any SIMD acceleration for f64, this wouldn't prevent accepting optimised casts for f64 but there may be less benefit if the data is not already in SIMD registers. For now SSE2 is the lowest common denominator for SIMD on Intel, it's always available on x64, I haven't added support for newer instruction sets. Supporting f64 raises a few questions in that regard because support could be added with either SSE2 using two __m128d registers or with AVX, so far I have not required AVX.

glam does use a SIMD optimised round already, see

glam-rs/src/core/sse2/float.rs

Lines 36 to 47 in 88e4538

	pub(crate) unsafe fn m128_round(v: __m128) -> __m128 {
	// Based on https://github.com/microsoft/DirectXMath `XMVectorRound`
	let sign = _mm_and_ps(v, PS_SIGN_MASK);
	let s_magic = _mm_or_ps(PS_NO_FRACTION, sign);
	let r1 = _mm_add_ps(v, s_magic);
	let r1 = _mm_sub_ps(r1, s_magic);
	let r2 = _mm_and_ps(v, PS_INV_SIGN_MASK);
	let mask = _mm_cmple_ps(r2, PS_NO_FRACTION);
	let r2 = _mm_andnot_ps(mask, v);
	let r1 = _mm_and_ps(r1, mask);
	_mm_xor_ps(r1, r2)
	}

.

I think for network compression of glam types it would make sense to do this in a separate crate, at least initially. There are a few different ways to approach this and what works best can vary from game to game, so I feel like it would be better to flesh this out outside of glam. For SIMD it should be a no-op to convert between glam types like Vec4 and Vec3A and SIMD registers, so exploring SIMD optimisations external to the glam crate should be possible.