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.svens...@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" <bmarw...@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, <erik.svens...@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.svens...@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-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
