perf: improve constructing dist table

[BubbleCal]

construc_dist_table: 16000,l2,PQ=96,DIM=1536
                        time:   [157.75 µs 157.97 µs 158.19 µs]
                        change: [-28.865% -28.731% -28.581%] (p = 0.00 < 0.10)
                        Performance has improved.

construc_dist_table: 16000,dot,PQ=96,DIM=1536
                        time:   [275.56 µs 276.02 µs 276.47 µs]
                        change: [-2.8930% -2.4637% -2.0839%] (p = 0.00 < 0.10)
                        Performance has improved.

[BubbleCal]

dot distance type doesn't benefit much from this optimization, any ideas? @eddyxu

[codecov-commenter]

Codecov Report

Attention: Patch coverage is 79.31034% with 12 lines in your changes missing coverage. Please review.

Project coverage is 77.95%. Comparing base (d79e870) to head (a2a37a5).

Files with missing lines	Patch %	Lines
rust/lance-index/src/vector/pq.rs	60.00%	10 Missing ⚠️
rust/lance-index/src/vector/pq/distance.rs	93.10%	2 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #3155      +/-   ##
==========================================
- Coverage   77.95%   77.95%   -0.01%     
==========================================
  Files         242      242              
  Lines       82436    82511      +75     
  Branches    82436    82511      +75     
==========================================
+ Hits        64262    64318      +56     
- Misses      14960    14985      +25     
+ Partials     3214     3208       -6     

Flag	Coverage Δ
unittests	77.95% <79.31%> (-0.01%)	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

---

🚨 Try these New Features:

• Flaky Tests Detection - Detect and resolve failed and flaky tests

[eddyxu]

dot distance type doesn't benefit much from this optimization, any ideas?

do we know if this is memory-bandwidth bound or just compute bound? we can look into that later.

[BubbleCal]

dot distance type doesn't benefit much from this optimization, any ideas?

do we know if this is memory-bandwidth bound or just compute bound? we can look into that later.

I think it's still compute bound, because L2 is much faster than dot, I'm thinking whether the 1-dot way leads to the compiler can't generate good enough code