You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Erik Svensson <Er...@nasdaq.com> on 2021/05/07 08:52:36 UTC
[math] working on increasing performance for Math3
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
[Nasdaq, Inc.]<http://www.nasdaq.com/>
Desk
Mobile
Email
Address
+ 46 8 405 66 39
+ 46 73 449 66 39
erik.svensson@nasdaq.com
Tullvaktsvägen 15, Stockholm
[signature_170089658]<https://www.facebook.com/nasdaq/>
[signature_1919909931]<https://twitter.com/nasdaq>
[signature_1754902186]<https://www.linkedin.com/company/nasdaq>
[signature_1778387217]<https://www.instagram.com/nasdaq/>
[signature_1326178797]<https://www.pinterest.com/nasdaq/>
rewritetomorrow.com<http://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
Posted by Gilles Sadowski <gi...@gmail.com>.
Hello.
Le ven. 7 mai 2021 à 10:52, Erik Svensson <Er...@nasdaq.com> 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-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [math] working on increasing performance for Math3
Posted by Gilles Sadowski <gi...@gmail.com>.
>> [...]
>
> 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-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [math] working on increasing performance for Math3
Posted by sebb <se...@gmail.com>.
On Sat, 8 May 2021 at 13:14, Gilles Sadowski <gi...@gmail.com> wrote:
>
> Hello.
>
> Le sam. 8 mai 2021 à 08:42, Benjamin Marwell <bm...@apache.org> 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, <Er...@nasdaq.com> 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.] <http://www.nasdaq.com/>
> > >
> > > *Desk*
> > > *Mobile*
> > > *Email*
> > > *Address *
> > >
> > > + 46 8 405 66 39
> > > + 46 73 449 66 39
> > > erik.svensson@nasdaq.com
> > > Tullvaktsvägen 15, Stockholm
> > >
> > > [image: signature_170089658] <https://www.facebook.com/nasdaq/>
> > >
> > > [image: signature_1919909931] <https://twitter.com/nasdaq>
> > >
> > > [image: signature_1754902186] <https://www.linkedin.com/company/nasdaq>
> > >
> > > [image: signature_1778387217] <https://www.instagram.com/nasdaq/>
> > >
> > > [image: signature_1326178797] <https://www.pinterest.com/nasdaq/>
> > >
> > > 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-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [math] working on increasing performance for Math3
Posted by Ralph Goers <ra...@dslextreme.com>.
> On May 8, 2021, at 5:14 AM, Gilles Sadowski <gi...@gmail.com> wrote:
>
> Hello.
>
> Le sam. 8 mai 2021 à 08:42, Benjamin Marwell <bmarwell@apache.org <ma...@apache.org>> 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
Posted by Gilles Sadowski <gi...@gmail.com>.
Hello.
Le sam. 8 mai 2021 à 08:42, Benjamin Marwell <bm...@apache.org> 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, <Er...@nasdaq.com> 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.] <http://www.nasdaq.com/>
> >
> > *Desk*
> > *Mobile*
> > *Email*
> > *Address *
> >
> > + 46 8 405 66 39
> > + 46 73 449 66 39
> > erik.svensson@nasdaq.com
> > Tullvaktsvägen 15, Stockholm
> >
> > [image: signature_170089658] <https://www.facebook.com/nasdaq/>
> >
> > [image: signature_1919909931] <https://twitter.com/nasdaq>
> >
> > [image: signature_1754902186] <https://www.linkedin.com/company/nasdaq>
> >
> > [image: signature_1778387217] <https://www.instagram.com/nasdaq/>
> >
> > [image: signature_1326178797] <https://www.pinterest.com/nasdaq/>
> >
> > 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-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [math] working on increasing performance for Math3
Posted by Gilles Sadowski <gi...@gmail.com>.
Hi.
Le mer. 12 mai 2021 à 13:23, Erik Svensson <Er...@nasdaq.com> 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-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [math] working on increasing performance for Math3
Posted by Gilles Sadowski <gi...@gmail.com>.
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 <gi...@gmail.com> a écrit :
>
> Le mer. 12 mai 2021 à 13:23, Erik Svensson <Er...@nasdaq.com> 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-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [math] working on increasing performance for Math3
Posted by Gilles Sadowski <gi...@gmail.com>.
Le mer. 12 mai 2021 à 13:23, Erik Svensson <Er...@nasdaq.com> 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-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [math] working on increasing performance for Math3
Posted by Erik Svensson <Er...@nasdaq.com>.
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
<http://www.nasdaq.com/>
Desk
Mobile
Email
Address
+ 46 8 405 66 39
+ 46 73 449 66 39
erik.svensson@nasdaq.com
Tullvaktsvägen 15, Stockholm
<https://www.facebook.com/nasdaq/>
<https://twitter.com/nasdaq>
<https://www.linkedin.com/company/nasdaq>
<https://www.instagram.com/nasdaq/>
<https://www.pinterest.com/nasdaq/>
rewritetomorrow.com <http://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-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [math] working on increasing performance for Math3
Posted by Brett Okken <br...@gmail.com>.
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 <Er...@nasdaq.com> wrote:
>
>
> On 2021-05-10, 18:03, "Brett Okken" <br...@gmail.com> 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-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@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-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [math] working on increasing performance for Math3
Posted by Erik Svensson <Er...@nasdaq.com>.
On 2021-05-10, 18:03, "Brett Okken" <br...@gmail.com> 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-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@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-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [math] working on increasing performance for Math3
Posted by Brett Okken <br...@gmail.com>.
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-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [math] working on increasing performance for Math3
Posted by Erik Svensson <Er...@nasdaq.com>.
On 2021-05-10, 17:14, "Brett Okken" <br...@gmail.com> 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-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@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
Posted by Brett Okken <br...@gmail.com>.
> 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-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [math] working on increasing performance for Math3
Posted by Erik Svensson <Er...@nasdaq.com>.
On 2021-05-10, 13:52, "Brett Okken" <br...@gmail.com> 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 <Er...@nasdaq.com>
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
> <http://www.nasdaq.com/>
> Desk
> Mobile
> Email
> Address
> + 46 8 405 66 39
> + 46 73 449 66 39
> erik.svensson@nasdaq.com
> Tullvaktsvägen 15, Stockholm
> <https://www.google.com/maps/search/Tullvaktsv%C3%A4gen+15,+Stockholm?entry=gmail&source=g>
> <https://www.facebook.com/nasdaq/>
> <https://twitter.com/nasdaq>
> <https://www.linkedin.com/company/nasdaq>
> <https://www.instagram.com/nasdaq/>
> <https://www.pinterest.com/nasdaq/>
> rewritetomorrow.com <http://rewritetomorrow.com/>
>
>
> On 2021-05-08, 08:42, "Benjamin Marwell" <bm...@apache.org> 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, <Er...@nasdaq.com>
> 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.] <http://www.nasdaq.com/>
> >
> > *Desk*
> > *Mobile*
> > *Email*
> > *Address *
> >
> > + 46 8 405 66 39
> > + 46 73 449 66 39
> > erik.svensson@nasdaq.com
> > Tullvaktsvägen 15, Stockholm
> >
> > [image: signature_170089658] <https://www.facebook.com/nasdaq/>
> >
> > [image: signature_1919909931] <https://twitter.com/nasdaq>
> >
> > [image: signature_1754902186] <
> https://www.linkedin.com/company/nasdaq>
> >
> > [image: signature_1778387217] <https://www.instagram.com/nasdaq/>
> >
> > [image: signature_1326178797] <https://www.pinterest.com/nasdaq/>
> >
> > 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.
> > *******************************************
> >
>
> *******************************************
> 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-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@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
Posted by Brett Okken <br...@gmail.com>.
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 <Er...@nasdaq.com>
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
> <http://www.nasdaq.com/>
> Desk
> Mobile
> Email
> Address
> + 46 8 405 66 39
> + 46 73 449 66 39
> erik.svensson@nasdaq.com
> Tullvaktsvägen 15, Stockholm
> <https://www.google.com/maps/search/Tullvaktsv%C3%A4gen+15,+Stockholm?entry=gmail&source=g>
> <https://www.facebook.com/nasdaq/>
> <https://twitter.com/nasdaq>
> <https://www.linkedin.com/company/nasdaq>
> <https://www.instagram.com/nasdaq/>
> <https://www.pinterest.com/nasdaq/>
> rewritetomorrow.com <http://rewritetomorrow.com/>
>
>
> On 2021-05-08, 08:42, "Benjamin Marwell" <bm...@apache.org> 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, <Er...@nasdaq.com>
> 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.] <http://www.nasdaq.com/>
> >
> > *Desk*
> > *Mobile*
> > *Email*
> > *Address *
> >
> > + 46 8 405 66 39
> > + 46 73 449 66 39
> > erik.svensson@nasdaq.com
> > Tullvaktsvägen 15, Stockholm
> >
> > [image: signature_170089658] <https://www.facebook.com/nasdaq/>
> >
> > [image: signature_1919909931] <https://twitter.com/nasdaq>
> >
> > [image: signature_1754902186] <
> https://www.linkedin.com/company/nasdaq>
> >
> > [image: signature_1778387217] <https://www.instagram.com/nasdaq/>
> >
> > [image: signature_1326178797] <https://www.pinterest.com/nasdaq/>
> >
> > 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.
> > *******************************************
> >
>
> *******************************************
> 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-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
Re: [math] working on increasing performance for Math3
Posted by Erik Svensson <Er...@nasdaq.com>.
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
<http://www.nasdaq.com/>
Desk
Mobile
Email
Address
+ 46 8 405 66 39
+ 46 73 449 66 39
erik.svensson@nasdaq.com
Tullvaktsvägen 15, Stockholm
<https://www.facebook.com/nasdaq/>
<https://twitter.com/nasdaq>
<https://www.linkedin.com/company/nasdaq>
<https://www.instagram.com/nasdaq/>
<https://www.pinterest.com/nasdaq/>
rewritetomorrow.com <http://rewritetomorrow.com/>
On 2021-05-08, 08:42, "Benjamin Marwell" <bm...@apache.org> 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, <Er...@nasdaq.com> 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.] <http://www.nasdaq.com/>
>
> *Desk*
> *Mobile*
> *Email*
> *Address *
>
> + 46 8 405 66 39
> + 46 73 449 66 39
> erik.svensson@nasdaq.com
> Tullvaktsvägen 15, Stockholm
>
> [image: signature_170089658] <https://www.facebook.com/nasdaq/>
>
> [image: signature_1919909931] <https://twitter.com/nasdaq>
>
> [image: signature_1754902186] <https://www.linkedin.com/company/nasdaq>
>
> [image: signature_1778387217] <https://www.instagram.com/nasdaq/>
>
> [image: signature_1326178797] <https://www.pinterest.com/nasdaq/>
>
> 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.
> *******************************************
>
*******************************************
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-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [math] working on increasing performance for Math3
Posted by Benjamin Marwell <bm...@apache.org>.
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, <Er...@nasdaq.com> 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.] <http://www.nasdaq.com/>
>
> *Desk*
> *Mobile*
> *Email*
> *Address *
>
> + 46 8 405 66 39
> + 46 73 449 66 39
> erik.svensson@nasdaq.com
> Tullvaktsvägen 15, Stockholm
>
> [image: signature_170089658] <https://www.facebook.com/nasdaq/>
>
> [image: signature_1919909931] <https://twitter.com/nasdaq>
>
> [image: signature_1754902186] <https://www.linkedin.com/company/nasdaq>
>
> [image: signature_1778387217] <https://www.instagram.com/nasdaq/>
>
> [image: signature_1326178797] <https://www.pinterest.com/nasdaq/>
>
> 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.
> *******************************************
>