Hi Paul
I have updated the patch in this webrev:
http://cr.openjdk.java.net/~vdeshpande/vectorizedMismatch_jdk/webrev.04/
Will push that soon.
Regards,
Vivek
-Original Message-
From: Deshpande, Vivek R
Sent: Thursday, June 21, 2018 4:14 PM
To: Paul Sandoz
Cc: roger.ri...@oracle.com;
Thanks Paul for taking some time and thinking about it.
I will make the change you have mentioned and send the patch again.
Regards,
Vivek
-Original Message-
From: Paul Sandoz [mailto:paul.san...@oracle.com]
Sent: Thursday, June 21, 2018 3:32 PM
To: Deshpande, Vivek R
Cc:
Hi Vivek,
This looks better. I thought a bit more about NaNs. I am concerned about edge
case performance regressions if the first two values are NaNs (with the same
bit pattern). Here’s a patch on top of your patch that compares the raw bits
for float/double elements. If you are ok with this
Hi Paul
The folding of if/else is the right way in this patch which I missed in earlier
webrev.
http://cr.openjdk.java.net/~vdeshpande/vectorizedMismatch_jdk/webrev.03/
I think I would keep the same earlier path if both the values are NaN.
Thanks.
Regards,
Vivek
From: Paul Sandoz
Yes makes sense. Good catch :)
Thanks :)
Regards,
Vivek
-Original Message-
From: Ivan Gerasimov [mailto:ivan.gerasi...@oracle.com]
Sent: Wednesday, June 20, 2018 5:24 PM
To: Deshpande, Vivek R
Cc: Paul Sandoz ; core-libs-dev@openjdk.java.net
Subject: Re: RFR(S): 8205194: Improve the
Hi Vivek,
459 public static int mismatch(float[] a, int aFromIndex,
460float[] b, int bFromIndex,
461int length) {
462 int i = 0;
463 if (length > 1) {
464 if (a[aFromIndex] != b[bFromIndex]) {
Hi Vivek!
I think you don't need this if block:
464 if (a[aFromIndex] != b[bFromIndex]) {
465 i = 0;
466 }
i is already 0 anyway, and the following line is just enough.
467 if (a[aFromIndex] == b[bFromIndex]) {
The same applies to other
Hi Paul
I have made the change you have suggested.
Please find the updated webrev at this location:
http://cr.openjdk.java.net/~vdeshpande/vectorizedMismatch_jdk/webrev.02/
Regards,
Vivek
From: Paul Sandoz [mailto:paul.san...@oracle.com]
Sent: Wednesday, June 20, 2018 2:30 PM
To: Deshpande,
459 public static int mismatch(float[] a, int aFromIndex,
460float[] b, int bFromIndex,
461int length) {
462 int i = 0;
463 if (length > 1) {
464 if (a[aFromIndex] != b[bFromIndex]) {
465
Hi All
I have updated the webrev with all the suggestions, which passes
ArraysEqCmpTest.java.
Earlier webrev failed the same test.
This webrev also modifies the BufferMismatch.java in similar way.
Please take a look and let me know what you think.
Updated webrev is here:
Hi Roger
I will also test with zero length arrays and let you know.
Thanks for the input.
Regards,
Vivek
From: Deshpande, Vivek R
Sent: Tuesday, June 19, 2018 10:17 AM
To: 'Paul Sandoz'
Cc: David Holmes ; core-libs-dev@openjdk.java.net;
Viswanathan, Sandhya
Subject: RE: RFR(S): 8205194:
Thanks Paul for quick review. I will work on the things you have mentioned and
get back soon.
I will also test this with test/jdk/java/util/Arrays/ArraysEqCmpTest.java.
Regards,
Vivek
From: Paul Sandoz [mailto:paul.san...@oracle.com]
Sent: Tuesday, June 19, 2018 9:55 AM
To: Deshpande, Vivek R
Hi Vivek,
Thanks for investigating this.
164 public static int mismatch(boolean[] a,
165boolean[] b,
166int length) {
167 int i = 0;
168 if (a[i] != b[i])
169 return i;
You might as well replace
Thanks David.
Sending it to core-libs-dev.
I would like to contribute a patch which improves the array comparison when
there is a mismatch for the first element.
This avoids call to vectorizedMismatch method and gives ~80x speed up.
Could you please review and sponsor the patch.
Link to bug:
Hi Vivek,
Do you need to concerned that the arrays are zero length?
Are there any tests that test the zero length case.
(I assume you ran the existing tests).
Thanks, Roger
On 6/18/2018 7:52 PM, Deshpande, Vivek R wrote:
Hi All
Forgot to add the links:
15 matches
Mail list logo
