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 <erik.svens...@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.svens...@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" <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 >
