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,
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..5
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
to 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 wrote:
On 9/4/20
ray 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 reply and thoughts!
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
w contributors
and assist as far as we can.
Best regards,
Martin
-Original Message-
From: Corey Ashford
Sent: Donnerstag, 27. August 2020 00:17
To: Doerr, Martin ; Michihiro Horie
Cc: hotspot-compiler-...@openjdk.java.net; core-libs-dev ; Kazunori Ogata ;
jos...@br
velopers.
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 benchmark tries to be "fair" in that it doesn't prefer a
large
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. August 2020 15:38
To: Corey Ashf
rom: 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
Hi Corey
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, Corey Ashford wrote:
Mi
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
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
, 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" ---2020/06/24
09:40:10--
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
for your consideration,
- Corey
Corey Ashford
Software Engineer
IBM Systems, LTC OpenJDK team
503-985-8699 Home office
cjash...@us.ibm.com
IBM
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
