About the performance of indy

classic Classic list List threaded Threaded
17 messages Options
12
Reply | Threaded
Open this post in threaded view
|

About the performance of indy

Daniel.Sun
Hi all,

      The performance of indy has been improved a lot, here is the
report[1]:

Benchmark                                                indy2 VS indy1
indy2 VS cs
CallsiteBench.dispatch_megamorphic 3675%                25.83%
CallsiteBench.dispatch_monomorphic 5.72%                188.62%
CallsiteBench.dispatch_polymorphic 3000%               -17.11%
(Note:  indy2: the indy with improved performance, indy1: the old indy, cs:
the legacy callsite caching used by default now)

      If nobody rejects the PR1135[2] in 72 hours, I will merge it. As for
whether to enable indy by default, it will be another topic...

      At last, I want to thank Jochen for reviewing PR1135[2] and thank
Cédric for helping me solve the Gradle dependency usage issue.

Cheers,
Daniel.Sun
[1] https://github.com/apache/groovy/pull/1135#issuecomment-571961230
[2] https://github.com/apache/groovy/pull/1135



-----
Apache Groovy committer & PMC member
Blog: http://blog.sunlan.me 
Twitter: @daniel_sun

--
Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html
Apache Groovy committer & PMC member

Blog: http://blog.sunlan.me
Twitter: @daniel_sun
Reply | Threaded
Open this post in threaded view
|

RE: About the performance of indy

Milles, Eric (TR Tech, Content & Ops)
What do the percentages represent in the benchmark results?  Is there a concern that indy2 vs compile static is negative.  A column for indy1 v. cs may help understanding.
 
-----Original Message-----
From: Daniel.Sun <[hidden email]>
Sent: Wednesday, January 8, 2020 3:37 AM
To: [hidden email]
Subject: About the performance of indy
 
Hi all,
 
      The performance of indy has been improved a lot, here is the
report[1]:
 
Benchmark                                  indy2 VS indy1       indy2 VS cs
CallsiteBench.dispatch_megamorphic      3675%                   25.83%
CallsiteBench.dispatch_monomorphic      5.72%                   188.62%
CallsiteBench.dispatch_polymorphic      3000%                  -17.11%
(Note:  indy2: the indy with improved performance, indy1: the old indy, cs: the legacy callsite caching used by default now)
 
      If nobody rejects the PR1135[2] in 72 hours, I will merge it. As for whether to enable indy by default, it will be another topic...
 
      At last, I want to thank Jochen for reviewing PR1135[2] and thank Cédric for helping me solve the Gradle dependency usage issue.
 
Cheers,
Daniel.Sun
 
 
 
-----
Apache Groovy committer & PMC member
Twitter: @daniel_sun
 
--
 
Reply | Threaded
Open this post in threaded view
|

Re: About the performance of indy

Guillaume Laforge
Administrator
"cs" here stands for "call site", not "compile static".

Guillaume


On Wed, Jan 8, 2020 at 4:36 PM Milles, Eric (TR Tech, Content & Ops) <[hidden email]> wrote:
What do the percentages represent in the benchmark results?  Is there a concern that indy2 vs compile static is negative.  A column for indy1 v. cs may help understanding.
 
-----Original Message-----
From: Daniel.Sun <[hidden email]>
Sent: Wednesday, January 8, 2020 3:37 AM
To: [hidden email]
Subject: About the performance of indy
 
Hi all,
 
      The performance of indy has been improved a lot, here is the
report[1]:
 
Benchmark                                  indy2 VS indy1       indy2 VS cs
CallsiteBench.dispatch_megamorphic      3675%                   25.83%
CallsiteBench.dispatch_monomorphic      5.72%                   188.62%
CallsiteBench.dispatch_polymorphic      3000%                  -17.11%
(Note:  indy2: the indy with improved performance, indy1: the old indy, cs: the legacy callsite caching used by default now)
 
      If nobody rejects the PR1135[2] in 72 hours, I will merge it. As for whether to enable indy by default, it will be another topic...
 
      At last, I want to thank Jochen for reviewing PR1135[2] and thank Cédric for helping me solve the Gradle dependency usage issue.
 
Cheers,
Daniel.Sun
 
 
 
-----
Apache Groovy committer & PMC member
Twitter: @daniel_sun
 
--
 


--
Guillaume Laforge
Apache Groovy committer
Developer Advocate @ Google Cloud Platform

Reply | Threaded
Open this post in threaded view
|

Re: About the performance of indy

