On Tue, 8 Jun 2021 00:11:42 GMT, Scott Gibbons
wrote:
>> src/java.base/share/classes/java/util/Base64.java line 813:
>>
>>> 811: while (sp < sl) {
>>> 812: if (shiftto == 18 && sp < sl - 4) { // fast path
>>> 813: int dl = decodeBlock(src, s
On Mon, 7 Jun 2021 13:20:20 GMT, Scott Gibbons
wrote:
>> Add the Base64 Decode intrinsic for x86 to utilize AVX-512 for acceleration.
>> Also allows for performance improvement for non-AVX-512 enabled platforms.
>> Due to the nature of MIME-encoded inputs, modify the intrinsic signature to
>>
On Tue, 22 Sep 2020 02:45:36 GMT, Corey Ashford
wrote:
> This patch set encompasses the following commits:
>
> - Adds a new HotSpot intrinsic candidate to the java.lang.Base64 class -
> decodeBlock(), and provides a flexible API for the intrinsic. The API is
> similar
On Mon, 26 Oct 2020 19:27:59 GMT, Paul Murphy
wrote:
>> Because the bytes are displayed e15..e8, instead of the other way around,
>> it's hard to follow. As an example, consider just the last four bytes of
>> the table, but displayed in the reverse order:
>>
>> 00||b0:0..500||b0:6..7||b1
On 10/26/20 12:47 PM, Paul Murphy wrote:
On Thu, 22 Oct 2020 22:06:11 GMT, CoreyAshford
wrote:
src/hotspot/cpu/ppc/stubGenerator_ppc.cpp line 3878:
3876: // |Element| | |
| | |
understand the directives as
gcc on linux.
Gcc 7.3.1 is the minimum for BE linux.
But if you protect your code by #ifdef VM_LITTLE_ENDIAN no compiler except gcc
>= 7.4.0 should ever look at it.
Best regards,
Martin
-Original Message-
From: Corey Ashford
Sent: Dienstag, 1. September 2020
Note, this patch set is now on a new thread in the mailing list, due to
the switchover from Mercurial to Git.
Regards,
- Corey
On 9/9/20 4:32 PM, Corey Ashford wrote:
On 9/9/20 2:04 PM, Roger Riggs wrote:
Hi Corey,
Right, the continue was so it would go back and check if the
conversion
o the intrinsic,
it's not clear there will be a performance gain when isMIME==true, but a
benchmark should make that clear. I'm guessing maybe 1.5X to 2X is
about the best that could be expected when linemax is the default 76.
- Corey
Thanks, Roger
On 9/9/20 3:13 PM, Corey Ashford wr
causing an array bounds error.
So this needs to be re-thought a little, but it shouldn't be too
difficult. I will work on it.
Regards,
- Corey
Regards, Roger
On 8/31/20 6:22 PM, Corey Ashford wrote:
On 8/29/20 1:19 PM, Corey Ashford wrote:
Hi Roger,
Thanks for your
On 8/27/20 8:07 AM, Doerr, Martin wrote:
I will use __attribute__ ((align(16))) instead of __vector, and make
them arrays of 16 unsigned char.
Maybe __vectors works as expected, too, now. Whatever we use, I'd appreciate to
double-check the alignment e.g. by using gdb.
I don't remember what we
On 8/29/20 1:19 PM, Corey Ashford wrote:
Hi Roger,
Thanks for your reply and thoughts! Comments interspersed below:
On 8/28/20 10:54 AM, Roger Riggs wrote:
...
Comparing with the way that the Base64 encoder was intrinsified, the
method that is intrinsified should have a method body that
atience and careful review is really
appreciated.
I'm glad you work on contributions. I think we should welcome new contributors
and assist as far as we can.
Best regards,
Martin
-Original Message-
From: Corey Ashford
Sent: Donnerstag, 27. August 2020 00:17
To
days a week, so the updates will be slower compared
to other developers.
Thanks, Roger
On 8/24/20 9:21 PM, Corey Ashford wrote:
Here's a revised webrev which includes a JMH benchmark for the decode
operation.
http://cr.openjdk.java.net/~mhorie/8248188/webrev.03/
The added benchmar
ng about
returning the number of bytes already written, which will allow
decodeBlockSlow to more quickly find the offending character. This
provides another good reason to make that change.
Best regards,
Martin
-Original Message-
From: Doerr, Martin
Sent: Dienstag, 25. Au
Message-
From: Doerr, Martin
Sent: Dienstag, 25. August 2020 15:38
To: Corey Ashford ; Michihiro Horie
Cc: hotspot-compiler-...@openjdk.java.net; core-libs-dev ; Kazunori Ogata ;
jos...@br.ibm.com
Subject: RE: RFR(M): 8248188: [PATCH] Add HotSpotIntrinsicCandidate and
API for Base64 decoding
ent and prove it is worthwhile to add code complexity.
I don't see any existing Base64 JMH tests but they would be in the repo
below or near:
test/micro/org/openjdk/bench/java/util/
Please contribute a JMH test and results to show the difference.
Regards, Roger
On 8/19/20 2:10 PM
Just as a general comment, an SIMD-based encode() intrinsic would be an
easy performance upgrade for this Hex class. I'd guess you'd get a
5x-10x improvement, depending on the specific CPU/arch being used. That
said, the intrinsic would do better on larger buffers, and I don't know
what the av
Hi Roger,
Thank you for your reply. I wasn't aware of this practice, and will get
to work on creating and contributing a test.
Regards,
- Corey
On 8/19/20 11:20 AM, Roger Riggs wrote:
Hi Corey,
For changes obviously performance motivated, it is conventional to run a
JMH perf test to demo
On 6/23/20 6:23 PM, Michihiro Horie wrote:
Hi Corey,
Following is the issue I created.
https://bugs.openjdk.java.net/browse/JDK-8248188
I will upload a webrev when you're ready as we talked in private.
Best regards,
Michihiro
Inactive hide details for "Corey Ashford" ---
This is an accidental duplicate post. Please disregard.
On 8/10/20 2:00 PM, Corey Ashford wrote:
Hello,
I had originally made two posts to the hotspot-compiler-dev and
ppc-aix-port-dev mailing lists, but since this RFR requires modifying
the core library code, it makes sense to post it to
to any comments about this.
Thanks for your consideration,
- Corey
Corey Ashford
Software Engineer
IBM Systems, LTC OpenJDK team
503-985-8699 Home office
cjash...@us.ibm.com
IBM
to any comments about this.
Thanks for your consideration,
- Corey
Corey Ashford
Software Engineer
IBM Systems, LTC OpenJDK team
503-985-8699 Home office
cjash...@us.ibm.com
IBM
22 matches
Mail list logo
