shubhamvishu commented on PR #15508: URL: https://github.com/apache/lucene/pull/15508#issuecomment-3666453702
Thanks @dweiss for taking a look. I completely agree with maintaining different native bindings in Lucene can get really challenging as you mentioned and I propose we **don't ship don't ship any pre-built binaries** (or to say at least in this PR today if someone feels otherwise). I got some cross environment binaries working but this is a never ending process and we will not be able to support all permutations/combinations of the different environments. While I got some cross-platform binaries working for few selective environments, supporting all environment permutations will be really painful. I added the build configuration to test across different environments on my end. I'm more happy to remove the Gradle build configurations for binary generation. One important point here is that GCC's auto-vectorization of simple C code performs comparably to (and sometimes better than) hand-written NEON/SVE implementations(except some cases/runs for SVE). This allows us to keep things simple on Lucene's end and let users experiment. This is inline with what @rmuir proposed [here in this comment](https://github.com/apache/lucene/pull/13572#issuecomment-2230061569). So here is what I propose we can do and would look like for user : - We can maybe keep simple dot product implementation in the C code in `dotProduct.c` in the `lucene/misc` as-is but not build it. - Instead, we let the Lucene user to optionally generate the binary on their end using `gcc -shared -O3 -march=native -funroll-loops -o <c_file>` on the platform they wish to run (or) they would need to do so for whichever compiler and environment they are targeting(we can add more documentation if req.). User could either use the default `dotProduct.c file` with auto-vectorization or get creative and provide a more performant implementation if they wish to. - To enable the native dot product codepath they could pass the `-Dlucene.useNativeDotProduct=true` system property. Contract: This PR would enable the interface to interact with binaries for dot product computations but providing that binary is in user's court. Users need to provide the binary with the required signature/impl: `int32_t dot8s(int8_t vec1[], int8_t vec2[], int32_t limit);` Let me know if this makes it clear for what it would look like from Lucene user's perspective. -- 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]
