rmuir commented on issue #12399: URL: https://github.com/apache/lucene/issues/12399#issuecomment-1612499383
> Yeah, some of our custom sorts are because we want to sort one array, but use the sort key from another parallel array. Unfortunately I don't think (?) the JDK has existing APIs for this usage, yet, the way the SIMD sorting works, it would be a perfect fit (it reports the indices into the array that it then permute to, to achieve the sort ... so we'd want those sorted indices so we could permute our own (possible non-primitive) arrays). I really don't think this is a good candidate for lucene. I would actually be opposed to merging any code that does this. Here's why: * Vector API is in incubation and has very high maintenance cost for us * Vector API has a lot of performance landmines * sorting is not a mega hotspot in any of our benchmarks * algorithm is AVX 512 only I see lots of issues being opened to vectorize this or that, and I know it's soon my time to play bad guy again, but I can and will veto performance gains that are overall a bad tradeoff. This would be one of them. We should really focus on only the hottest of hotspots, we should really focus on the big wins where vectorization is a natural fit, and where it works on most everyone's hardware, and seek to *minimize* the surface area we touch with vector API. -- 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: issues-unsubscr...@lucene.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
