On Tue, 7 Jun 2022 12:34:25 GMT, Claes Redestad wrote:
> - Reduce runtime by running fewer forks, fewer iterations, less warmup. All
> micros tested in this group appear to stabilize very quickly.
> - Refactor BigIntegers to avoid re-running some (most) micros over and over
> with parameter val
/was JEP 306 and/or to which
depth it meant by "restore always-strict floating-point semantics", but I don't
think that I am the only one out there.
JEP 306 isn't about j.l.StrictMath. The Description section of 306
says what it's really about.
--
Andrew Haley (h
.
You're right.
--
Andrew Haley (he/him)
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
https://keybase.io/andrewhaley
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671
intrinsics (log, trig) that
are faster than StrictMath and also more accurate. StrictMath is not
about accuracy, but cross-architecture down-to-the-last bit reproducibility.
Whether we still need that reproducibility is, I suppose, something for
debate.
--
Andrew Haley (he/him)
Java Platform Lead
On Wed, 27 Apr 2022 19:21:58 GMT, Alan Bateman wrote:
>> src/java.base/share/classes/jdk/internal/misc/UnsafeConstants.java line 122:
>>
>>> 120: */
>>> 121:
>>> 122: public static final int SCOPED_CACHE_SHIFT;
>>
>> I can't find this constant being used. If added for future, maybe
onormal inclusion?
In a word, no. That possibility is so unlikely that it is not worthy
of consideration.
--
Andrew Haley (he/him)
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
https://keybase.io/andrewhaley
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671
On Sun, 13 Mar 2022 06:36:15 GMT, Jatin Bhateja wrote:
>> Summary of changes:
>> - Intrinsify Math.round(float) and Math.round(double) APIs.
>> - Extend auto-vectorizer to infer vector operations on encountering scalar
>> IR nodes for above intrinsics.
>> - Test creation using new IR testing fra
program. I know, unlikely, but
we preserve compatibility.
--
Andrew Haley (he/him)
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
https://keybase.io/andrewhaley
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671
On Sun, 13 Mar 2022 04:27:25 GMT, Jatin Bhateja wrote:
>> src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 4024:
>>
>>> 4022: * the result is equal to the value of Integer.MAX_VALUE.
>>> 4023: */
>>> 4024: void
>>> C2_MacroAssembler::vector_cast_float_special_cases_avx(XMMRegister dst,
>>>
On Wed, 9 Mar 2022 11:38:34 GMT, Jatin Bhateja wrote:
>> Summary of changes:
>> - Intrinsify Math.round(float) and Math.round(double) APIs.
>> - Extend auto-vectorizer to infer vector operations on encountering scalar
>> IR nodes for above intrinsics.
>> - Test creation using new IR testing fram
On Wed, 9 Mar 2022 11:38:34 GMT, Jatin Bhateja wrote:
>> Summary of changes:
>> - Intrinsify Math.round(float) and Math.round(double) APIs.
>> - Extend auto-vectorizer to infer vector operations on encountering scalar
>> IR nodes for above intrinsics.
>> - Test creation using new IR testing fram
On Wed, 2 Mar 2022 02:44:41 GMT, Jatin Bhateja wrote:
>> Summary of changes:
>> - Intrinsify Math.round(float) and Math.round(double) APIs.
>> - Extend auto-vectorizer to infer vector operations on encountering scalar
>> IR nodes for above intrinsics.
>> - Test creation using new IR testing fram
On Wed, 2 Mar 2022 02:44:41 GMT, Jatin Bhateja wrote:
>> Summary of changes:
>> - Intrinsify Math.round(float) and Math.round(double) APIs.
>> - Extend auto-vectorizer to infer vector operations on encountering scalar
>> IR nodes for above intrinsics.
>> - Test creation using new IR testing fram
On Thu, 3 Mar 2022 13:31:35 GMT, Claes Redestad wrote:
> > Well, it just didn't build. With the annotation being present, you also
> > need an intrinsic implementation. That's what the error message is saying...
>
> Doh, I had no idea the presence of `@IntrinsicCandidate` was mandating the VM
On Thu, 3 Mar 2022 12:04:47 GMT, Claes Redestad wrote:
>> I'm requesting comments and, hopefully, some help with this patch to replace
>> `StringCoding.hasNegatives` with `countPositives`. The new method does a
>> very similar pass, but alters the intrinsic to return the number of leading
>> b
On Tue, 1 Mar 2022 19:12:17 GMT, Claes Redestad wrote:
> > @theRealAph , @a74nh or someone familiar with aarch64 code, please review
> > aarch64 changes.
>
> Note that the aarch64 changes I've put in for now implements `countPositives`
> to return `0` if there's a negative value anywhere, othe
On 3/1/22 11:45, Andrew Haley wrote:
Sure, you wouldn't
be able to use the default thread pool, but that's no big deal, I would have
thought.
I'm sorry, I'll say that again. :-)
I meant to say "you wouldn't be able to use the default thread pool if
you w
On 2/28/22 15:32, Andrew Haley wrote:
I think all we'd need is a set of capabilities bound to a scope local
at thread startup, and I guess it'd default to "all capabilities".
Trusted code could then override any of those capabilities.
We'd have to make sure that capab
On 2/28/22 15:12, Sean Mullan wrote:
>
> On 2/27/22 1:47 PM, Andrew Haley wrote:
>
>> I'd like to explore the use of scope locals as a lightweight means to
>> implement a system of permissions and capabilities for things such as
>> this.
>
> Now you have piq
pabilities for things such as
this.
--
Andrew Haley (he/him)
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
https://keybase.io/andrewhaley
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671
On Fri, 25 Feb 2022 10:19:17 GMT, Claes Redestad wrote:
>> test/micro/org/openjdk/bench/java/lang/StringDecode.java line 72:
>>
>>> 70: public void setup() {
>>> 71: charset = Charset.forName(charsetName);
>>> 72: asciiString = LOREM.substring(0, 32).getBytes(charset);
>>
>>
On Fri, 25 Feb 2022 09:19:33 GMT, Claes Redestad wrote:
>> Splitting out these micro changes from #7231
>>
>> - Clean up and simplify setup and code
>> - Add variants with different inputs with varying lengths and encoding
>> weights, but also relevant mixes of each so that we both cover intere
On Tue, 22 Feb 2022 16:10:22 GMT, Magnus Ihse Bursie wrote:
> This PR adds a new configure argument, `--enable-hsdis-bundling`. Setting
> this, together with a valid backend using `--with-hsdis`, will bundle the
> generated hsdis library with the JDK.
Maybe I missed it, but are there instructi
On 2/11/22 19:25, XenoAmess wrote:
On Fri, 11 Feb 2022 18:24:49 GMT, Andrew Haley wrote:
Just multiply by 0.75.
On a modern design, floating-point multiply is 4 clocks latency, 4 ops/clock
throughput. FP max is 2 clocks latency, conversions int-float and vice versa 3
clocks latency, 4 ops
On Sun, 13 Feb 2022 13:12:35 GMT, Jatin Bhateja wrote:
>>> Hi, IIRC for evex encoding you can embed the RC control bit directly in the
>>> evex prefix, removing the need to rely on global MXCSR register. Thanks.
>>
>> Hi @merykitty , You are correct, we can embed RC mode in instruction
>> enc
On Sun, 13 Feb 2022 03:09:43 GMT, Jatin Bhateja wrote:
>> Summary of changes:
>> - Intrinsify Math.round(float) and Math.round(double) APIs.
>> - Extend auto-vectorizer to infer vector operations on encountering scalar
>> IR nodes for above intrinsics.
>> - Test creation using new IR testing fra
On Fri, 11 Feb 2022 18:13:36 GMT, Roger Riggs wrote:
>> @RogerRiggs
>> so you recommend `(int) Math.min(((m.size() * 4L + 2L) / 3L),
>> Integer.MAX_VALUE)`? OK then, changed it.
>> please review again, thanks!
>
> Works for me. Thanks
Just multiply by 0.75.
On a modern design, floating-point
On 12/30/21 16:12, Alexander Scherbatiy wrote:
Would it be useful to have some kind of an immutable array in Java language
which works in the same way as ordinary array except it is not to
possible to change
its values after creation?
Yes. https://openjdk.java.net/jeps/8261007
--
Andrew
t could deepen in possible problems and
their solutions.
Everything is always harder than it looks at first.
--
Andrew Haley (he/him)
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
https://keybase.io/andrewhaley
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671
On Tue, 2 Nov 2021 06:25:33 GMT, Aleksey Shipilev wrote:
>> This blocks JDK-8276215: `StrictMath` intrinsics are handled peculiarly by
>> giving failing intrinsics a second chance to match against the similar
>> `Math` intrinsics. This has interesting consequence for matchers: we can
>> match
On Mon, 1 Nov 2021 11:23:16 GMT, Aleksey Shipilev wrote:
> This blocks JDK-8276215: `StrictMath` intrinsics are handled peculiarly by
> giving failing intrinsics a second chance to match against the similar `Math`
> intrinsics. This has interesting consequence for matchers: we can match the
>
On Thu, 28 Oct 2021 08:47:31 GMT, Aleksey Shipilev wrote:
> `Unsafe.{load|store}Fence` falls back to `unsafe.cpp` for
> `OrderAccess::{acquire|release}Fence()`. It seems too heavy-handed (useless?)
> to call to runtime for a single memory barrier. We can simplify the native
> `Unsafe` interfac
On Wed, 13 Oct 2021 18:55:10 GMT, Vamsi Parasa wrote:
> Optimize the new Math.unsignedMultiplyHigh using the x86 mul instruction.
> This change show 1.87X improvement on a micro benchmark.
test/micro/org/openjdk/bench/java/lang/MathBench.java line 547:
> 545: return Math.unsignedMulti
On Wed, 13 Oct 2021 18:55:10 GMT, Vamsi Parasa wrote:
> Optimize the new Math.unsignedMultiplyHigh using the x86 mul instruction.
> This change show 1.87X improvement on a micro benchmark.
src/hotspot/share/opto/mulnode.cpp line 468:
> 466: }
> 467:
> 468:
> //===
examples, where inlining changes
and each time a program is run it's either fast or slow, quasi-randomly.
If you really want to know, use -prof perfasm in JMH.
- Whether suggested changes is worth implementations?
IMO the gain is too small. Others may disagree.
--
Andrew Hale
On Thu, 14 Oct 2021 10:21:20 GMT, David Holmes wrote:
> See https://bugs.openjdk.java.net/browse/JDK-8275263 for some info on the
> failures. It seems really bizarre.
I would understand this a lot better if the affected machines actually used
SVE, but they don't have the hardware.
That does re
On Thu, 14 Oct 2021 06:37:19 GMT, Nick Gasson wrote:
> This reverts "8269559: AArch64: Implement string_compare intrinsic in SVE"
> which caused some unknown failures in Oracle's CI.
It might be a spurious failure, then. I guess we need to see the test logs.
-
PR: https://git.open
On Thu, 14 Oct 2021 07:08:20 GMT, David Holmes wrote:
> The issue is only on (some of) our macOS Aarch64 systems. Let me know if I
> can provide more info on hardware etc.
Any info about what failed? A reproducer would be nice.
-
PR: https://git.openjdk.java.net/jdk/pull/5941
On Fri, 16 Apr 2021 11:30:32 GMT, Raffaello Giulietti
wrote:
>> Hello,
>>
>> here's a PR for a patch submitted on March 2020
>> [1](https://cr.openjdk.java.net/~bpb/4511638/webrev.04/) when Mercurial was
>> a thing.
>>
>> The patch has been edited to adhere to OpenJDK code conventions about
gt; What do you think? Would this be a viable option?
It's a good-enough idea in theory, but I don't think it'd be accepted.
Pinging Joe Darcy: do you (or any of your friends) have a good way
to contact Guy Steele?
--
Andrew Haley (he/him)
Java Platform Lead Engineer
Red Hat UK
JVMs and it provides the reader with a simple
implementation.
I'm not at all sure we'd want a complex implementation.
Having said that, if I were looking at a faster pure Java version of
this logic, I'd look at MethodHandles.byteArrayViewVarHandle().
--
Andrew Haley (he/him)
Jav
On Mon, 23 Aug 2021 21:48:01 GMT, TatWai Chong
wrote:
>> This patch implements string_compare intrinsic in SVE.
>> It supports all LL, LU, UL and UU comparisons.
>>
>> As we haven't found an existing benchmark to measure performance impact,
>> we created a benchmark derived from the test [1] fo
On Fri, 16 Apr 2021 11:30:32 GMT, Raffaello Giulietti
wrote:
>> Hello,
>>
>> here's a PR for a patch submitted on March 2020
>> [1](https://cr.openjdk.java.net/~bpb/4511638/webrev.04/) when Mercurial was
>> a thing.
>>
>> The patch has been edited to adhere to OpenJDK code conventions about
On Mon, 20 Sep 2021 09:52:45 GMT, Andrew Dinn wrote:
>> Andrew, can you help us to approve this?
>
> I agree with Andrew Haley that this patch is not going to make an improvement
> for anything but a very small number of applications. Processing of strings
> over a few 10s of
On Mon, 30 Aug 2021 06:26:01 GMT, Wang Huang wrote:
>> Dear all,
>> Can you do me a favor to review this patch. This patch use `ldp` to
>> implement String.compareTo.
>>
>> * We add a JMH test case
>> * Here is the result of this test case
>>
>> Benchmark |(
really works if you want to
generate a lot of bits at a time. But it is maybe 128 randomish bits
per a few clock cycles.
--
Andrew Haley (he/him)
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
https://keybase.io/andrewhaley
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671
On Thu, 26 Aug 2021 09:26:24 GMT, Wu Yan wrote:
>> src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 4871:
>>
>>> 4869: // exit from large loop when less than 64 bytes left to read or
>>> we're about
>>> 4870: // to prefetch memory behind array border
>>> 4871: int largeLoopExi
like that. I was (still am) tempted to approve
it, but Nick says there are still bugs in corner cases.
I think you should probably close it. Comparison of really long
Strings is so rare that I can't find any examples of where it
actually happens. Array comparisons, sure, but Strings, not so
m
On Wed, 28 Jul 2021 08:25:08 GMT, Nick Gasson wrote:
> I don't think we want to keep two copies of the compareTo intrinsic. If there
> are no cases where the LDP version is worse than the original version then we
> should just delete the old one and replace it with this.
I agree. The trouble i
On Mon, 12 Jul 2021 09:14:25 GMT, Wang Huang wrote:
>> Dear all,
>> Can you do me a favor to review this patch. This patch use `ldp` to
>> implement String.compareTo.
>>
>> * We add a JMH test case
>> * Here is the result of this test case
>>
>> Benchmark |(
On Mon, 12 Jul 2021 09:14:25 GMT, Wang Huang wrote:
>> Dear all,
>> Can you do me a favor to review this patch. This patch use `ldp` to
>> implement String.compareTo.
>>
>> * We add a JMH test case
>> * Here is the result of this test case
>>
>> Benchmark |(
On Thu, 8 Jul 2021 11:50:36 GMT, Wang Huang wrote:
> Dear all,
> Can you do me a favor to review this patch. This patch use `ldp` to
> implement String.compareTo.
>
> * We add a JMH test case
> * Here is the result of this test case
>
> Benchmark|(size)| M
On Thu, 8 Jul 2021 09:43:35 GMT, Andrew Haley wrote:
> Moves between GPRs and FPRs are often slow. There's a 10-cycle latency on
> some AArch64, so we avoid it whenever we can. Mind you, we don't care about
> this patch because we always generate FABS from an intrinsic any
On Thu, 8 Jul 2021 01:05:16 GMT, Brian Burkhalter wrote:
>> Please consider this change to make the `float` and `double` versions of
>> `java.lang.Math.abs()` branch-free.
>
> Brian Burkhalter has updated the pull request incrementally with one
> additional commit since the last revision:
>
>
On Fri, 2 Jul 2021 20:12:39 GMT, Ian Graves wrote:
> 8214761: Bug in parallel Kahan summation implementation
Crikey, how did we get that wrong?
It'd be nice if we had a regression test for this. Can you provide one, please?
-
PR: https://git.openjdk.java.net/jdk/pull/4674
On Fri, 2 Jul 2021 16:37:21 GMT, Brian Burkhalter wrote:
>> Please consider this proposal to add a method
>> `unsignedMultiplyHigh(long,long)` to each of `java.lang.Math` and
>> `java.lang.StrictMath`.
>
> Brian Burkhalter has refreshed the contents of this pull request, and
> previous commits
ub-nanosecond throughput.
--
Andrew Haley (he/him)
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
https://keybase.io/andrewhaley
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671
On 7/2/21 12:26 PM, Raffaello Giulietti wrote:
> ... or even as a one liner, like in the test
>
> return Math.multiplyHigh(x, y) + ((x >> (Long.SIZE - 1)) & y) + ((y >>
> (Long.SIZE - 1)) & x);
It was hard to write, so it should be hard to read too! :-)
On Fri, 2 Jul 2021 13:47:40 GMT, Andrew Haley wrote:
>> You can also do that branchlessly which might prove better
>>
>> long result = Math.multiplyHigh(x, y);
>> result += (y & (x >> 63));
>> result += (x & (y >> 63)
On Fri, 2 Jul 2021 11:06:06 GMT, Andrew Dinn wrote:
> You can also do that branchlessly which might prove better
>
> ```
> long result = Math.multiplyHigh(x, y);
> result += (y & (x >> 63));
> result += (x & (y >> 63));
> return result;
> ```
I doubt very much that it would b
On Fri, 2 Jul 2021 09:37:47 GMT, Andrew Haley wrote:
>> Brian Burkhalter has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> 8188044: Add @see links between multiplyHigh() and unsignedMultiplyHigh().
>
> sr
On Thu, 1 Jul 2021 18:08:22 GMT, Brian Burkhalter wrote:
>> Please consider this proposal to add a method
>> `unsignedMultiplyHigh(long,long)` to each of `java.lang.Math` and
>> `java.lang.StrictMath`.
>
> Brian Burkhalter has updated the pull request incrementally with one
> additional commit
Greg, what's your email address? Everything I try bounces.
--
Andrew Haley (he/him)
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
https://keybase.io/andrewhaley
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671
on benchmarks.
However, I do intend to fix this in a different way, if I can.
--
Andrew Haley (he/him)
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
https://keybase.io/andrewhaley
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671
from within the thread's Runnable. Was there a
> particular use case this was meant to address?
Structured Concurrency, but also possibly anywhere that inheritable
thread locals are used now.
--
Andrew Haley (he/him)
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.
permit more flexible control over what
gets inherited and when.
--
Andrew Haley (he/him)
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
https://keybase.io/andrewhaley
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671
On 5/15/21 6:15 PM, Remi Forax wrote:
> I think the JEP should be more explicit about the shortcoming of ThreadLocal
> and how the design of scope local fix both issues.
Yes. It's in progress.
--
Andrew Haley (he/him)
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.red
is proposed here, which does no more than bind values
to names over a scope. There needs to be more discussion in the JEP of
what this proposal isn't intended to do, and how we might cope with
mutability of a scope local's values.
--
Andrew Haley (he/him)
Java Platform Lead Engin
rit scope locals from the thread that was
running.
--
Andrew Haley (he/him)
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
https://keybase.io/andrewhaley
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671
On 5/15/21 10:10 AM, Alex Otenko wrote:
> ScopeLocal.where(...).run(...).finally(...) would be nice.
Is that different from try ... run ... finally ?
--
Andrew Haley (he/him)
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
https://keybase.io/andrewhaley
EAC8 43EB
ing else, that would require a more
heavyweight mechanism than scope locals, which need to be very lightweight
for some applications.
Over at Loom we've been talking about lifetimes and Ron has some ideas, but
scope locals are not likely to be that thing.
--
Andrew Haley (he/him)
Java Platf
object? Do I use Cleaner? Does the object need to implement
> finalize()... hopefully not?
All a scope local does is bind a value to a name, in a scope. This isn't
about C++-style destructors, which have their merits but are a different
subject.
--
Andrew Haley (he/him)
Java Platform L
ing that a scope local can do can also
be done by a TL, albeit with some clumsiness. I should be more explicit
about that.
--
Andrew Haley (he/him)
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
https://keybase.io/andrewhaley
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671
On 5/13/21 4:59 PM, Alan Snyder wrote:
>
>
>> On May 13, 2021, at 2:03 AM, Andrew Haley wrote:
>>
>> On 5/12/21 8:12 PM, Alan Snyder wrote:
>>> From the motivation section:
>>>
>>>> So you want to invoke a method |X| in a library that later
need to be passed
to callees, and in many cases it's better isolation if they don't get to
find out. The latter is especially true of passing security permissions.
Also, there is evolution of libraries: with scope locals you don't need
to change library interfaces to add useful capabi
/loom-dev/2021-April/002287.html
https://mail.openjdk.java.net/pipermail/loom-dev/2021-May/002427.html
--
Andrew Haley (he/him)
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
https://keybase.io/andrewhaley
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671
On Thu, 29 Apr 2021 20:24:25 GMT, Carlos O'Donell
wrote:
> Where does the requirement for monotonicity come from?
Semi-monotonicity, to be precise. In the spec of java.lang.Math,
"Besides accuracy at individual arguments, maintaining proper relations between
the method at different arguments
On Thu, 8 Apr 2021 17:24:38 GMT, Vladimir Kozlov wrote:
>> As part of [JEP 410](http://openjdk.java.net/jeps/410) remove code related
>> to Ahead-of-Time Compiler from JDK:
>>
>> - `jdk.aot` module — the `jaotc` tool
>> - `src/hotspot/share/aot` — loads AoT compiled code into VM for execution
On Thu, 8 Apr 2021 06:33:43 GMT, Dong Bo wrote:
>> In JDK-8248188, IntrinsicCandidate and API is added for Base64 decoding.
>> Base64 decoding can be improved on aarch64 with ld4/tbl/tbx/st3, a basic
>> idea can be found at
>> http://0x80.pl/articles/base64-simd-neon.html#encoding-quadwords.
>>
On Wed, 7 Apr 2021 05:51:02 GMT, Dong Bo wrote:
>> In JDK-8248188, IntrinsicCandidate and API is added for Base64 decoding.
>> Base64 decoding can be improved on aarch64 with ld4/tbl/tbx/st3, a basic
>> idea can be found at
>> http://0x80.pl/articles/base64-simd-neon.html#encoding-quadwords.
>>
On Wed, 7 Apr 2021 09:50:45 GMT, Andrew Haley wrote:
>> Dong Bo has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> fix misleading annotations
>
> src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 582
On Tue, 6 Apr 2021 07:25:57 GMT, Dong Bo wrote:
>> In JDK-8248188, IntrinsicCandidate and API is added for Base64 decoding.
>> Base64 decoding can be improved on aarch64 with ld4/tbl/tbx/st3, a basic
>> idea can be found at
>> http://0x80.pl/articles/base64-simd-neon.html#encoding-quadwords.
>>
On Fri, 2 Apr 2021 10:01:27 GMT, Andrew Haley wrote:
>> Dong Bo has updated the pull request with a new target base due to a merge
>> or a rebase. The pull request now contains six commits:
>>
>> - Merge branch 'master' into aarch64.base64.decode
&
On Sat, 27 Mar 2021 08:58:03 GMT, Dong Bo wrote:
> There can be illegal characters at the start of the input if the data is MIME
> encoded.
> It would be no benefits to use SIMD for this case, so the stub use no-simd
> instructions for MIME encoded data now.
What is the reasoning here? Sure, t
On 4/5/21 9:08 AM, Alan Bateman wrote:
> On 04/04/2021 09:53, Andrew Haley wrote:
>> :
>> We also have a candidate for a String -> toDouble parser from Raffaello
>> Giulietti:
>>
>> https://mail.openjdk.java.net/pipermail/core-libs-dev/2018-March/052355.ht
On 4/4/21 9:53 AM, Andrew Haley wrote:
> On 4/3/21 12:58 PM, Carfield Yim wrote:
>> HI all, just aware of this project,
>> https://github.com/wrandelshofer/FastDoubleParser, not sure if it good idea
>> to use this as default Double Parser in JVM?
>
> We also ha
etti:
https://mail.openjdk.java.net/pipermail/core-libs-dev/2018-March/052355.html
As far as I can see there's nothing wrong with it, but it got stuck in
review. This was a bad failure of our review processes, I'm afraid. I
wonder if we will do any better with this one.
--
Andrew Haley
On Fri, 2 Apr 2021 03:10:57 GMT, Dong Bo wrote:
>> In JDK-8248188, IntrinsicCandidate and API is added for Base64 decoding.
>> Base64 decoding can be improved on aarch64 with ld4/tbl/tbx/st3, a basic
>> idea can be found at
>> http://0x80.pl/articles/base64-simd-neon.html#encoding-quadwords.
>>
On Fri, 2 Apr 2021 07:05:26 GMT, Dong Bo wrote:
> PING... Any suggestions on the updated commit?
Once you reply to the comments, sure.
-
PR: https://git.openjdk.java.net/jdk/pull/3228
On Fri, 2 Apr 2021 03:10:57 GMT, Dong Bo wrote:
>> In JDK-8248188, IntrinsicCandidate and API is added for Base64 decoding.
>> Base64 decoding can be improved on aarch64 with ld4/tbl/tbx/st3, a basic
>> idea can be found at
>> http://0x80.pl/articles/base64-simd-neon.html#encoding-quadwords.
>>
On Mon, 29 Mar 2021 03:28:54 GMT, Dong Bo wrote:
> > Please consider losing the non-SIMD case. It doesn't result in any
> > significant gain.
>
> The non-SIMD case is useful for MIME decoding performance.
Your test results suggest that it isn't useful for that, surely?
-
PR: http
On Fri, 2 Apr 2021 03:10:57 GMT, Dong Bo wrote:
>> In JDK-8248188, IntrinsicCandidate and API is added for Base64 decoding.
>> Base64 decoding can be improved on aarch64 with ld4/tbl/tbx/st3, a basic
>> idea can be found at
>> http://0x80.pl/articles/base64-simd-neon.html#encoding-quadwords.
>>
On Mon, 29 Mar 2021 03:28:54 GMT, Dong Bo wrote:
> I think I can rewrite this part as loops.
> With an intial implemention, we can have almost half of the code size reduced
> (1312B -> 748B). Sounds OK to you?
Sounds great, but I'm still somewhat concerned that the non-SIMD case only
offers 3-
On Mon, 29 Mar 2021 03:15:57 GMT, Nick Gasson wrote:
> > There's a lot of unrolling, particularly in the non-SIMD case. Please
> > consider taking out some of the unrolling; I suspect it'd not increase time
> > by very much but would greatly reduce the code cache pollution. It's very
> > tempt
On Sat, 27 Mar 2021 09:53:37 GMT, Andrew Haley wrote:
>> In JDK-8248188, IntrinsicCandidate and API is added for Base64 decoding.
>> Base64 decoding can be improved on aarch64 with ld4/tbl/tbx/st3, a basic
>> idea can be found at
>> http://0x80.pl/articles/base64
On Sat, 27 Mar 2021 08:58:03 GMT, Dong Bo wrote:
> In JDK-8248188, IntrinsicCandidate and API is added for Base64 decoding.
> Base64 decoding can be improved on aarch64 with ld4/tbl/tbx/st3, a basic idea
> can be found at
> http://0x80.pl/articles/base64-simd-neon.html#encoding-quadwords.
>
>
On Sat, 27 Mar 2021 08:58:03 GMT, Dong Bo wrote:
> In JDK-8248188, IntrinsicCandidate and API is added for Base64 decoding.
> Base64 decoding can be improved on aarch64 with ld4/tbl/tbx/st3, a basic idea
> can be found at
> http://0x80.pl/articles/base64-simd-neon.html#encoding-quadwords.
>
>
On Tue, 23 Mar 2021 16:20:47 GMT, Ludovic Henry wrote:
>> Anton Kozlov has updated the pull request with a new target base due to a
>> merge or a rebase. The pull request now contains 115 commits:
>>
>> - Merge branch 'master' into jdk-macos
>> - JDK-8262491: bsd_aarch64 part
>> - JDK-826300
On Tue, 23 Mar 2021 13:54:24 GMT, Andrew Haley wrote:
>> Anton Kozlov has updated the pull request with a new target base due to a
>> merge or a rebase. The pull request now contains 115 commits:
>>
>> - Merge branch 'master' into jdk-macos
>> -
On Mon, 22 Mar 2021 12:50:14 GMT, Anton Kozlov wrote:
>> Please review the implementation of JEP 391: macOS/AArch64 Port.
>>
>> It's heavily based on existing ports to linux/aarch64, macos/x86_64, and
>> windows/aarch64.
>>
>> Major changes are in:
>> * src/hotspot/cpu/aarch64: support of the
1 - 100 of 560 matches
Mail list logo
