rmuir commented on PR #12743: URL: https://github.com/apache/lucene/pull/12743#issuecomment-1792596894
@ChrisHegarty I did some investigation, looked at the assembly on ARM machines, did some experiments, etc. I didn't mess around with intel, but i think the situation is the same. My thoughts: * lots of overhead here for each loop iteration other than just `mul`/`madd` for what we do here. so there's some room left on the table on some cpus. * does not help the other functions as they have more going on already * does not help vector functions, specific to this one * cannot find a way to get more parallelism e.g. on the arm it is more than just `ldrsb` to load from byte array, convert to int, sign-extend, etc. There is the overhead of the loop too. so we just get a little more parallelism out of this simple function. for the other functions here this trick is not helpful: they already have a "meatier" loop body if that makes sense. So I think we should commit the little trick for now. The way to get more parallelization long-term for this method is to use the correct cpu instructions (e.g. `sdot`): https://developer.arm.com/documentation/102651/a/What-are-dot-product-intructions- . As the documentation states, with 128-bit vectors it can do 64 dot products per cycle. I assume possibly twice that on 256-bit vectors. on intel there is a similar feature. I don't even know where to begin/suggest when looking at vector API, how such instructions would be exposed. It is like a VectorOperator which is both ternary and conversion :). The best idea i have, would be to expose it as ternary operator on ByteVector that returns ByteVector and force the user to reinterpret the underlying bits as IntVector. -- 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
