advisedy commented on code in PR #3562:
URL: https://github.com/apache/kvrocks/pull/3562#discussion_r3638977379
##########
src/search/hnsw_indexer.cc:
##########
@@ -173,14 +172,15 @@ StatusOr<double> ComputeSimilarity(const VectorItem&
left, const VectorItem& rig
}
HnswIndex::HnswIndex(const SearchKey& search_key, HnswVectorFieldMetadata*
vector, engine::Storage* storage,
- std::random_device::result_type seed)
+ std::optional<std::random_device::result_type> seed)
: search_key(search_key),
metadata(vector),
storage(storage),
- generator(std::mt19937(seed)),
+ seed(seed),
m_level_normalization_factor(1.0 / std::log(metadata->m)) {}
uint16_t HnswIndex::RandomizeLayer() {
+ static thread_local std::mt19937 generator = [this] { return
std::mt19937(seed.value_or(std::random_device()())); }();
Review Comment:
You're right — the semantics of `seed` is indeed weird here. Since the
generator is now shared, only the first instance's seed would take
effect, which is misleading.
I see two possible directions:
1. Share the generator only among indexes with the same seed, and let
indexes with different seeds keep their own. I haven't fully figured
out the implementation yet, but maybe a `static thread_local` map
could work? It seems like that might be doable.
2. Drop `seed` entirely, seed the generator with `std::random_device`,
and make it a class-level `static thread_local std::mt19937` member
(no longer a function-local static), so its initialization no longer
depends on any specific instance.
I'd like to know which direction you think we should take. If you
prefer option 1, I'll think about how to implement it in detail. If
it's option 2, I'll go ahead and do it now.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
