madrob commented on PR #940: URL: https://github.com/apache/solr/pull/940#issuecomment-1190903304
I found your source `FastInvTrig` repo and ran the benchmarks from there, with a few tweaks to improve measurement accuracy and also added Lucene's [SloppyMath](https://javadoc.io/doc/org.apache.lucene/lucene-core/latest/org/apache/lucene/util/SloppyMath.html) into the competition. My results are directionally the same as yours - ``` Benchmark Mode Cnt Score Error Units FastInvTrigBenchmark.acosBM avgt 3 17.576 ± 1.243 ns/op FastInvTrigBenchmark.fastMathAcosBM avgt 3 87.301 ± 4.303 ns/op FastInvTrigBenchmark.haversineBM avgt 3 95.062 ± 17.137 ns/op FastInvTrigBenchmark.mathAcosBM avgt 3 140.391 ± 5.508 ns/op FastInvTrigBenchmark.sloppyHaversineMeters avgt 3 46.647 ± 8.927 ns/op FastInvTrigBenchmark.sloppyHaversineSortKey avgt 3 33.637 ± 6.364 ns/op ``` One concern for comparison that I have would be that the current Lucene implementation (which is only 2x slower than yours) has an upper error bound of 40cm. I think we can get there with your series expansions by adding additional terms, but I don't remember my calculus well enough to know how many we need. If we do that, how much does performance suffer? Are we still competitive? You're currently at 10m, which I suspect might be too large of a delta to be useful for the applications that I am familiar with. -- 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]
