RFR(M): 8216060: [PPC64] Vector CRC implementation should be used by interpreter and be faster for short arrays
gromero at linux.vnet.ibm.com
Thu Jan 3 16:13:23 UTC 2019
oh that's nice. You removed the 512-byte block constraint and also wired it up to the Interpreter :)
For the worst case, unaligned 512 byte array, I see the gap to aligned 512 byte array reduced by about ~5.7x.
On the Interpreter I see an improvement of at least 50% for 1024 bytes.
This is all for the CRC32 class.
On CRC32C I'm getting a SIGSEV that can be reproduced running against ./test/hotspot/jtreg/compiler/intrinsics/zip/TestCRC32C.java.
I've upload a full log into http://cr.openjdk.java.net/~gromero/logs/crc32c_sigsegv/
I'm leaving for the lunch and I'll take a closer look when back. But probably you will figure it out before I sit to appreciate the meal :)
Finally, since the change does some cleanup, I wonder if it would be worth fixing the following typos:
I think it's Barrett const., not Barret. Probably 'barret' is used in the code as a short version
for Barrett but it should be changed in
+ // Point to Barret constants
+ add_const_optimized(cur_const, constants, outer_consts_size + inner_consts_size);
cpu/ppc/macroAssembler_ppc.cpp:3977:// A not on the lookup table address(es):
cpu/ppc/macroAssembler_ppc.cpp:4265: mtvrwz(VCRC, crc); // crc lives lives in VCRC, now
On 01/03/2019 12:17 PM, Doerr, Martin wrote:
> the JVM on PPC64 currently misses usage of the fast vector implementation in the interpreter code.
> In addition, performance is not good for short arrays (unaligned 512 byte arrays or shorter arrays) because the current vector implementation needs at least 512 bytes.
> I have addressed these 2 issues + some cleanup with the following webrev:
> http://cr.openjdk.java.net/~mdoerr/8216060_PPC64_CRC/webrev.00/ <http://cr.openjdk.java.net/%7Emdoerr/8216060_PPC64_CRC/webrev.00/>
> Please review.
> Best regards,
More information about the hotspot-compiler-dev