Using indy vs call-site

[Raviteja Lokineni <ra...@gmail.com>]

Hi all,

Just wanted to gather feedback on which is preferred and why? benchmarks
too, if any?

Indy source: http://www.groovy-lang.org/indy.html

I googled it up and found these:

   -
   http://stackoverflow.com/questions/29812958/execution-of-bubble-sort-is-5-times-slower-with-indy
   -
   http://blackdragsview.blogspot.com/2015/01/indy-and-compilestatic-as-tag-team-to.html

What is PIC (from the stack-overflow answer link above), I mean
abbreviation?

Thanks,
-- 
*Raviteja Lokineni* | Business Intelligence Developer
TD Ameritrade

E: raviteja.lokineni@gmail.com

[image: View Raviteja Lokineni's profile on LinkedIn]
<http://in.linkedin.com/in/ravitejalokineni>

Re: Using indy vs call-site

[Jochen Theodorou <bl...@gmx.org>]

On 24.08.2016 22:33, Winnebeck, Jason wrote:
> You mentioned the PIC limitation of 1 in Groovy, suggesting that monomorphic call sites are efficient in dynamic Groovy, but not polymorphic or megamorphic ones. Is the call site considered polymorphic or monomorphic if the method called is via a common interface?
>
> void rot90(Shape s) {
>    s.rotate(90)
> }
>
> for (Shape s in (large list of squares, triangles, circles, etc.)) {
>    rot90(s)
> }

that is not monomorphic in Groovy.

> You mentioned that indy takes more setup for call site caching, does that imply that an application relying on a large number of poly/megamorphic call sites is better served by the pre-indy method?

in tight loops with current Groovy, yes. This holds, till we change things

bye Jochen

RE: Using indy vs call-site

["Winnebeck, Jason" <Ja...@windstream.com>]

You mentioned the PIC limitation of 1 in Groovy, suggesting that monomorphic call sites are efficient in dynamic Groovy, but not polymorphic or megamorphic ones. Is the call site considered polymorphic or monomorphic if the method called is via a common interface?

void rot90(Shape s) {
  s.rotate(90)
}

for (Shape s in (large list of squares, triangles, circles, etc.)) {
  rot90(s)
}

You mentioned that indy takes more setup for call site caching, does that imply that an application relying on a large number of poly/megamorphic call sites is better served by the pre-indy method?

Jason

-----Original Message-----
From: Jochen Theodorou [mailto:blackdrag@gmx.org] 
Sent: Wednesday, August 24, 2016 4:02 PM
To: users@groovy.apache.org
Subject: Re: Using indy vs call-site

On 24.08.2016 20:42, Raviteja Lokineni wrote:
> Hi all,
>
> Just wanted to gather feedback on which is preferred and why? 
> benchmarks too, if any?
>
> Indy source: http://www.groovy-lang.org/indy.html
>
> I googled it up and found these:
>
>   * http://stackoverflow.com/questions/29812958/execution-of-bubble-sort-is-5-times-slower-with-indy
>   * 
> http://blackdragsview.blogspot.com/2015/01/indy-and-compilestatic-as-t
> ag-team-to.html
>
> What is PIC (from the stack-overflow answer link above), I mean 
> abbreviation?

PIC means polymorphic inline cache. Example:


def foo(x) {
   x.toString() //1
}

foo(1)           //2
foo("a string")  //3
foo(1G)          //4

during runtime the places 1-4 will be call sites, places of method calls in this case. The callsites in 2-4 always use the same type, which is why they are called monomorphic. The callsite in 1 is called with 3 different types: int, String, BigDecimal and called polymorphic or megamorpic. The distinction is usually done by how many different types the polymorphic version allows before it turns megamorphic. A PIC is then a cache with a fast method call path for the n different types the PIC supports There are different approaches to this, so I hope I am forgiven for a little bit of oversimplification. Anyway... Java supports I think a PIC of 3, Groovy currently has only monomorphic versions.... 
or a PIC of size 1. Well, worse actually, we miss the fallback for the megamorphic sites. This is the same for Groovy with and without indy. 
The difference is that the setup code in indy takes much longer than the older callsite caching code based on runtime class generation.

But this is something which will be fixed in the future.. for indy. for the runtime class generation approach I am unsure

bye Jochen



This email message and any attachments are for the sole use of the intended recipient(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message and any attachments.

Re: Using indy vs call-site

[Jochen Theodorou <bl...@gmx.org>]

On 24.08.2016 20:42, Raviteja Lokineni wrote:
> Hi all,
>
> Just wanted to gather feedback on which is preferred and why? benchmarks
> too, if any?
>
> Indy source: http://www.groovy-lang.org/indy.html
>
> I googled it up and found these:
>
>   * http://stackoverflow.com/questions/29812958/execution-of-bubble-sort-is-5-times-slower-with-indy
>   * http://blackdragsview.blogspot.com/2015/01/indy-and-compilestatic-as-tag-team-to.html
>
> What is PIC (from the stack-overflow answer link above), I mean
> abbreviation?

PIC means polymorphic inline cache. Example:


def foo(x) {
   x.toString() //1
}

foo(1)           //2
foo("a string")  //3
foo(1G)          //4

during runtime the places 1-4 will be call sites, places of method calls 
in this case. The callsites in 2-4 always use the same type, which is 
why they are called monomorphic. The callsite in 1 is called with 3 
different types: int, String, BigDecimal and called polymorphic or 
megamorpic. The distinction is usually done by how many different types 
the polymorphic version allows before it turns megamorphic. A PIC is 
then a cache with a fast method call path for the n different types the 
PIC supports There are different approaches to this, so I hope I am 
forgiven for a little bit of oversimplification. Anyway... Java supports 
I think a PIC of 3, Groovy currently has only monomorphic versions.... 
or a PIC of size 1. Well, worse actually, we miss the fallback for the 
megamorphic sites. This is the same for Groovy with and without indy. 
The difference is that the setup code in indy takes much longer than the 
older callsite caching code based on runtime class generation.

But this is something which will be fixed in the future.. for indy. for 
the runtime class generation approach I am unsure

bye Jochen