On 2021-05-10, 13:52, "Brett Okken" <brett.okken...@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 <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
>
*******************************************
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.
*******************************************
