RFR: 8256431: [PPC64] Implement Base64 encodeBlock() for Power64-LE

[Martin Doerr]

On Tue, 17 Nov 2020 01:35:05 GMT, Corey Ashford <github.com+51754783+CoreyAshford at openjdk.org> wrote:

> Add a vector-based implementation of the Base64 encodeBlock intrinsic for Power9 and Power10, little-endian Linux only.
> 
> This implementation is based upon a paper (linked in comments) describing an Intel SSE vector-based implementation of Base64 encoding.  Although the Intel SSE instruction set and the Power VMX/VSX instruction sets are different, the method used in the paper is adaptable to Power.  In addition there are a few places in the algorithm where it's possible to gain some performance by using more optimal instruction sequences for VMX/VSX, and some additional benefit is gained from the ISA 3.1 additions available in Power10.
> 
> There is one controversial method I used in this implementation: I defined a macro to emit the instruction sequence for encoding 12 bytes in a vector to 16 bytes, because this sequence is needed in three places.  Turning it into a function would have been possible, but I would have needed to pass quite a few register numbers into the function.  I would have liked to have used a nested function, to give the function visibility to the register numbers declared in the outer scope, but alas nested functions are not possible in C++.
> 
> The overall performance advantage on Power9 is about 4.0X, based on the main/java/org/openjdk/micro/bench/java/util/Base64VarLenEncode.java benchmark.  This benchmark covers random buffer lengths from 8 to 20007 bytes.  Buffers that are short won't perform as well, approaching the performance of the pure Java code (or slightly worse for very short buffers),  Buffers that are consistently long will perform a little better than 4.0X.

src/hotspot/cpu/ppc/stubGenerator_ppc.cpp line 4036:

> 4034:        // 5.4X slower.  So on P9, we replace lxvl with a conditional
> 4035:        // unaligned load sequence, based on the alignment of the address
> 4036:        // and the length of the data requested.

This code looks like it is more than 5.4X slower than fast lxvl and hence slower than slow lxvl.

-------------

PR: https://git.openjdk.java.net/jdk/pull/1245