dweiss commented on issue #16730: URL: https://github.com/apache/lucene/issues/16730#issuecomment-5897593861
Yes - I've sent an email about this to dev list a while ago. Quote: AI-backed analysis insists this is an permissible floating point computation difference between different jvm compilation levels. It wrote a test that has an allowed epsilon difference but it's so ugly that I won't present it here. The problem remains though, quote: "The test compares bytes that depend on a Vector API floating-point reduction, and the JDK does not guarantee that reduction is stable within one JVM. The .vemq body for field v lays out fixed ints, a few vints, then the 64-float centroid at bytes 18 to 273, then the centroid dot product [...] The writer computes the stored value with VectorUtil.dotProduct on that identical centroid at Lucene104ScalarQuantizedVectorsWriter.java:381, and the two calls returned results two ULPs apart. The Panama dot product ends with a reduceLanes(ADD). The JDK javadoc for FloatVector.reduceLanes says that for ADD the result "will reflect the choice of an arbitrary order of operations, which may even vary over time." Concretely, the Java fallback used by the interpreter and C1 folds lanes sequentially, while the C2 intrinsic uses a horizontal tree reduction. Confirmation. A standalone program that reduces the same 64-float vector 200,000 times on JDK 25 with 256-bit species yields two distinct results. The value flips at iteration 4472, which is when C2 takes over." -- 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]