Daniel.Sun
Yep, we are comparing the performance of different version of DYNAMIC Groovy.

The percentage formula for "a VS b": (a - b) / b.  NOTE: a and b in the
formula are scores output by JMH.

Cheers,
Daniel.Sun



-----
Apache Groovy committer & PMC member
Blog: http://blog.sunlan.me 
Twitter: @daniel_sun

--
Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html
Apache Groovy committer & PMC member

Blog: http://blog.sunlan.me
Twitter: @daniel_sun
Reply | Threaded
Open this post in threaded view
|

RE: About the performance of indy

Milles, Eric (TR Tech, Content & Ops)
Do "a" and "b" represent time taken, operations completed, some other unit?  Are positive values good or bad?  You haven't given much to be able to understand and evaluate the benchmark.

-----Original Message-----
From: Daniel.Sun <[hidden email]>
Sent: Wednesday, January 8, 2020 10:11 AM
To: [hidden email]
Subject: Re: About the performance of indy

Yep, we are comparing the performance of different version of DYNAMIC Groovy.

The percentage formula for "a VS b": (a - b) / b.  NOTE: a and b in the formula are scores output by JMH.

Cheers,
Daniel.Sun



-----
Apache Groovy committer & PMC member
Blog: https://urldefense.proofpoint.com/v2/url?u=http-3A__blog.sunlan.me&d=DwICAg&c=4ZIZThykDLcoWk-GVjSLmy8-1Cr1I4FWIvbLFebwKgY&r=tPJuIuL_GkTEazjQW7vvl7mNWVGXn3yJD5LGBHYYHww&m=__vA299pRTL6yfUwM1mf5SGWa5nU8xVnMKB9EN0pcPc&s=CHJ1uNywU9Rv2xReNeP6cF01dUJ0rZc1uZDw6P3GRWA&e=
Twitter: @daniel_sun

--
Sent from: https://urldefense.proofpoint.com/v2/url?u=http-3A__groovy.329449.n5.nabble.com_Groovy-2DDev-2Df372993.html&d=DwICAg&c=4ZIZThykDLcoWk-GVjSLmy8-1Cr1I4FWIvbLFebwKgY&r=tPJuIuL_GkTEazjQW7vvl7mNWVGXn3yJD5LGBHYYHww&m=__vA299pRTL6yfUwM1mf5SGWa5nU8xVnMKB9EN0pcPc&s=rmiRHf5T7oSTrdz4VPdYyrzzJKL55j3I7zbGh0EvREo&e= 
Reply | Threaded
Open this post in threaded view
|

RE: About the performance of indy

Daniel.Sun
FYI.
https://github.com/apache/groovy/pull/1135#issuecomment-571961230





-----
Apache Groovy committer & PMC member
Blog: http://blog.sunlan.me 
Twitter: @daniel_sun

--
Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html
Apache Groovy committer & PMC member

Blog: http://blog.sunlan.me
Twitter: @daniel_sun
MG
Reply | Threaded
Open this post in threaded view
|

Re: About the performance of indy

MG
These results look great, Daniel G-)

With regards to nomenclature: What is your definition of megamorphic as
compared to polymorphic ? The web does not seem to be in complete
agreement on these terms - I assume you are referring to the number of
call site cache entries needed (monomorphic: 1, polymorphic: > 1,
megamorphic: > cache size) ?

Cheers,
mg

PS: Came across some Kotlin code during my web search. Mind still
shudders at seeing the syntax
var result: Foo= calcFooResult()
used in a statically typed language - bloated, hard to read, why are we
seemingly assigning a value to a type...


On 08/01/2020 17:26, Daniel.Sun wrote:

> FYI.
> https://github.com/apache/groovy/pull/1135#issuecomment-571961230
>
>
>
>
>
> -----
> Apache Groovy committer & PMC member
> Blog: http://blog.sunlan.me
> Twitter: @daniel_sun
>
> --
> Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html
>

Reply | Threaded
Open this post in threaded view
|

Re: About the performance of indy

Angelo Schneider
Necause languages like Pascal and Modula II or Ada use:

var_name : TType; // this is a declaration of a variable named „var_name“ and of type TType.

However in  your example I assume either the var, or the „: Foo“ is redundant. Because var is used in Kotline for type interference, if I’m not mistaken.

Best Regards

privat: -------------------- www.oomentor.de --------------------------
Angelo Schneider         OOAD/UML         [hidden email]
Putlitzstr. 24       Patterns/FrameWorks          
76137 Karlsruhe           C++/JAVA                Mob: +49 172 9873893

