IP space roundup bug fix

[GuyAv46]

Fixing a bug causing IP functions in some optimizations and cases to round up the calculated result.

when using InnerProductSIMD16ExtResiduals or InnerProductSIMD4ExtResiduals, we call InnerProductSIMD16Ext or InnerProductSIMD4Ext respectively, and then also calling InnerProduct. each result already calculated 1.0f - {IP} so we need to sum them and then subtract one 1.0f back to get 1.0f - {IP16/4 + IPrest} and not 2.0f - {IP16/4 + IPrest}.

When comparing close vectors, this can lead to losing the actual IP and rounding up the result, and getting inconsistent results in different optimizations.

[yurymalkov]

Hi @GuyAv46. Thank you for the PR!

One major factor is that hopefully #357 is going to be merged pretty soon with some changes in the same file, so probably it would be needed to be updated.

I guess it also might make sense to rename InnerProduct_impl* to just DotProduct* (or InnerProduct*), and probably it is a good time to add to rename InnerProduct* to InnerProductDistance*, so that is it is clear that some methods are computing inner product and some - inner product distance.

I also wonder if you've know what is the difference between avx and non-avx computation on the same cpu?

[GuyAv46]

Happy to help. :)
I will subscribe to the PR you've mentioned and make the needed changes. I also agree about the naming of the functions.

about the last question - do you mean what is the difference in performance?

[GuyAv46]

---------------------------------------------------------------------
Benchmark                           Time             CPU   Iterations
---------------------------------------------------------------------
BM_VecSimBasicsIP/IP             76.4 ns         76.4 ns      9018969
BM_VecSimBasicsIP/IPAVX512       7.34 ns         7.34 ns     94764434
BM_VecSimBasicsIP/IPAVX          12.4 ns         12.4 ns     56307633
BM_VecSimBasicsIP/IPSSE          15.2 ns         15.2 ns     46112636

tested on Lenovo Thinkpad P15v with AVX512 capabilities, on 128 dimension float vector, using InnerProductSIMD16Ext

[yurymalkov]

@GuyAv46 Thank you!
I meant if there is a difference in terms of numeric accuracy (I guess there might be some), though the performance numbers are also valuable.

[GuyAv46]

As far as I can tell, my PR fix this problem; there is no more difference in result accuracy between different optimization. Every function eventually multiply each same-index elements pair and then sum them all up, using floats, even if they use two functions internally, and only afterward calculating 1 - res.

Before the change, I notice that when I used InnerProductSIMD16ExtResiduals with two close vectors, the first internal function returned 1 (the dot product was 0), and the second internal (on the "tail") returned ~0 (1-{almost 1}), and instead returning ~0 (5.9604645e-08), the function returned 1 + ~0 - 1 and it got round up to 0.

Now I'm getting the same result regardless the specific function.

[yurymalkov]

Got it! Thanks!

[yurymalkov]

Hi @GuyAv46.
The PR looks good to me. Wanted to check that you think it is ready to be merged?

[GuyAv46]

Yes, It is ready

[yurymalkov]

Thanks!