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

[Kamath, Smita]

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.