
<!DOCTYPE html><html><head><title></title><style type="text/css">p.MsoNormal,p.MsoNoSpacing{margin:0}</style></head><body><div>For reference, we have published a C# library for Base64 decoding:<br></div><div><br></div><div><a href="https://github.com/simdutf/SimdBase64">https://github.com/simdutf/SimdBase64</a><br></div><div><br></div><div>This is another example of a library that cannot be written (with good performance) in Java right now.<br></div><div><br></div><div>I thought it might be useful to provide another example.<br></div><div><br></div><div>(Note that I am *not* biased in favour of C# nor am I promoting C#. I am only using C# as a reference due to the obvious similarity between C# and Java.)</div><div><br></div><div>- Daniel</div><div><br></div><div>On Fri, Jun 28, 2024, at 12:51, Paul Sandoz wrote:<br></div><blockquote type="cite" id="qt" style=""><div><br></div><div><br></div><div>> On Jun 28, 2024, at 9:36 AM, Chris Hegarty <<a href="mailto:chegar999@gmail.com">chegar999@gmail.com</a>> wrote:<br></div><div>> <br></div><div>> Hi,<br></div><div>> <br></div><div>> <br></div><div>> On 21/06/2024 21:11, Paul Sandoz wrote:<br></div><div>>> Hi Daniel,<br></div><div>>> Thanks for the email discussion. I think we can do better and get to, or closer to, your expectation on the generation of a single instruction.<br></div><div>>> At the moment rearrange performs bounds checks on the shuffle argument (checking for exceptional indexes), and selectFrom converts a vector to a shuffle and calls rearrange. <br></div><div>> <br></div><div>> ...<br></div><div>> <br></div><div>> We've run into this separately too. If memory serves me correctly, it was slice(int) using rearrange internally to only then do expensive bounds checks on the implementation specific shuffle. ( I can try to dig out the details if I've mixed up something here. )<br></div><div>> <br></div><div><br></div><div>Please share if you can (I recall you may have mentioned this to me in the past, and I probably said “hmm…. this is tricky"). Benchmarks/code can really help focus our efforts.<br></div><div><br></div><div><br></div><div>> Bounds checks on input at the API level is expected, but not when the rearrange is an implementation detail.<br></div><div>> <br></div><div>> More generally, the system property has been around for a while now, and from my understanding it's a workaround to the compiler not yet being able to eliminate the checks. Firstly, is this understanding correct? And if so, is the intention to eventually remove it when it is no longer needed?<br></div><div>> <br></div><div><br></div><div>The system property is for debugging, it’s not intended for production use. Ideally it would go away, but it’s a useful "break glass in emergency". My usage was intended to show what might be possible if we can enhance the API and/or implementation appropriately.<br></div><div><br></div><div>Paul.<br></div><div><br></div><div>> ...<br></div><div>> <br></div><div>> > To be fair, it is fine if folks say "No, we don't want to do this with Java Vector, we don't want to optimize indexing in Lucene, we want to do X".<br></div><div>> <br></div><div>> Lucene is already using the Panama Vector API to improve the performance of vector similarity comparisons - for vector search. We would love to use it for more, but are largely hampered by the above issue. A less ideal situation is that in Elasticsearch [1] we're now using Panama FFI to workaround the limitations of the Vector API by linked to our own optimized implementations. This not ideal, and effectively robs Lucene of these potential performance benefits (since it's non-trivial to ship Lucene with a native lib)<br></div><div>> <br></div><div>> -Chris.<br></div><div>> <br></div><div>> [1] <a href="https://urldefense.com/v3/__https://github.com/elastic/elasticsearch/tree/main/libs/simdvec__;!!ACWV5N9M2RV99hQ!OZZEZlRHgbdC6YncLGIyD41hdpE2pHOo9-alCbMm7qzTPbmxPPLN1-IzNwnemXh3PnfOwsjdiwb5Qzrw4EM$">https://urldefense.com/v3/__https://github.com/elastic/elasticsearch/tree/main/libs/simdvec__;!!ACWV5N9M2RV99hQ!OZZEZlRHgbdC6YncLGIyD41hdpE2pHOo9-alCbMm7qzTPbmxPPLN1-IzNwnemXh3PnfOwsjdiwb5Qzrw4EM$</a> <br></div><div><br></div><div><br></div></blockquote><div><br></div></body></html>