Increasing max alignment length about gkl-rs

[philipc]

For both the C and rust code, the main reason for this constraint is the size of the backtrack array, which is a two dimensional array of i16. I think that changing this to i32 would roughly double the memory usage and maybe cause some slowdown, but I don't know how much without measuring.

In addition to replacing i16 with i32, you would need to change the AVX instructions that do the packing (_mm256_packs_epi32). I'm reluctant to change the C code to do this, since then we stop being the same as upstream GKL, which is the main reason for having that C code there. However, it would be feasible to change the rust code and see how it affects performance.

[philipc]

Hmm, I'm not sure I have that right... let me refresh my memory of how this works.

[philipc]

I think the backtrack array only contains the insert/delete flags, so it could even be u8. I added assert!(btrack <= 15); here and it was never hit during the tests:

gkl-rs/src/smithwaterman.rs

Lines 523 to 524 in 9eec442

	let btrack =
	unsafe { *backtrack.offset((antidiag * backtrack_stride + backtrack_ind) as isize) };

So I don't think the backtrack array is the reason for the limit.

Instead, I'd be concerned about overflows in the 32-bit calculations in compute, but I'd have to look closer to determine where they might occur.

[philipc]

I think the only place that overflow can occur is here:

gkl-rs/src/smithwaterman.rs

Line 350 in 9eec442

let m11 = v.add(h00, sbt11);

Underflow isn't a concern because we always take the maximum of two values, so it is limited by low_init_value.

So the limit is that MAX_SW_SEQUENCE_LENGTH * MAXIMUM_SW_MATCH_VALUE < i32::MAX. Currently the code limits these values individually, but I don't see why we couldn't limit the product instead.