Re: [math] working on increasing performance for Math3

2021-05-10 Thread Brett Okken
The explicit cast to primitive does not result in boxing/unboxing. It is the "magic" of PolymorphicSignature which actually adjusts to allow for primitives. On Mon, May 10, 2021 at 11:08 AM Erik Svensson wrote: > > > On 2021-05-10, 18:03, "Brett Okken" wrote: > > WARNING - External email;

Re: [math] working on increasing performance for Math3

2021-05-10 Thread Erik Svensson
On 2021-05-10, 18:03, "Brett Okken" wrote: WARNING - External email; exercise caution. Perhaps it is an Intellij issue. The MethodHandle javadoc[1] has an "Usage examples" section. One of the examples shows calling List.size() (which returns an int): > Object x, y; String

Re: [math] working on increasing performance for Math3

2021-05-10 Thread Brett Okken
Perhaps it is an Intellij issue. The MethodHandle javadoc[1] has an "Usage examples" section. One of the examples shows calling List.size() (which returns an int): > Object x, y; String s; int i; > MethodType mt; MethodHandle mh; > MethodHandles.Lookup lookup = MethodHandles.lookup(); > ... > mt

Re: [math] working on increasing performance for Math3

2021-05-10 Thread Erik Svensson
On 2021-05-10, 17:14, "Brett Okken" wrote: WARNING - External email; exercise caution. > Secondly, MethodHandle.invokeExact() takes and returns an object so there's a boxing/unboxing involved as well (as the Math/FastMath methods returns primitives). There is "magic" going on

Re: [math] working on increasing performance for Math3

2021-05-10 Thread Brett Okken
> Secondly, MethodHandle.invokeExact() takes and returns an object so there's a > boxing/unboxing involved as well (as the Math/FastMath methods returns > primitives). There is "magic" going on here that actually avoids boxing. You can/should cast directly to the primitive type. That is what

Re: [math] working on increasing performance for Math3

2021-05-10 Thread Erik Svensson
On 2021-05-10, 13:52, "Brett Okken" wrote: WARNING - External email; exercise caution. Out of curiosity, what specifically about MethodHandles use consumed the time? Was it the discovery/initialization or the steady-state usage? My observation has been that if the MH itself is

Re: [lang] Failing test on Java 16-EA.

2021-05-10 Thread Jaikiran Pai
This issue should be fixed in the recently released JDK 17 EA 21 build https://www.mail-archive.com/dev@commons.apache.org/msg70950.html -Jaikiran On 2021/04/13 12:04:21, Jaikiran Pai wrote: > Hello Gary, > > I had a look at this one and I was able to reproduce this. Based on my > reading

Re: [math] working on increasing performance for Math3

2021-05-10 Thread Brett Okken
Out of curiosity, what specifically about MethodHandles use consumed the time? Was it the discovery/initialization or the steady-state usage? My observation has been that if the MH itself is static final and invokeExact is used, performance at steady-state is identical to making the call

Re: [math] working on increasing performance for Math3

2021-05-10 Thread Erik Svensson
Hello all! Some background: I work at a relatively well known fintech company and work with our clearing/risk products. They do a lot of calculations and performance is quite important to us. We have several libs that do the same thing and I was looking into a merger. So I wrote some JMH tests

JDK 17 Early Access build 21 is available

2021-05-10 Thread Rory O'Donnell
Hi Benedikt, ** *OpenJDK 17 Early Access build 21 is now available at **https://jdk.java.net/17* * These early-access , open-source builds are provided under the o GNU General Public License, version 2, with the Classpath Exception