gsmiller commented on code in PR #16771: URL: https://github.com/apache/lucene/pull/16771#discussion_r4272222039
########## lucene/CHANGES.txt: ########## @@ -201,6 +201,14 @@ Improvements Optimizations --------------------- + +* GITHUB#16771: Lucene99FlatVectorsWriter now aligns vector data to 4096 bytes for all encodings + (previously 64 for float32 and 4 for float16 and byte), so a vector whose size divides a page or is + a multiple of it no longer straddles a page boundary and a rescoring read touches no extra page. + (Ankur Goel) + +* GITHUB#16431: Add support for Block-Max WAND dynamic score skipping in FunctionScoreQuery Review Comment: Looks like a merge/rebase picked up another change entry. Could you clean this up? ########## lucene/core/src/java/org/apache/lucene/codecs/lucene99/Lucene99FlatVectorsFormat.java: ########## @@ -63,11 +63,13 @@ * that only in sparse case * </ul> * - * <p>NOTE: Arm Neoverse machines have a performance overhead in reading data that is not aligned to - * 64 bytes, so this format aligns the <code>.vec</code> file to that size. There may be a - * performance penalty in searching of float vectors that do <b>not</b> have a dimension of a - * multiple of 16 (equivalent to 64 bytes), because the alignment will not hold for all vectors in - * the file. + * <p>NOTE: this format aligns the vector data of each field in the <code>.vec</code> file to 4096 + * bytes, for every encoding. A vector whose size divides 4096 bytes or is a multiple of it (e.g. + * 1024-dim float32) then never straddles a page boundary, so reading one vector, as rescoring does, Review Comment: Philosophic question: We're introducing an assumption with this alignment change that we're running on a 4KiB page architecture. I don't think we make that assumption elsewhere, but I could be wrong? I don't think this change makes things fundamentally worse for non-4KiB page setups though. I think it's fine to do this, but I do wonder if there's a way to be smarter about the page sizes? -- 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] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
