Hi Jochen
On why I am looking at projections for
behavior determination.
In my case I use an object reference
in the receiver to determine the method to execute. One
could say that this is a projection
from the class to an address which is an integer. So in this
case computing the projection is
Am 16.03.2015 00:42, schrieb Mark Roos:
Jochen writes
So far I have avoided using projections since I am not sure
about how to
do this. Basically I am missing a way to project a Class to an
usable
int.
After this discussion, reading Rémi's suggested paper and some more
Jochen writes
So far I have avoided using projections since I am not sure about
how to
do this. Basically I am missing a way to project a Class to an
usable
int.
After this discussion, reading Rémi's suggested paper and some more
analysis of my code base
I am
Am 12.03.2015 19:37, schrieb Mark Roos:
Jochen
The comment on the test part of the pic is interesting. Since I am
looking at multimethods
I would like to have a better understanding of how you decide which
code to dispatch at a site.
We currently have no PIC in Groovy. The naive
Am 12.03.2015 00:13, schrieb Mark Roos:
Hi Jochen
I have to think about yours some more but I thought I would share mine.
I condensed it to
make it easier to explain.
my pleasure
[…]
I extended callsite to hold a bunch of values one of which is the depth.
And my model for the cache is up
We did have optional instrumentation to maintain the PIC counts, and used
that to guide our choice of ordering, but we didn¹t use it on a per PIC
level to do anything at run time, it was just a case of gathering a lot of
data and printing out the stats. It did add some overhead, but I think
Vlad¹s
Jochen
The comment on the test part of the pic is interesting. Since I am looking
at multimethods
I would like to have a better understanding of how you decide which code
to dispatch at a site.
My pic suggestion assumes that one test method is applied to the arguments
and its result
used
Thanks Rémi, I was looking for a paper like that. Not for multimethods
but for a way to
improve code reuse across a hierarchy. Will savor it later with a fine
pinot :)
What I was thinking about for multi methods was a simpler tree like
approach.
http://dl.acm.org/citation.cfm?id=28732
In
Rémi your suggested paper and comments caused me to take a look at my code
base some more. What I found was that for a given selector+arity 93% of
them
have 5 implementations or less ( across 2000 classes and 25K methods).
Combining
this with my prior observations that 99% of the call sites
Am 11.03.2015 15:37, schrieb Remi Forax:
[...]
Sometime, yes, if you count the frequency of each branch by example,
here is another code that implements a bimorphic inlining cache that
expand to a dispatch table local to a callsite if necessary, I think you
can adapt this code to implement what
be relevant.
-Original Message-
From: mlvm-dev [mailto:mlvm-dev-boun...@openjdk.java.net] On Behalf Of Jochen
Theodorou
Sent: 11 March 2015 14:00
To: Da Vinci Machine Project
Subject: Re: A simple PIC api
Am 11.03.2015 14:46, schrieb Jochen Theodorou:
[...]
I really should write a PIC
On 03/11/2015 11:12 PM, Mark Roos wrote:
From Jochen
Do I also understand right, that your test for checking if the current
target is still valid is limited to only the receiver?
Well yes and no. In my case the test examines all of the arguments on
the stack and computes
an 'behavior'
Hi Jochen
uses basically guardWithTest, so the order of the handles is never
changed to for example trying the last one first or the one with the
most hits recently. Is it not worth the trouble?
In my case I always add the new gwt to the head of the chain. This fits
my use case where
the most
On 03/11/2015 11:12 PM, Mark Roos wrote:
Remi commented
I think you can adapt this code to implement what Mark want quite easily
I don't disagree that pics are easy to code, my premise is that with a
construct such I
I proposed the jvm would do a better job of optimizing. Especially
taking
From Jochen
Do I also understand right, that your test for checking if the current
target is still valid is limited to only the receiver?
Well yes and no. In my case the test examines all of the arguments on the
stack and computes
an 'behavior' reference. This reference is the head of a
Remi commented
I think you can adapt this code to implement what Mark want quite easily
I don't disagree that pics are easy to code, my premise is that with a
construct such I
I proposed the jvm would do a better job of optimizing. Especially taking
into account
invalidation, multi core
The overhead is negligible in my micro-benchmarks for monomorphic and
trimorphic call sites compared to regular Java virtual calls.
- Julien
On Tue, Mar 10, 2015, at 18:25, Mark Roos wrote:
From Julian
That being said performance of the PIC construct is very good in our
case.
Do
Hi Rémi,
I assume you want me to be more specific about my concerns on:
taking into account invalidation, multi core memory model and
volatile state.
My model is that I have a GWT chain, a cache, and a fallback which is
updating the chain, and more
than one core using the same
Hi Jochen
I have to think about yours some more but I thought I would share mine. I
condensed it to
make it easier to explain.
regards
mark
I extended callsite to hold a bunch of values one of which is the depth.
And my model for the cache is up to 10 chained GWTs after that I drop the
Am 09.03.2015 18:51, schrieb Mark Roos:
I was thinking about a generic pic, easy to use but flexible and came up
with the following concept api.
By passing the callsite and the testValue around with allowing an
optional pic update I can envision
this as a nice building block for several caching
Am 11.03.2015 14:46, schrieb Jochen Theodorou:
[...]
I really should write a PIC implementation for Groovy :(
actually picking up on that maybe you guys could give some advice
about how to structure a PIC internally.
How is it different from Rémi's construct?
https://code.google.com/p/jsr292-cookbook/source/browse/trunk/inlining-cache/src/jsr292/cookbook/icache/RT.java
(we use that pattern in Golo)
- Julien
On 09 Mar 2015, at 18:51, Mark Roos mr...@roos.com wrote:
I was thinking about a generic pic,
From Julian
How is it different from Rémi's construct?
Performance would be the hope.
My position has been that with a decent pic api the jvm would be able to
optimize the
pic to a few test/branch instructions for the large majority of callsites.
For your use case do you have the same
For your use case do you have the same situation as I do with 99%+ of call
sites having
less than 5 targets?
Yes.
We set the PIC-megamorphic threshold to 5 in Golo, in which case we degrade
to a stable but slower map-based + invoker dispatch.
That being said performance of the PIC
24 matches
Mail list logo
