Am 13.01.20 um 15:49 schrieb Daniel Sun:
Hi Jochen,
The changed example will run faster than the original one because cache
will always be hit for each argument. Actually we can make run even much
faster, loop more than 100_000 times, e.g. 1_000_000, because the optimize
threshold re
Hi Jochen,
The changed example will run faster than the original one because cache
will always be hit for each argument. Actually we can make run even much
faster, loop more than 100_000 times, e.g. 1_000_000, because the optimize
threshold reaches, the related MH will be linked to the cs.
Am 10.01.20 um 16:14 schrieb Daniel.Sun:
Hi Jochen,
> If you want to get the maximum performance then I would suggest to
work
with the guards instead of falling back to a hashed map.
Thanks for your suggestions :-)
After we constructed the following "tree" MH with guards, we
Hi Jochen,
> If you want to get the maximum performance then I would suggest to
work
with the guards instead of falling back to a hashed map.
Thanks for your suggestions :-)
After we constructed the following "tree" MH with guards, we have to set
target to link the MH to the related
On 09.01.20 19:01, Daniel.Sun wrote:
Hi Jochen,
I am still thinking about how to improve indy performance further in
the method overload cases, e.g.
```
def same(String obj) { return obj }
def same(int obj) { return obj }
def same(float obj) { return obj }
for (int i = 0; i < 10; i++)
The PR#1135[1] implements the PIC for Groovy indy. As the book
"Efficient Polymorphic Calls" said[2], "If a send is megamorphic(invokes
many different methods), it cannot be handled efficiently by PICs.
Fortunately, such sends are the exception rather than the rule.", so I will
not spend more
Hi Jochen,
I am still thinking about how to improve indy performance further in
the method overload cases, e.g.
```
def same(String obj) { return obj }
def same(int obj) { return obj }
def same(float obj) { return obj }
for (int i = 0; i < 10; i++) {
[1, 1.0f, '1.0'].each { same(it
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
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 lo
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 mi
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,
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
ry 8, 2020 10:11 AM
To: d...@groovy.incubator.apache.org
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.S
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_s
"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) <
eric.mil...@thomsonreuters.com> wrote:
> What do the percentages represent in the benchmark results? Is there a
> concern that indy2 vs compile static is neg
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
Sent: Wednesday, January 8, 2020 3:37 AM
To: d...@groovy.incubator.apache.org
S
16 matches
Mail list logo
