Summary:
Pull Request resolved: https://github.com/facebookresearch/faiss/pull/5127
Attempt to enable FAISS dynamic dispatch (DD) mode on Windows/MSVC.
Changes:
- CMakeLists.txt: Remove if(NOT WIN32) guard from DD section, add MSVC per-file
SIMD flags (/arch:AVX2, /arch:AVX512, /bigobj) alongside existing GCC/Clang flags
- build-pull-request.yml: Add windows-x86_64-DD-cmake job that runs immediately
(no dependency on linux-x86_64-cmake), builds with MSVC and FAISS_OPT_LEVEL=dd,
runs C++ tests and Python tests
This diff is expected to fail on Windows due to MSVC requiring explicit template
specialization declarations (C++ §17.8.3) which GCC/Clang don't enforce. The CI
failure will surface the exact errors to guide the fix.
UPDATE: in fact, MSVC does not seem to require this. After fixing build scripts and a few classical Windows error, the C++ and python tests pass.
Reviewed By: algoriddle
Differential Revision: D101649751
fbshipit-source-id: 765ef8483d02652ce58625cd22baab8870acf718
Summary:
Pull Request resolved: https://github.com/facebookresearch/faiss/pull/4897
Add `FastScanCodeScanner`, a virtual base that bundles handler + kernel
behind the SIMD dispatch boundary. In DD mode, `SINGLE_SIMD_LEVEL = NONE`
so the existing fast scan code path uses emulated SIMD types. The new
scanner provides per-SIMD translation units (AVX2, AVX512, ARM_NEON)
compiled with the correct ISA flags, and a factory function
(`make_fast_scan_knn_scanner`) that uses `DISPATCH_SIMDLevel` to select
the right TU at runtime.
This follows the proven `THE_LEVEL_TO_DISPATCH` pattern from the scalar
quantizer per-SIMD TUs (`sq-dispatch.h`). Each per-SIMD TU includes
`dispatching.h` which provides:
- `ScannerMixIn<Handler>`: wraps a concrete handler and calls accumulation
kernels (both search_1 multi-BB and QBS paths)
- Factory specialization `make_fast_scan_scanner_impl<SL>()` with
combinatorial dispatch over `is_max × with_id_map × handler_type`
(SingleResultHandler for k=1, HeapHandler for k≤20, ReservoirHandler
for k>20)
New files:
- `impl/fast_scan/dispatching.h` — dispatch template header
- `impl/fast_scan/impl-avx2.cpp` — AVX2 per-SIMD TU
- `impl/fast_scan/impl-avx512.cpp` — AVX512 per-SIMD TU
- `impl/fast_scan/impl-neon.cpp` — ARM NEON TU (with ARM_SVE forwarding)
Modified files:
- `impl/fast_scan/pq4_fast_scan.h` — FastScanCodeScanner base + factory decl
- `impl/fast_scan/pq4_fast_scan.cpp` — NONE specialization + dispatch wrapper
- `xplat.bzl` / `CMakeLists.txt` — register SIMD files and header
Note: RaBitQ handler is not wired through FastScanCodeScanner in this
diff. That comes in later diffs when callers are switched.
Reviewed By: mdouze
Differential Revision: D95950483
fbshipit-source-id: 03841671f59c0d99de7d0c7408a64e7a8383a8e7
Summary:
Pull Request resolved: https://github.com/facebookresearch/faiss/pull/4867
Templatize the result handler hierarchy and scaler types on SIMDLevel SL,
defaulted to SINGLE_SIMD_LEVEL_256. This allows per-SIMD TUs to instantiate
handlers and scalers with explicit SIMD levels (e.g., AVX2) for native
dispatch.
Result handlers: ResultHandlerCompare, SingleResultHandler, HeapHandler,
ReservoirHandler, RangeHandler, PartialRangeHandler — all gain SL parameter.
Scalers: DummyScaler templatized on SL. 512-bit methods use SL directly
(removing #ifdef __AVX512F__ guard — safe because template bodies only
instantiated when called). NormTableScaler stays non-template (public API).
FixedStorageHandler: add SL parameter, remove SIMDResultHandler base class
(never used polymorphically), remove final/virtual.
Pure refactor. All existing callers use defaults and compile unchanged.
Reviewed By: mdouze
Differential Revision: D95392149
fbshipit-source-id: f4f05332b84d220d9d8e82b08afb4b7219c301a1
Summary:
Pull Request resolved: https://github.com/facebookresearch/faiss/pull/4623
Codes can be loaded from disk, so alignment is not guaranteed. This diff allows unaligned pointer in pq fast scan code.
I checked what the overhead was in low level instructions in godbolt. All 3 approaches are in P1997520050.
- No conditional
- Template parameter conditional (same number of instructions as no conditional, so it is probably not slower?)
- New parameter (increases number of instructions, making it slower)
Tried microbenchmarking in a loop. Seems to be the same between unaligned and aligned.
Unit Test
-
For non avx512, the code handles it correctly with the unit test. P1998522307 shows the error without any `c.loadu(codes)` handling.
Do we need to update avx512 version?
-
- The unit test passes with whatever code size I tried. I might have to change other things like nsq? May need input here.
Reviewed By: junjieqi
Differential Revision: D84364872
fbshipit-source-id: 59bae66d97d292d1096899280c94bb87ad15c69e
Matthijs Douze