RFR(S) JDK-8205528: Base64 Encode Algorithm using AVX512 Instructions

[Paul Sandoz]

Hi Smita,

I am ok with it if Vladimir is :-) One slight concern is this may be biasing towards the x86 implementation of the intrinsic. I dunno if an int[] table is as useful for an AARCH64 intrinsic.

Paul.

> On Jun 22, 2018, at 3:25 PM, Kamath, Smita <smita.kamath at intel.com> wrote:
> 
> Hi Paul,
> 
> I can change the Java arrays(toBase64URL and toBase64) to int[] and use them in the intrinsic if it is acceptable. Please let me know.
> 
> Thanks,
> Smita
> 
> -----Original Message-----
> From: Paul Sandoz [mailto:paul.sandoz at oracle.com] 
> Sent: Friday, June 22, 2018 3:18 PM
> To: Kamath, Smita <smita.kamath at intel.com>
> Cc: Vladimir Kozlov <vladimir.kozlov at oracle.com>; hotspot compiler <hotspot-compiler-dev at openjdk.java.net>
> Subject: Re: RFR(S) JDK-8205528: Base64 Encode Algorithm using AVX512 Instructions
> 
> 
> 
>> On Jun 22, 2018, at 3:00 PM, Kamath, Smita <smita.kamath at intel.com> wrote:
>>> Looks like you changed all need place to implement intrinsic.
>>> One question so: why you have own copy of base64 charsets and not using one in library:
>>> 
>>>       private int encode0(byte[] src, int off, int end, byte[] dst) {
>>>           char[] base64 = isURL ? toBase64URL : toBase64;
>>> 
>> 
>> Yes, especially if we converted those from char[] to byte[] (which might also improve the C2 generated code) and pass the selected byte[] to the intrinsic. 
>> Smita>>  I need an integer array in order to use vpgatherdd instruction with vector index. Vpgather instruction works on 32 bit array and so I need to define base64 charset in a 32 bit array.
>> 
> 
> Thanks, I also saw your reply to Vladimir and see why you need this [*]. We could still unify leveraging a Java int[] array at the expense of extra space required on non-intrisified platforms. IMHO the less stub code and the more Java code the better with regards to maintenance.
> 
> 
>> Naming wise for the Java methods here are some suggestions:
>> 
>> generateImplEncode -> encodeBlockWithBoundsCheck  implEncode -> 
>> encodeBlock
>> 
>> Also can generateImplEncode be private?
>> Smita>> I'll make these changes and send an updated webrev.
>> 
> 
> Ok.
> 
> 
>> Further. is there is a need to perform bounds checks in generateImplEncode given the public methods calling encode will, i presume, have dominating checks?
>> Smita>> The check is not required. I'll retain encodeBlock and remove encodeBlockWithBoundsCheck. 
>> 
> 
> Ok.
> 
> Thanks,
> Paul.
> 
> [*] On AVX-512 it's tempting to explore permute/rearrange operations on bytes, if there are any such instructions, since the translation array of bytes (toBase64URL or toBase64) fits neatly into one z register, or for AVX-2 in two y registers if some masked variant, based on ranges, is possible.