Am 09.01.2020 um 04:37 schrieb MG <[hidden email]>:

These results look great, Daniel G-)

With regards to nomenclature: What is your definition of megamorphic as compared to polymorphic ? The web does not seem to be in complete agreement on these terms - I assume you are referring to the number of call site cache entries needed (monomorphic: 1, polymorphic: > 1, megamorphic: > cache size) ?

Cheers,
mg

PS: Came across some Kotlin code during my web search. Mind still shudders at seeing the syntax
var result: Foo= calcFooResult()
used in a statically typed language - bloated, hard to read, why are we seemingly assigning a value to a type...


On 08/01/2020 17:26, Daniel.Sun wrote:
FYI.
https://github.com/apache/groovy/pull/1135#issuecomment-571961230





-----
Apache Groovy committer & PMC member
Blog: http://blog.sunlan.me
Twitter: @daniel_sun

--
Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html



MG
Reply | Threaded
Open this post in threaded view
|

Re: About the performance of indy

MG
Don't want to turn this into an endless off topic thread, but:
  1. Kotlin is not of the Algol/Pascal/... language tree but a C syntax language
  2. C syntax is the dominant syntax used (C/C++/Java/C#) for a reason (with Python being the odd man out)
  3. The foo : Foo syntax kind of works, as long as there is no assignment on declaration, because then it becomes foo : Foo = initialFooVal, which to me is just ugly, since it looks like we are assigning initialFooVal to type Foo
  4. The example was taken from a Kotlin blog, and is the Kotlin syntax for assignment on declaration when giving an explicit type*
Kind regards,
mg

*As long as you are always using type inference (or in a weakly typed language such as JavaScript), there is of course no explicit type, and the syntax becomes clear & concise, the same as in Groovy (def foo = initialFooVal).


On 09/01/2020 00:46, Angelo Schneider wrote:
Necause languages like Pascal and Modula II or Ada use:

var_name : TType; // this is a declaration of a variable named „var_name“ and of type TType.

However in  your example I assume either the var, or the „: Foo“ is redundant. Because var is used in Kotline for type interference, if I’m not mistaken.

Best Regards

privat: -------------------- www.oomentor.de --------------------------
Angelo Schneider         OOAD/UML         [hidden email]
Putlitzstr. 24       Patterns/FrameWorks          
76137 Karlsruhe           C++/JAVA                Mob: +49 172 9873893

Am 09.01.2020 um 04:37 schrieb MG <[hidden email]>:

These results look great, Daniel G-)

With regards to nomenclature: What is your definition of megamorphic as compared to polymorphic ? The web does not seem to be in complete agreement on these terms - I assume you are referring to the number of call site cache entries needed (monomorphic: 1, polymorphic: > 1, megamorphic: > cache size) ?

Cheers,
mg

PS: Came across some Kotlin code during my web search. Mind still shudders at seeing the syntax
var result: Foo= calcFooResult()
used in a statically typed language - bloated, hard to read, why are we seemingly assigning a value to a type...


On 08/01/2020 17:26, Daniel.Sun wrote:
FYI.
https://github.com/apache/groovy/pull/1135#issuecomment-571961230





-----
Apache Groovy committer & PMC member
Blog: http://blog.sunlan.me
Twitter: @daniel_sun

--
Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html




Reply | Threaded
Open this post in threaded view
|

Re: About the performance of indy

Jochen Theodorou
In reply to this post by MG

Am 08.01.20 um 22:37 schrieb MG:
> These results look great, Daniel G-)
>
> With regards to nomenclature: What is your definition of megamorphic as
> compared to polymorphic ? The web does not seem to be in complete
> agreement on these terms - I assume you are referring to the number of
> call site cache entries needed (monomorphic: 1, polymorphic: > 1,
> megamorphic: > cache size) ?


monomorphic: any number of calls of one type only
polymorphic: any number of calls of at max cachesize different types
megamorphic: any number of calls of more than max cachesize different types

In Java a cal of the structure x.foo(bar) is of one type if the type of
x does not change, the type of bar is not relevant beyond the first
selection, since we expect static method selection. If the declaration
type of x is final, then in theory you do not even need to check the
receiver type of x later.

In Groovy we have dynamic method selection, thus we need to check x and
bar all the time, plus code for categories and methods added/replaced
through meta classes. So the number of call types will be much higher in
Groovy, even for Java style code and only in very specific situations
this could be different. Plus some more clutter with when we actually
have the information about the to be selected method.

bye Jochen

12