Re: [math] working on increasing performance for Math3

2021-05-21 Thread Gilles Sadowski 
Ping.

I've created a "neuralnet" module (for the ANN/SOFM functionality), in the
"modularized_master" branch, that can be used as a template for the feature
discussed in this thread.  Are you still interested in implementing it?
If so, I'd suggest
  commons-math-jdkmath
for the name.
It should be a "core" module (independend of the "legacy" module).

Regards,
Gilles

Le sam. 15 mai 2021 à 18:38, Gilles Sadowski  a écrit :
>
> Le mer. 12 mai 2021 à 13:23, Erik Svensson  a écrit 
> :
> >
> > Howdy all,
> >
> > Irrespective of how it's implemented we would like to implement the 
> > performance improvements possible to the commons-math lib.
> > While I can certainly fork the project and we could have our own version of 
> > commons-math, we would like to contribute.
>
> Please use the newly-created branch.[1]
> [Thus: You should try and take all the necessary the code/package
> out of the "legacy" module and create new module that would provide
> the functionality which you want to achieve.]
>
> Please file a JIRA report with the proposal (e.g. as a "sub-task" of the
> MATH-1575 report.[2]
>
> Thanks,
> Gilles
>
> [1] 
> https://gitbox.apache.org/repos/asf?p=commons-math.git;a=shortlog;h=refs/heads/modularized_master
> [2] https://issues.apache.org/jira/browse/MATH-1575
>
> > [...]

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [math] working on increasing performance for Math3

2021-05-15 Thread Gilles Sadowski 
Le mer. 12 mai 2021 à 13:23, Erik Svensson  a écrit :
>
> Howdy all,
>
> Irrespective of how it's implemented we would like to implement the 
> performance improvements possible to the commons-math lib.
> While I can certainly fork the project and we could have our own version of 
> commons-math, we would like to contribute.

Please use the newly-created branch.[1]
[Thus: You should try and take all the necessary the code/package
out of the "legacy" module and create new module that would provide
the functionality which you want to achieve.]

Please file a JIRA report with the proposal (e.g. as a "sub-task" of the
MATH-1575 report.[2]

Thanks,
Gilles

[1] 
https://gitbox.apache.org/repos/asf?p=commons-math.git;a=shortlog;h=refs/heads/modularized_master
[2] https://issues.apache.org/jira/browse/MATH-1575

> [...]

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [math] working on increasing performance for Math3

2021-05-12 Thread Gilles Sadowski 
Hi.

Le mer. 12 mai 2021 à 13:23, Erik Svensson  a écrit :
>
> Howdy all,
>
> Irrespective of how it's implemented we would like to implement the 
> performance improvements possible to the commons-math lib.
> While I can certainly fork the project and we could have our own version of 
> commons-math, we would like to contribute.

Thanks.

> If there is no or little interest in a more performant commons-math (one that 
> uses jlM where appropriate), then I will fork and maybe submit patches.
> If there is interest, then I would like to have suggestions on the how and 
> what.

I mentioned some, although I do not know which are realistic or simply useful.

> How would you like it to work, what would you like see.
> Should you be able to choose between jlM or FastMath, for instance.

At first sight, I'd think so.

>
> Ps
> I asked about bytebuddy because of point 5 on the 
> https://commons.apache.org/proper/commons-math/

As of the current development version of Commons Math[1], the JDK
dependency has been upgraded to at least Java 8.

The features (whatever they may be) could also be available, or not,
depending on the JVM being used.

Regards,
Gilles

[1] 
https://gitbox.apache.org/repos/asf?p=commons-math.git;a=tree;h=refs/heads/master;hb=refs/heads/master

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [math] working on increasing performance for Math3

2021-05-12 Thread Erik Svensson 
Howdy all,

Irrespective of how it's implemented we would like to implement the performance 
improvements possible to the commons-math lib.
While I can certainly fork the project and we could have our own version of 
commons-math, we would like to contribute.
If there is no or little interest in a more performant commons-math (one that 
uses jlM where appropriate), then I will fork and maybe submit patches.
If there is interest, then I would like to have suggestions on the how and 
what. How would you like it to work, what would you like see.
Should you be able to choose between jlM or FastMath, for instance.

Ps
I asked about bytebuddy because of point 5 on the 
https://commons.apache.org/proper/commons-math/

Erik Svensson
Principal Architect
Strategic Programs, Platform & Product Engineering
 
Desk
Mobile
Email
Address  
+ 46 8 405 66 39
+ 46 73 449 66 39
erik.svens...@nasdaq.com
Tullvaktsvägen 15, Stockholm
 
 
 
 
 
rewritetomorrow.com 
 


***
CONFIDENTIALITY AND PRIVACY NOTICE: This e-mail and any attachments are for the 
exclusive and confidential use of the intended recipient and may constitute 
non-public information.  Personal data in this email is governed by our Privacy 
Policy at  https://www.nasdaq.com/privacy-statement  unless explicitly excluded 
from it; please see the section in the policy entitled “Situations Where This 
Privacy Policy Does Not Apply” for circumstances where different privacy terms 
govern emailed personal data.  If you received this e-mail in error, 
disclosing, copying, distributing or taking any action in reliance of this 
e-mail is strictly prohibited and may be unlawful. Instead, please notify us 
immediately by return e-mail and promptly delete this message and its 
attachments from your computer system. We do not waive any work product or 
other applicable legal privilege(s) by the transmission of this message.
***

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

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; 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 s; int i;
> > MethodType mt; MethodHandle mh;
> > MethodHandles.Lookup lookup = MethodHandles.lookup();
> > ...
> > mt = MethodType.methodType(int.class);
> > mh = lookup.findVirtual(java.util.List.class, "size", mt);
> > i = (int) mh.invokeExact(java.util.Arrays.asList(1,2,3));
> > // invokeExact(Ljava/util/List;)I
> > assert(i == 3);
>
> There is no boxing/unboxing going on here.
>
> But there is an explicit cast, I thought that was the unboxing?
>
> [1] - 
> https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/lang/invoke/MethodHandle.html
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>
> ***
> CONFIDENTIALITY AND PRIVACY NOTICE: This e-mail and any attachments are for 
> the exclusive and confidential use of the intended recipient and may 
> constitute non-public information.  Personal data in this email is governed 
> by our Privacy Policy at  https://www.nasdaq.com/privacy-statement  unless 
> explicitly excluded from it; please see the section in the policy entitled 
> “Situations Where This Privacy Policy Does Not Apply” for circumstances where 
> different privacy terms govern emailed personal data.  If you received this 
> e-mail in error, disclosing, copying, distributing or taking any action in 
> reliance of this e-mail is strictly prohibited and may be unlawful. Instead, 
> please notify us immediately by return e-mail and promptly delete this 
> message and its attachments from your computer system. We do not waive any 
> work product or other applicable legal privilege(s) by the transmission of 
> this message.
> ***
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

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 s; int i;
> MethodType mt; MethodHandle mh;
> MethodHandles.Lookup lookup = MethodHandles.lookup();
> ...
> mt = MethodType.methodType(int.class);
> mh = lookup.findVirtual(java.util.List.class, "size", mt);
> i = (int) mh.invokeExact(java.util.Arrays.asList(1,2,3));
> // invokeExact(Ljava/util/List;)I
> assert(i == 3);

There is no boxing/unboxing going on here.

But there is an explicit cast, I thought that was the unboxing?

[1] - 
https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/lang/invoke/MethodHandle.html

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org


***
CONFIDENTIALITY AND PRIVACY NOTICE: This e-mail and any attachments are for the 
exclusive and confidential use of the intended recipient and may constitute 
non-public information.  Personal data in this email is governed by our Privacy 
Policy at  https://www.nasdaq.com/privacy-statement  unless explicitly excluded 
from it; please see the section in the policy entitled “Situations Where This 
Privacy Policy Does Not Apply” for circumstances where different privacy terms 
govern emailed personal data.  If you received this e-mail in error, 
disclosing, copying, distributing or taking any action in reliance of this 
e-mail is strictly prohibited and may be unlawful. Instead, please notify us 
immediately by return e-mail and promptly delete this message and its 
attachments from your computer system. We do not waive any work product or 
other applicable legal privilege(s) by the transmission of this message.
***

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

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 = MethodType.methodType(int.class);
> mh = lookup.findVirtual(java.util.List.class, "size", mt);
> i = (int) mh.invokeExact(java.util.Arrays.asList(1,2,3));
> // invokeExact(Ljava/util/List;)I
> assert(i == 3);

There is no boxing/unboxing going on here.

[1] - 
https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/lang/invoke/MethodHandle.html

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

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 here that actually avoids boxing. You
can/should cast directly to the primitive type. That is what the
PolymorphicSignature annotation means.

@HotSpotIntrinsicCandidate
public final native @PolymorphicSignature Object
invokeExact(Object... args) throws Throwable;

While I don't do an explicit boxing on calling, there's an explicit unboxing on 
the return. The compiler barfs if it's not there or maybe it's just Intellij?

/Erik
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org


***
CONFIDENTIALITY AND PRIVACY NOTICE: This e-mail and any attachments are for the 
exclusive and confidential use of the intended recipient and may constitute 
non-public information.  Personal data in this email is governed by our Privacy 
Policy at  https://www.nasdaq.com/privacy-statement  unless explicitly excluded 
from it; please see the section in the policy entitled “Situations Where This 
Privacy Policy Does Not Apply” for circumstances where different privacy terms 
govern emailed personal data.  If you received this e-mail in error, 
disclosing, copying, distributing or taking any action in reliance of this 
e-mail is strictly prohibited and may be unlawful. Instead, please notify us 
immediately by return e-mail and promptly delete this message and its 
attachments from your computer system. We do not waive any work product or 
other applicable legal privilege(s) by the transmission of this message.
***

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 the
PolymorphicSignature annotation means.

@HotSpotIntrinsicCandidate
public final native @PolymorphicSignature Object
invokeExact(Object... args) throws Throwable;

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

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 static final and
invokeExact is used, performance at steady-state is identical to making the
call explicitly from code. Deviating from either of those conditions can
lead to meaningful performance degradation. Aleksey Shipilev touches on why
each are important to what the compiler can do at runtime in a couple of
his blogs/presentations.

My MethodHandle declaration wasn't final, I'll test that.
Secondly, MethodHandle.invokeExact() takes and returns an object so there's a 
boxing/unboxing involved as well (as the Math/FastMath methods returns 
primitives).

(Now I see my test node has gone the way of all flesh. I'll get back to you on 
the test on final)
Cheers
Erik


On Mon, May 10, 2021 at 3:41 AM Erik Svensson 
wrote:

> 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 and found that lib A was faster on JDK 8
> and below and lib B was faster on jdk 9 and above.
> (Note: only for certain calls!)
> Looking further into this I determined the cause to be due to Lib A using
> FastMath and Lib B using java.lang.Math. In jdk9 some jlM methods were
> moved from native to being annotated with HotspotIntrinsicCandidate (from
> jdk16, just IntrinsicCandidate) and they significantly outperformed the
> corresponding FastMath methods.
> Since the Math distributions uses FastMath , my first thought was to do
> what would essentially be a static replace depending on java version, 
where
> the FastMath method would call the jlM method if It was an annotated one.
> However, this would not be so flexible given that IntrinsicCandidates 
could
> come and go.
> So I created a scanner that scanned for the annotation and replaced the
> FastMath call where appropriate. It used MethodHandles and that consumed
> most, if not all and more, of the performance gain.
> That was when I hit up on the idea of using ByteBuddy to create a proxy
> class.
> I asked if it was permissible since some OSS projects do not like to use
> 3rd party code in their own code base.
>
> So, what I would like to do is to still get the performance gain from jlM
> but use FastMath where it is actually faster and also get the 
distributions
> to use the more performant math methods.
> A sort of pick and choose.
> I think it would be of interest to be able to choose a performant math
> provider rather than the exact.
>
> Erik Svensson
> Principal Architect
> Strategic Programs, Platform & Product Engineering
>  
> Desk
> Mobile
> Email
> Address
> + 46 8 405 66 39
> + 46 73 449 66 39
> erik.svens...@nasdaq.com
> Tullvaktsvägen 15, Stockholm
> 

>  
>  
>  
>  
>  
> rewritetomorrow.com 
>
>
> On 2021-05-08, 08:42, "Benjamin Marwell"  wrote:
>
> WARNING - External email; exercise caution.
>
> Instead of using byte buddy, why not just maven multi release jars? *1
>
> The Java9+ impl will go to META-INF/java9 or so. We did that in the
> maven-jlink-plugin for example. *2
> Will be much faster and work on Java 16+. Much easier to rest.
> Drawback: bad IDE support
>
> 1:
> https://maven.apache.org/plugins/maven-compiler-plugin/multirelease.html
>
> 2:
>
> 
https://github.com/apache/maven-jlink-plugin/commit/f8bdf5050c266854524aaa51eb36109c00ca692a
>
> HTH
> Ben
>
>
> On Fri, 7 May 2021, 10:52 Erik Svensson, 
> wrote:
>
> > Howdy all!
> >
> >
> >
> > I’m looking to do some work on FastMath to increase performance by
> using
> > java.lang.Math where it is applicable (ie where there is an
> > @HotspotIntrinsicCandidate annotation on the method).
> >
> > Since HIC was introduced in java 9 and the code needs to work on
> pre-java
> > 9 and I don’t want to compromise performance (since performance is
> the
> > whole reason I’m doing

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 explicitly from code. Deviating from either of those conditions can
lead to meaningful performance degradation. Aleksey Shipilev touches on why
each are important to what the compiler can do at runtime in a couple of
his blogs/presentations.

Brett

On Mon, May 10, 2021 at 3:41 AM Erik Svensson 
wrote:

> 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 and found that lib A was faster on JDK 8
> and below and lib B was faster on jdk 9 and above.
> (Note: only for certain calls!)
> Looking further into this I determined the cause to be due to Lib A using
> FastMath and Lib B using java.lang.Math. In jdk9 some jlM methods were
> moved from native to being annotated with HotspotIntrinsicCandidate (from
> jdk16, just IntrinsicCandidate) and they significantly outperformed the
> corresponding FastMath methods.
> Since the Math distributions uses FastMath , my first thought was to do
> what would essentially be a static replace depending on java version, where
> the FastMath method would call the jlM method if It was an annotated one.
> However, this would not be so flexible given that IntrinsicCandidates could
> come and go.
> So I created a scanner that scanned for the annotation and replaced the
> FastMath call where appropriate. It used MethodHandles and that consumed
> most, if not all and more, of the performance gain.
> That was when I hit up on the idea of using ByteBuddy to create a proxy
> class.
> I asked if it was permissible since some OSS projects do not like to use
> 3rd party code in their own code base.
>
> So, what I would like to do is to still get the performance gain from jlM
> but use FastMath where it is actually faster and also get the distributions
> to use the more performant math methods.
> A sort of pick and choose.
> I think it would be of interest to be able to choose a performant math
> provider rather than the exact.
>
> Erik Svensson
> Principal Architect
> Strategic Programs, Platform & Product Engineering
>  
> Desk
> Mobile
> Email
> Address
> + 46 8 405 66 39
> + 46 73 449 66 39
> erik.svens...@nasdaq.com
> Tullvaktsvägen 15, Stockholm
> 
>  
>  
>  
>  
>  
> rewritetomorrow.com 
>
>
> On 2021-05-08, 08:42, "Benjamin Marwell"  wrote:
>
> WARNING - External email; exercise caution.
>
> Instead of using byte buddy, why not just maven multi release jars? *1
>
> The Java9+ impl will go to META-INF/java9 or so. We did that in the
> maven-jlink-plugin for example. *2
> Will be much faster and work on Java 16+. Much easier to rest.
> Drawback: bad IDE support
>
> 1:
> https://maven.apache.org/plugins/maven-compiler-plugin/multirelease.html
>
> 2:
>
> https://github.com/apache/maven-jlink-plugin/commit/f8bdf5050c266854524aaa51eb36109c00ca692a
>
> HTH
> Ben
>
>
> On Fri, 7 May 2021, 10:52 Erik Svensson, 
> wrote:
>
> > Howdy all!
> >
> >
> >
> > I’m looking to do some work on FastMath to increase performance by
> using
> > java.lang.Math where it is applicable (ie where there is an
> > @HotspotIntrinsicCandidate annotation on the method).
> >
> > Since HIC was introduced in java 9 and the code needs to work on
> pre-java
> > 9 and I don’t want to compromise performance (since performance is
> the
> > whole reason I’m doing this) I’m thinking about using ByteBuddy to
> > construct a proxy class but I’m unsure whether that is allowed in
> Apache
> > Commons.
> >
> > Btw, I’ve tested using MethodHandles but that consumed almost all the
> > performance improvement java.lang.Math had over FastMath (for sin
> anyway).
> >
> >
> >
> > Cheers
> >
> >
> >
> > *Erik Svensson*
> >
> > Principal Architect
> > Strategic Programs, Platform & Product Engineering
> >
> > [image: Nasdaq, Inc.] 
> >
> > *Desk*
> > *Mobile*
> > *Email*
> > *Address  *
> >
> > + 46 8 405 66 39
> > + 46 73 449 66 39
> > erik.svens...@nasdaq.com
> > Tullvaktsvägen 15, Stockholm
> >
> > [image: signature_170089658]

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 and found that lib A was faster on JDK 8 and below and 
lib B was faster on jdk 9 and above.
(Note: only for certain calls!)
Looking further into this I determined the cause to be due to Lib A using 
FastMath and Lib B using java.lang.Math. In jdk9 some jlM methods were moved 
from native to being annotated with HotspotIntrinsicCandidate (from jdk16, just 
IntrinsicCandidate) and they significantly outperformed the corresponding 
FastMath methods. 
Since the Math distributions uses FastMath , my first thought was to do what 
would essentially be a static replace depending on java version, where the 
FastMath method would call the jlM method if It was an annotated one. However, 
this would not be so flexible given that IntrinsicCandidates could come and go. 
So I created a scanner that scanned for the annotation and replaced the 
FastMath call where appropriate. It used MethodHandles and that consumed most, 
if not all and more, of the performance gain.
That was when I hit up on the idea of using ByteBuddy to create a proxy class. 
I asked if it was permissible since some OSS projects do not like to use 3rd 
party code in their own code base. 

So, what I would like to do is to still get the performance gain from jlM but 
use FastMath where it is actually faster and also get the distributions to use 
the more performant math methods.
A sort of pick and choose.
I think it would be of interest to be able to choose a performant math provider 
rather than the exact. 

Erik Svensson
Principal Architect
Strategic Programs, Platform & Product Engineering
 
Desk
Mobile
Email
Address  
+ 46 8 405 66 39
+ 46 73 449 66 39
erik.svens...@nasdaq.com
Tullvaktsvägen 15, Stockholm
 
 
 
 
 
rewritetomorrow.com 
 

On 2021-05-08, 08:42, "Benjamin Marwell"  wrote:

WARNING - External email; exercise caution.

Instead of using byte buddy, why not just maven multi release jars? *1

The Java9+ impl will go to META-INF/java9 or so. We did that in the
maven-jlink-plugin for example. *2
Will be much faster and work on Java 16+. Much easier to rest.
Drawback: bad IDE support

1: https://maven.apache.org/plugins/maven-compiler-plugin/multirelease.html

2:

https://github.com/apache/maven-jlink-plugin/commit/f8bdf5050c266854524aaa51eb36109c00ca692a

HTH
Ben


On Fri, 7 May 2021, 10:52 Erik Svensson,  wrote:

> Howdy all!
>
>
>
> I’m looking to do some work on FastMath to increase performance by using
> java.lang.Math where it is applicable (ie where there is an
> @HotspotIntrinsicCandidate annotation on the method).
>
> Since HIC was introduced in java 9 and the code needs to work on pre-java
> 9 and I don’t want to compromise performance (since performance is the
> whole reason I’m doing this) I’m thinking about using ByteBuddy to
> construct a proxy class but I’m unsure whether that is allowed in Apache
> Commons.
>
> Btw, I’ve tested using MethodHandles but that consumed almost all the
> performance improvement java.lang.Math had over FastMath (for sin anyway).
>
>
>
> Cheers
>
>
>
> *Erik Svensson*
>
> Principal Architect
> Strategic Programs, Platform & Product Engineering
>
> [image: Nasdaq, Inc.] 
>
> *Desk*
> *Mobile*
> *Email*
> *Address  *
>
> + 46 8 405 66 39
> + 46 73 449 66 39
> erik.svens...@nasdaq.com
> Tullvaktsvägen 15, Stockholm
>
> [image: signature_170089658] 
>
> [image: signature_1919909931] 
>
> [image: signature_1754902186] 
>
> [image: signature_1778387217] 
>
> [image: signature_1326178797] 
>
> rewritetomorrow.com
>
>
>
>  ***
> CONFIDENTIALITY AND PRIVACY NOTICE: This e-mail and any attachments are
> for the exclusive and confidential use of the intended recipient and may
> constitute non-public information.  Personal data in this email is 
governed
> by our Privacy Policy at  https://www.nasdaq.com/privacy-statement
> unless explicitly excluded from it; please see the section in the policy
> entitled “Situations Where This Privacy Policy Does Not Apply” for
> circumst

Re: [math] working on increasing performance for Math3

2021-05-09 Thread Ralph Goers 


> On May 8, 2021, at 5:14 AM, Gilles Sadowski  wrote:
> 
> Hello.
> 
> Le sam. 8 mai 2021 à 08:42, Benjamin Marwell  > a écrit :
>> 
>> Instead of using byte buddy, why not just maven multi release jars? *1
> 
> Thanks for the suggestion.
> Again, I don't know how to do it concretely[1] nor the implications
> (IIRC, the mention of multi-release JARs was frowned upon some
> time ago).

Log4j 2 2.x has used multi-release jars for a few years. All the real issues 
have long been solved.
The remaining complications probably won’t be an issue for Commons. The main 
issue is that
some classes and/or methods were eliminated in Java 9 with new replacements 
added. This was 
a poor decision by the OpenJDK team/Oracle as it means that if you want to 
support both 
Java 8 and 11 and you use classes only available in Java 8 that you must have 
multiple compile 
steps in the build of your module and use toolchains to control which JDK gets 
used. If you don’t 
have dependencies on classes or methods that are no longer available then using 
the Java 11 
compiler should work fine.

> 
>> The Java9+ impl will go to META-INF/java9 or so. We did that in the
>> maven-jlink-plugin for example. *2
>> Will be much faster and work on Java 16+. Much easier to rest.
> 
> All good points, I guess.
> 
> However, what about the potential of having a user-selectable
> version of the implementations of the functions contained in
> the JDK's "Math" class?

Why? You should know how the JDK is going to behave. You can create classes 
that wrap JDK 
stuff where Java’s Math works well and have the wrapper call something else 
when it does not. 
You don’t need any logic to do that. You just provide a wrapper at the 
appropriate release levels 
and Java will take care of loading the correct one.

Ralph

Re: [math] working on increasing performance for Math3

2021-05-08 Thread Gilles Sadowski 
>> [...]
>
> It might make sense to update the FastMath Javadoc to clarify that the
> main focus of the class is now accuracy (and portability?) rather than
> speed.

Done.

> This should help manage user expectations.

Yet the idea that though some API (TBD), an application could select
which implementation to use seems useful.
The "legacy" class (still to be called "FastMath"?) would be untouched
(and the reference for any function where the priority is accuracy over
speed).

> > > [...]

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [math] working on increasing performance for Math3

2021-05-08 Thread sebb 
On Sat, 8 May 2021 at 13:14, Gilles Sadowski  wrote:
>
> Hello.
>
> Le sam. 8 mai 2021 à 08:42, Benjamin Marwell  a écrit :
> >
> > Instead of using byte buddy, why not just maven multi release jars? *1
>
> Thanks for the suggestion.
> Again, I don't know how to do it concretely[1] nor the implications
> (IIRC, the mention of multi-release JARs was frowned upon some
> time ago).
>
> > The Java9+ impl will go to META-INF/java9 or so. We did that in the
> > maven-jlink-plugin for example. *2
> > Will be much faster and work on Java 16+. Much easier to rest.
>
> All good points, I guess.
>
> However, what about the potential of having a user-selectable
> version of the implementations of the functions contained in
> the JDK's "Math" class?
>
> Unless one can provide a reference that, from Java 9 on, the
> accuracy cannot be improved upon what the JDK computes,
> the point remains that "FastMath" is more accurate, so that we
> cannot assume that a transparent call to "java.util.Math" won't
> have side-effects.

It might make sense to update the FastMath Javadoc to clarify that the
main focus of the class is now accuracy (and portability?) rather than
speed. This should help manage user expectations.

> > Drawback: bad IDE support
>
> Personally I don't care. ;-)
>
> Regards,
> Gilles
>
> [1] If you'd like to propose a patch/PR, I could set up a dedicated branch.
>
> >
> > 1: https://maven.apache.org/plugins/maven-compiler-plugin/multirelease.html
> >
> > 2:
> > https://github.com/apache/maven-jlink-plugin/commit/f8bdf5050c266854524aaa51eb36109c00ca692a
> >
> > HTH
> > Ben
> >
> >
> > On Fri, 7 May 2021, 10:52 Erik Svensson,  wrote:
> >
> > > Howdy all!
> > >
> > >
> > >
> > > I’m looking to do some work on FastMath to increase performance by using
> > > java.lang.Math where it is applicable (ie where there is an
> > > @HotspotIntrinsicCandidate annotation on the method).
> > >
> > > Since HIC was introduced in java 9 and the code needs to work on pre-java
> > > 9 and I don’t want to compromise performance (since performance is the
> > > whole reason I’m doing this) I’m thinking about using ByteBuddy to
> > > construct a proxy class but I’m unsure whether that is allowed in Apache
> > > Commons.
> > >
> > > Btw, I’ve tested using MethodHandles but that consumed almost all the
> > > performance improvement java.lang.Math had over FastMath (for sin anyway).
> > >
> > >
> > >
> > > Cheers
> > >
> > >
> > >
> > > *Erik Svensson*
> > >
> > > Principal Architect
> > > Strategic Programs, Platform & Product Engineering
> > >
> > > [image: Nasdaq, Inc.] 
> > >
> > > *Desk*
> > > *Mobile*
> > > *Email*
> > > *Address  *
> > >
> > > + 46 8 405 66 39
> > > + 46 73 449 66 39
> > > erik.svens...@nasdaq.com
> > > Tullvaktsvägen 15, Stockholm
> > >
> > > [image: signature_170089658] 
> > >
> > > [image: signature_1919909931] 
> > >
> > > [image: signature_1754902186] 
> > >
> > > [image: signature_1778387217] 
> > >
> > > [image: signature_1326178797] 
> > >
> > > rewritetomorrow.com
> > >
> > >
> > >
> > >  ***
> > > CONFIDENTIALITY AND PRIVACY NOTICE: This e-mail and any attachments are
> > > for the exclusive and confidential use of the intended recipient and may
> > > constitute non-public information.  Personal data in this email is 
> > > governed
> > > by our Privacy Policy at  https://www.nasdaq.com/privacy-statement
> > > unless explicitly excluded from it; please see the section in the policy
> > > entitled “Situations Where This Privacy Policy Does Not Apply” for
> > > circumstances where different privacy terms govern emailed personal data.
> > > If you received this e-mail in error, disclosing, copying, distributing or
> > > taking any action in reliance of this e-mail is strictly prohibited and 
> > > may
> > > be unlawful. Instead, please notify us immediately by return e-mail and
> > > promptly delete this message and its attachments from your computer 
> > > system.
> > > We do not waive any work product or other applicable legal privilege(s) by
> > > the transmission of this message.
> > > ***
> > >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [math] working on increasing performance for Math3

2021-05-08 Thread Gilles Sadowski 
Hello.

Le sam. 8 mai 2021 à 08:42, Benjamin Marwell  a écrit :
>
> Instead of using byte buddy, why not just maven multi release jars? *1

Thanks for the suggestion.
Again, I don't know how to do it concretely[1] nor the implications
(IIRC, the mention of multi-release JARs was frowned upon some
time ago).

> The Java9+ impl will go to META-INF/java9 or so. We did that in the
> maven-jlink-plugin for example. *2
> Will be much faster and work on Java 16+. Much easier to rest.

All good points, I guess.

However, what about the potential of having a user-selectable
version of the implementations of the functions contained in
the JDK's "Math" class?

Unless one can provide a reference that, from Java 9 on, the
accuracy cannot be improved upon what the JDK computes,
the point remains that "FastMath" is more accurate, so that we
cannot assume that a transparent call to "java.util.Math" won't
have side-effects.

> Drawback: bad IDE support

Personally I don't care. ;-)

Regards,
Gilles

[1] If you'd like to propose a patch/PR, I could set up a dedicated branch.

>
> 1: https://maven.apache.org/plugins/maven-compiler-plugin/multirelease.html
>
> 2:
> https://github.com/apache/maven-jlink-plugin/commit/f8bdf5050c266854524aaa51eb36109c00ca692a
>
> HTH
> Ben
>
>
> On Fri, 7 May 2021, 10:52 Erik Svensson,  wrote:
>
> > Howdy all!
> >
> >
> >
> > I’m looking to do some work on FastMath to increase performance by using
> > java.lang.Math where it is applicable (ie where there is an
> > @HotspotIntrinsicCandidate annotation on the method).
> >
> > Since HIC was introduced in java 9 and the code needs to work on pre-java
> > 9 and I don’t want to compromise performance (since performance is the
> > whole reason I’m doing this) I’m thinking about using ByteBuddy to
> > construct a proxy class but I’m unsure whether that is allowed in Apache
> > Commons.
> >
> > Btw, I’ve tested using MethodHandles but that consumed almost all the
> > performance improvement java.lang.Math had over FastMath (for sin anyway).
> >
> >
> >
> > Cheers
> >
> >
> >
> > *Erik Svensson*
> >
> > Principal Architect
> > Strategic Programs, Platform & Product Engineering
> >
> > [image: Nasdaq, Inc.] 
> >
> > *Desk*
> > *Mobile*
> > *Email*
> > *Address  *
> >
> > + 46 8 405 66 39
> > + 46 73 449 66 39
> > erik.svens...@nasdaq.com
> > Tullvaktsvägen 15, Stockholm
> >
> > [image: signature_170089658] 
> >
> > [image: signature_1919909931] 
> >
> > [image: signature_1754902186] 
> >
> > [image: signature_1778387217] 
> >
> > [image: signature_1326178797] 
> >
> > rewritetomorrow.com
> >
> >
> >
> >  ***
> > CONFIDENTIALITY AND PRIVACY NOTICE: This e-mail and any attachments are
> > for the exclusive and confidential use of the intended recipient and may
> > constitute non-public information.  Personal data in this email is governed
> > by our Privacy Policy at  https://www.nasdaq.com/privacy-statement
> > unless explicitly excluded from it; please see the section in the policy
> > entitled “Situations Where This Privacy Policy Does Not Apply” for
> > circumstances where different privacy terms govern emailed personal data.
> > If you received this e-mail in error, disclosing, copying, distributing or
> > taking any action in reliance of this e-mail is strictly prohibited and may
> > be unlawful. Instead, please notify us immediately by return e-mail and
> > promptly delete this message and its attachments from your computer system.
> > We do not waive any work product or other applicable legal privilege(s) by
> > the transmission of this message.
> > ***
> >

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [math] working on increasing performance for Math3

2021-05-07 Thread Benjamin Marwell 
Instead of using byte buddy, why not just maven multi release jars? *1

The Java9+ impl will go to META-INF/java9 or so. We did that in the
maven-jlink-plugin for example. *2
Will be much faster and work on Java 16+. Much easier to rest.
Drawback: bad IDE support

1: https://maven.apache.org/plugins/maven-compiler-plugin/multirelease.html

2:
https://github.com/apache/maven-jlink-plugin/commit/f8bdf5050c266854524aaa51eb36109c00ca692a

HTH
Ben


On Fri, 7 May 2021, 10:52 Erik Svensson,  wrote:

> Howdy all!
>
>
>
> I’m looking to do some work on FastMath to increase performance by using
> java.lang.Math where it is applicable (ie where there is an
> @HotspotIntrinsicCandidate annotation on the method).
>
> Since HIC was introduced in java 9 and the code needs to work on pre-java
> 9 and I don’t want to compromise performance (since performance is the
> whole reason I’m doing this) I’m thinking about using ByteBuddy to
> construct a proxy class but I’m unsure whether that is allowed in Apache
> Commons.
>
> Btw, I’ve tested using MethodHandles but that consumed almost all the
> performance improvement java.lang.Math had over FastMath (for sin anyway).
>
>
>
> Cheers
>
>
>
> *Erik Svensson*
>
> Principal Architect
> Strategic Programs, Platform & Product Engineering
>
> [image: Nasdaq, Inc.] 
>
> *Desk*
> *Mobile*
> *Email*
> *Address  *
>
> + 46 8 405 66 39
> + 46 73 449 66 39
> erik.svens...@nasdaq.com
> Tullvaktsvägen 15, Stockholm
>
> [image: signature_170089658] 
>
> [image: signature_1919909931] 
>
> [image: signature_1754902186] 
>
> [image: signature_1778387217] 
>
> [image: signature_1326178797] 
>
> rewritetomorrow.com
>
>
>
>  ***
> CONFIDENTIALITY AND PRIVACY NOTICE: This e-mail and any attachments are
> for the exclusive and confidential use of the intended recipient and may
> constitute non-public information.  Personal data in this email is governed
> by our Privacy Policy at  https://www.nasdaq.com/privacy-statement
> unless explicitly excluded from it; please see the section in the policy
> entitled “Situations Where This Privacy Policy Does Not Apply” for
> circumstances where different privacy terms govern emailed personal data.
> If you received this e-mail in error, disclosing, copying, distributing or
> taking any action in reliance of this e-mail is strictly prohibited and may
> be unlawful. Instead, please notify us immediately by return e-mail and
> promptly delete this message and its attachments from your computer system.
> We do not waive any work product or other applicable legal privilege(s) by
> the transmission of this message.
> ***
>

Re: [math] working on increasing performance for Math3

2021-05-07 Thread Gilles Sadowski 
Hello.

Le ven. 7 mai 2021 à 10:52, Erik Svensson  a écrit :
>
> Howdy all!
>
>
>
> I’m looking to do some work on FastMath

Thanks for your interest.

> to increase performance by using java.lang.Math where it is applicable (ie 
> where there is an @HotspotIntrinsicCandidate annotation on the method).

Please be sure have a look at the open issues that mention
"FastMath" on the bug tracking system.[1]

>
> Since HIC was introduced in java 9 and the code needs to work on pre-java 9 
> and I don’t want to compromise performance (since performance is the whole 
> reason I’m doing this)

One important point is that "FastMath" was probably not a
good name, as the most consistent feature is accuracy,
better than JDK's "Math" at the time.  If that's still the case
we may not want to loose that.

> I’m thinking about using ByteBuddy to construct a proxy class

I don't know anything about it, but it seems a way to implement
the feature that will let the caller decide what is more important
(precision or performance).  Correct?

> but I’m unsure whether that is allowed in Apache Commons.

It's under ASL 2.0.
So the only question would be whether a dependency towards
a library outside Commons is acceptable.
Could this be implemented around an _optional_ dependency?

>
> Btw, I’ve tested using MethodHandles but that consumed almost all the 
> performance improvement java.lang.Math had over FastMath (for sin anyway).
>

Did you use JMH for the benchmark?[2]
The first step is perhaps to open a new JIRA issue and post the
result over there.
We want to modularize Commons Math, so setting up a module
for JMH testing is welcome.

Regards,
Gilles

[1] 
https://issues.apache.org/jira/issues/?jql=project%20%3D%20MATH%20AND%20status%20%3D%20Open%20AND%20description%20%20~%20%22FastMath%22
[2] At the time, we implemented (2) custom benchmarks (see the test sources).

>
> Cheers
>
>
>
> Erik Svensson
>

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org