<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On May 10, 2018, at 5:50 AM, Dmitrij Pochepko <<a href="mailto:dmitrij.pochepko@bell-sw.com" class="">dmitrij.pochepko@bell-sw.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class="">
  
    <meta http-equiv="Content-Type" content="text/html; charset=utf-8" class="">
  
  <div text="#000000" bgcolor="#FFFFFF" class=""><p class=""><br class="">
    </p>
    <br class="">
    <div class="moz-cite-prefix">On 09.05.2018 01:36, Paul Sandoz wrote:<br class="">
    </div>
    <blockquote type="cite" cite="mid:7228956E-9497-41C7-A8DC-8A8F3139F72C@oracle.com" class="">
      <pre wrap="" class="">
</pre>
      <blockquote type="cite" class="">
        <pre wrap="" class="">On May 8, 2018, at 6:31 AM, Dmitrij Pochepko <a class="moz-txt-link-rfc2396E" href="mailto:dmitrij.pochepko@bell-sw.com"><dmitrij.pochepko@bell-sw.com></a> wrote:



On 04.05.2018 16:46, Andrew Haley wrote:
</pre>
        <blockquote type="cite" class="">
          <pre wrap="" class="">On 05/04/2018 02:24 PM, Dmitrij Pochepko wrote:
</pre>
          <blockquote type="cite" class="">
            <pre wrap="" class="">Do you suggest to change vectorizedMismatch from generic single entry
point to 4 versions (1,2,4 and 8 -byte) each optimized for respective
size(and possible re-using code generation logic)? Then it can be
re-used for same-encoded strings without penalties, indeed, but it
requires changes in jdk.internal.util.ArraysSupport.java
</pre>
          </blockquote>
          <pre wrap="" class="">I don't see why it's absolutely necessary.  On the other hand, it might
be an excellent idea to have a switch statement in the Java code wich
will almost always optimized away.  It's worth trying.

</pre>
        </blockquote>
        <pre wrap="" class="">As this is a separate possibly multiplatform effort which potentially affects common code and x86 platform intrinsic implementation I created a separate enhancement for this issue: <a class="moz-txt-link-freetext" href="https://bugs.openjdk.java.net/browse/JDK-8202783">https://bugs.openjdk.java.net/browse/JDK-8202783</a>

</pre>
      </blockquote>
      <pre wrap="" class="">Thank you (i cannot look at the issue right now as JBS is down for maintenance).

I don’t understand why you need to convert vectorizedMismatch to 4 versions, the stub is generated using the most optimal vector instructions for the platform (on x86). A single version should suffice with surrounding Java code detecting thresholds and managing the tail elements. See the wrapping Java methods in jdk.internal.util.ArraysSupport and similar methods in java.nio.BufferMismatch. (Note that fixed thresholds are used, and i did not do any measurements on platforms with larger vector sizes to determine if the thresholds should be adjusted, but vectorizedMismatch implementation will use smaller vectors sizes if need be.)

Paul.</pre>
    </blockquote>
    <font size="-1" class="">I was looking at existing vectorizedMismatch
      implementation (x86). It handles whole array length, including
      tail handling (which is basically duplicates java code tail
      handling), so, last "for" block is always skipped. I suspect it
      was done this way for better performance.</font></div></div></blockquote><div><br class=""></div>Yes, the specification is written such that a <font size="2" class="">vectorizedMismatch implementation can bail out at any index and the Java code can deal with the rest, but the implementation does not have to, it's an optimization decision. Note that the Java code for the tail also deals with lengths under the threshold to call </font><span style="font-size: small;" class="">vectorizedMismatch.</span></div><div><font size="2" class=""><br class=""></font></div><div><font size="2" class=""><br class=""></font><blockquote type="cite" class=""><div class=""><div text="#000000" bgcolor="#FFFFFF" class=""><font size="-1" class=""> In case final solution
      will be to handle whole array in vectorizedMismatch, I think we
      have one more way to improve it, since, for example, 2-byte
      version doesn't need 1-byte loop inside intrinsic code(and doesn't
      need respective check).</font></div></div></blockquote><div><br class=""></div>As lengths get larger it might matter less. I think its worth doing some measurements to help inform which direction to take.</div><div><br class=""></div><div>Paul.</div><div><br class=""><blockquote type="cite" class=""><div class=""><div text="#000000" bgcolor="#FFFFFF" class=""><font size="-1" class=""> That was my thoughts and reason for
      considering 4 versions. In case vectorizedMismatch will be used
      strictly for 8-byte loads, then there is obviously no need to have
      4 implementations.<br class="">
      <br class="">
      Thanks,<br class="">
      Dmitrij<br class="">
    </font>
    <blockquote type="cite" cite="mid:7228956E-9497-41C7-A8DC-8A8F3139F72C@oracle.com" class="">
      <pre wrap="" class="">
</pre>
      <blockquote type="cite" class="">
        <pre wrap="" class="">Let me know if you have any comments on the patch.

Thanks,
Dmitrij
</pre>
      </blockquote>
      <pre wrap="" class=""></pre>
    </blockquote>
    <br class="">
  </div>

</div></blockquote></div><br class=""></body></html>