tang-hi commented on issue #12396: URL: https://github.com/apache/lucene/issues/12396#issuecomment-1620965832
Switching from LongVector to IntVector is feasible, especially for 128-bit, as there are only a few modifications needed. Special handling may be required for 256-bit and 512-bit, but it shouldn't be a big issue. Additionally, when the output is also int[], the handling will be simpler. For example, if it were long[] and bpv was 3, we would need to store it as six longs, which cannot be evenly divided by four. However, with int[], this problem doesn't exist. Currently, I am more concerned about the scalar code. Yesterday, I tested it and found that the original scalar code was amazingly fast, almost on par with the SIMD speed at 50 op/us. On the other hand, the code using the new compression format only achieved around 10+ op/us. I would like to know if we can tolerate some performance loss in the scalar code if we switch the compression format. What is the minimum performance threshold we can accept? -- 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
