Skip to content

Keep the NEON int8 cosine sums in 64 bits - #356

Open
MayCXC wants to merge 1 commit into
asg017:mainfrom
MayCXC:cosine-int8-sums
Open

MayCXC wants to merge 1 commit into
asg017:mainfrom
MayCXC:cosine-int8-sums

Conversation

@MayCXC

@MayCXC MayCXC commented Oct 23, 2026

Copy link
Copy Markdown

cosine_int8_neon() sums the products of int8 elements exactly, but in 32 bits, which the squares of -128 overflow from 131,072 elements. vec_distance_cosine() then returns NULL where a magnitude wraps negative or to zero, or a wrong distance:

-- 300,000 elements of 127 against 300,000 elements of 64, whose distance is 0
select vec_distance_cosine(
  vec_int8(unhex(replace(hex(zeroblob(300000)), '00', '7F'))),
  vec_int8(unhex(replace(hex(zeroblob(300000)), '00', '40'))));
-- main, built with -DSQLITE_VEC_ENABLE_NEON: 3.271314859390259
-- this change:                               0.0

Each pass now sums its products in 32-bit lanes, which hold at most 4 products each, and adds them into 64-bit lanes, as mceachen's photostructure/sqlite-vec@4e7a65b does in that fork for the same kernel. Widening only the final sum would not be enough: over 1,048,576 elements, the lane that holds every 8th square of -128 reaches 2^31 on its own.

test_vec_distance_cosine_int8_overflow checks mceachen's three cases from that commit against a float64 reference: 131,072 squares of 128, whose sum is 2^31; 2^32 in total, which wraps a 32-bit sum to 0; and 1,048,576 squares of 128, which overflow each 32-bit lane. Their squares keep every partial sum exact in float, so the scalar loop matches too. On main the NEON build returns NULL for all three and the test fails; with this change it passes on the NEON and the scalar build, as does the rest of tests/test-*.py (240 passed, 66 skipped on both). The NEON build here is Clang's, since GCC cannot build the NEON code on main (#322). Merged with #339, which builds on #322 and turns NEON on for Linux arm64, it builds with GCC, with the same warnings as #339 alone, and passes the suite.

The kernel is 0de765f's, which both forks ported: photostructure/sqlite-vec's main has this fix as mceachen's 4e7a65b, and vlasky#20 ports the kernel with it. #338 sums the float32 cosine kernel and scalar loop in double and leaves this kernel alone. This merges cleanly with #327 through #331 and #336 through #355; #267 conflicts with main itself, in the same three places with or without this change.

cosine_int8_neon() summed the products of int8 elements exactly, but
in 32 bits, which the squares of -128 overflow from 131,072 elements.
vec_distance_cosine() then returned NULL where a magnitude wrapped
negative or to zero, or a wrong distance: 3.27 for a vector of 300,000
elements of 127 and one of 300,000 elements of 64, whose distance is 0.

Each pass now sums its products in 32-bit lanes, which hold at most 4
products each, and adds them into 64-bit lanes, as mceachen's
photostructure/sqlite-vec@4e7a65b does in that fork for the same
kernel. Widening only the final sum would not be enough: over
1,048,576 elements, the lane that holds every 8th square of -128
reaches 2^31 on its own.

test_vec_distance_cosine_int8_overflow checks mceachen's three cases
from that commit against a float64 reference: 131,072 squares of 128,
whose sum is 2^31; 2^32 in total, which wraps a 32-bit sum to 0; and
1,048,576 squares of 128, which overflow each 32-bit lane. Their
squares keep every partial sum exact in float, so the scalar loop
matches too. On main the NEON build returns NULL for all three.

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant