Leopold Toetsch <[EMAIL PROTECTED]> writes:
> Piers Cawley <[EMAIL PROTECTED]> wrote:
>> Leopold Toetsch <[EMAIL PROTECTED]> writes:
>
>>> C becomes C if only P-registers are used. Saving only
>>> 3 or 5 registers isn't possible yet. We have no opcodes for that.
>
>> save Pn
>> save Pm
>
> Well
Piers Cawley wrote:
Leopold Toetsch <[EMAIL PROTECTED]> writes:
Out of interest, why do we have distinct register and user stacks?
User stack entries are typed and you save and restore one item per
operation. The register backing stores first took 32 registers of one
kind (now 16 or 32). To get
At 4:34 PM +0100 3/26/04, Leopold Toetsch wrote:
Dan Sugalski <[EMAIL PROTECTED]> wrote:
At 6:46 PM +0100 3/17/04, Leopold Toetsch wrote:
Or: after the 1st delegate lookup create a JITed stub
Which is swell, except for that pesky can't-guarantee-a-JIT thing... :)
I've running that now for the C
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> At 6:46 PM +0100 3/17/04, Leopold Toetsch wrote:
>>Or: after the 1st delegate lookup create a JITed stub
> Which is swell, except for that pesky can't-guarantee-a-JIT thing... :)
I've running that now for the C<__init> call. In the absence of
C<__init> t
Piers Cawley <[EMAIL PROTECTED]> wrote:
> How hard would it be to stick all continuations onto a 'weak'
> continuation stack (not seen by DOD) then, during DOD, mark the freed
> continuations (or the live ones).
The current code is much simpler. s.
void add_to_retc_free_list(Parrot_Interp, PMC*)
Leopold Toetsch <[EMAIL PROTECTED]> writes:
> Dan Sugalski <[EMAIL PROTECTED]> wrote:
>> Okay, as I see it there are two big things that we can do to speed
>> objects up. (Well, besides speeding up the creation of continuation
>> PMCs, which I am, at the moment, sorely tempted to put in a special
Piers Cawley <[EMAIL PROTECTED]> wrote:
> Leopold Toetsch <[EMAIL PROTECTED]> writes:
>> And finally: I really don't know, if a Continuation needs just pointers
>> to the stacks (and to which) or (COWed) copies (to which).
> If a 'single object per stack frame' approah, the continuation only
> ne
Piers Cawley <[EMAIL PROTECTED]> wrote:
> Leopold Toetsch <[EMAIL PROTECTED]> writes:
>> C becomes C if only P-registers are used. Saving only
>> 3 or 5 registers isn't possible yet. We have no opcodes for that.
> save Pn
> save Pm
Well, these are already used for pushing items onto the user
Leopold Toetsch <[EMAIL PROTECTED]> writes:
> Piers Cawley <[EMAIL PROTECTED]> wrote:
>> Leopold Toetsch <[EMAIL PROTECTED]> writes:
>
>>> You seem to be mixing up different issues with that statement. Using
>>> plain Continuation PMCs for returning just from subroutines was dead
>>> slow, w or w/
Leopold Toetsch <[EMAIL PROTECTED]> writes:
> Piers Cawley <[EMAIL PROTECTED]> wrote:
>
>> The thing is, 'pushtop' is almost certainly the wrong thing to do. You
>> should only push the registers you care about onto the register
>> stacks.
>
> Yes:
>
> $ time parrot -j oofib.imc
> fib(28) = 31781
Piers Cawley <[EMAIL PROTECTED]> wrote:
> The thing is, 'pushtop' is almost certainly the wrong thing to do. You
> should only push the registers you care about onto the register
> stacks.
Yes:
$ time parrot -j oofib.imc
fib(28) = 317811 3.050051s
real0m3.077s
$ time parrot -j -Oc oofib.
Piers Cawley <[EMAIL PROTECTED]> wrote:
> Leopold Toetsch <[EMAIL PROTECTED]> writes:
>> You seem to be mixing up different issues with that statement. Using
>> plain Continuation PMCs for returning just from subroutines was dead
>> slow, w or w/o COWed stacks.
> But when a Continuation is simply
Luke Palmer <[EMAIL PROTECTED]> writes:
> Piers Cawley writes:
>> > You seem to be mixing up different issues with that statement. Using
>> > plain Continuation PMCs for returning just from subroutines was dead
>> > slow, w or w/o COWed stacks.
>>
>> But when a Continuation is simply a collection
Piers Cawley writes:
> > You seem to be mixing up different issues with that statement. Using
> > plain Continuation PMCs for returning just from subroutines was dead
> > slow, w or w/o COWed stacks.
>
> But when a Continuation is simply a collection of pointers to the tops
> of the various stacks
Leopold Toetsch <[EMAIL PROTECTED]> writes:
> Piers Cawley <[EMAIL PROTECTED]> wrote:
>
>> ... I strongly advocate rejigging the
>> stacks so that one stack frame = 1 stacked thing + 1 link to the next
>> thing in the chain.
>
> Let's do things in correct order. First was method cache. 2nd the
> d
Matt Fowles <[EMAIL PROTECTED]> writes:
> All~
>
> Piers Cawley wrote:
>> I argue that we have the problems we do (incorrect behaviour of
>> continuations, horrible allocation performance) because we chose the
>> wrong optimization in the first place. The stack optimizations that are
>> in place m
Piers Cawley <[EMAIL PROTECTED]> wrote:
> ... I strongly advocate rejigging the
> stacks so that one stack frame = 1 stacked thing + 1 link to the next
> thing in the chain.
Let's do things in correct order. First was method cache. 2nd the
debatable return continuation recycling. Both accummulate
All~
Piers Cawley wrote:
I argue that we have the problems we do (incorrect behaviour of
continuations, horrible allocation performance) because we chose the
wrong optimization in the first place. The stack optimizations that are
in place make sense when you don't have continuations, but once you
Mitchell N Charity <[EMAIL PROTECTED]> wrote:
> And RetContinuation segfaulting when used twice becomes acceptable
> behavior under this model. Sigh.
No. Segfaults aren't accetable. I've already outlined a scheme to
disable this optimization. It's currently not done but its simple: If
ever a Con
Having already argued against it, here is an argument that reusing
RetContinuations is acceptable.
Parrot is not a side-effect free language. So _every_ continuation
goes out with a social contract.
Something like "Use this continuation once, great, but use it twice,
and things are _so_ undefine
Larry Wall wrote:
Well, Leo asked for hints, and I basically said Perl has no problem
sending them. If Parrot has a problem receiving them, that's another
matter. :-)
When there are now hits from languages like Ruby or Smalltalk, then one
single flag will do it: If ever a real Continuation is cr
At 08:57 AM 3/19/2004 +0100, Leopold Toetsch wrote:
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> At 10:38 PM +0100 3/18/04, Leopold Toetsch wrote:
>>
>>Which brings up again my warnocked question: How can return
>>continuations get reused?
> Works like this. (No pasm, but it should be obvious)
I was a
On Sat, Mar 20, 2004 at 11:18:08AM -0500, Dan Sugalski wrote:
: At 12:44 PM -0800 3/19/04, Larry Wall wrote:
: >On Fri, Mar 19, 2004 at 08:57:28AM +0100, Leopold Toetsch wrote:
: >: What's the usage of Continuations from HLLs point of view? Can we get
: >: some hints, what is intended?
: >
: >From
At 12:44 PM -0800 3/19/04, Larry Wall wrote:
On Fri, Mar 19, 2004 at 08:57:28AM +0100, Leopold Toetsch wrote:
: What's the usage of Continuations from HLLs point of view? Can we get
: some hints, what is intended?
From the standpoint of Perl 6, I hope to hide continuations far, far
away in a galaxy
Piers Cawley <[EMAIL PROTECTED]> wrote:
> I argue that we have the problems we do (incorrect behaviour of
> continuations, horrible allocation performance) because we chose the
> wrong optimization in the first place. The stack optimizations that are
> in place make sense when you don't have conti
Leopold Toetsch <[EMAIL PROTECTED]> writes:
> Larry Wall <[EMAIL PROTECTED]> wrote:
>> On Fri, Mar 19, 2004 at 08:57:28AM +0100, Leopold Toetsch wrote:
>
>>: I'd like to have, if possible a clear indication: that's a plain
>>: function or method call and this is not. I think the possible speedup i
Larry Wall <[EMAIL PROTECTED]> wrote:
> On Fri, Mar 19, 2004 at 08:57:28AM +0100, Leopold Toetsch wrote:
>: I'd like to have, if possible a clear indication: that's a plain
>: function or method call and this is not. I think the possible speedup is
>: worth the effort.
> I have no problem with "p
Larry Wall wrote:
We can certainly make it the default that a routine is not going to
do anything fancy with continuations unless it is explicitly declared
to allow it. As to what that declaration should be, I have no idea.
Probably just a trait that says, "is continuationalizableish" or
some such
On Fri, Mar 19, 2004 at 08:57:28AM +0100, Leopold Toetsch wrote:
: What's the usage of Continuations from HLLs point of view? Can we get
: some hints, what is intended?
>From the standpoint of Perl 6, I hope to hide continuations far, far
away in a galaxy long ago. No wait, wrong movie...
We can
> This idea involves two assumptions:
there are three kinds of people.
those that can count and the others ;)
~ibotty
I may have a possible solution. Disclaimer: I do not really understand
continuations, so I may be completely wrong.
This idea involves two assumptions:
1. Most Parrot code will not use continuations except for returning.
(There will be a significant efficiency loss otherwise.)
2. The most ex
Leopold Toetsch <[EMAIL PROTECTED]> writes:
> Dan Sugalski <[EMAIL PROTECTED]> wrote:
>> At 10:38 PM +0100 3/18/04, Leopold Toetsch wrote:
>>>
>>>Which brings up again my warnocked question: How can return
>>>continuations get reused?
>
>> Works like this. (No pasm, but it should be obvious)
>
> O
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> At 10:38 PM +0100 3/18/04, Leopold Toetsch wrote:
>>
>>Which brings up again my warnocked question: How can return
>>continuations get reused?
> Works like this. (No pasm, but it should be obvious)
Ok. First (and that applies to Jens example too), I'd lik
oops, I renamed the wrong file...
This is the correct example.
jens
.pcc_sub _main:
newsub P0, .Sub, _foo
newsub P1, .RetContinuation, _ret
invoke
_ret:
print "returned!\n"
set P0, P2
invokecc
print "after 2nd invoke\n"
end
.pcc_sub _foo:
print "foo start\n"
Hi,
On Thursday 18 March 2004 22:38, Leopold Toetsch wrote:
> Dan Sugalski <[EMAIL PROTECTED]> wrote:
> > At 4:10 PM -0500 3/18/04, Mitchell N Charity wrote:
> >>It seemed nontrivial to reduce the number return continuation pmc's
> >>used in oofib.imc. So I instead added an _extra_, unused one, t
At 10:38 PM +0100 3/18/04, Leopold Toetsch wrote:
Dan Sugalski <[EMAIL PROTECTED]> wrote:
At 4:10 PM -0500 3/18/04, Mitchell N Charity wrote:
It seemed nontrivial to reduce the number return continuation pmc's
used in oofib.imc. So I instead added an _extra_, unused one, to the
two already used i
>Which suggests return continuation pmc driven memory management costs
>(gc and allocation) are currently a major, perhaps even dominant,
>factor in method invocation speed.
Yow. Okay, thanks. That means it's time to dive into the think tank
and see what we can do about that.
Noth
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> At 4:10 PM -0500 3/18/04, Mitchell N Charity wrote:
>>It seemed nontrivial to reduce the number return continuation pmc's
>>used in oofib.imc. So I instead added an _extra_, unused one, to the
>>two already used in each fib method.
>>
>>Parrot ran 30% slow
At 4:10 PM -0500 3/18/04, Mitchell N Charity wrote:
It seemed nontrivial to reduce the number return continuation pmc's
used in oofib.imc. So I instead added an _extra_, unused one, to the
two already used in each fib method.
Parrot ran 30% slower. (Optimized, unoptimized, and jit)
Which suggest
It seemed nontrivial to reduce the number return continuation pmc's
used in oofib.imc. So I instead added an _extra_, unused one, to the
two already used in each fib method.
Parrot ran 30% slower. (Optimized, unoptimized, and jit)
Which suggests return continuation pmc driven memory management
On Wed, Mar 17, 2004 at 12:06:35PM -0500, Sterling Hughes wrote:
: >
: >That's all fine and good, and the generic method cache will help here.
: >However... we can do better. What I'm thinking of is caching the
: >actual found method PMC pointer in the class somewhere (hanging off
: >the vtable
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> At 6:46 PM +0100 3/17/04, Leopold Toetsch wrote:
>>
>>I though about that already. Returncontinuations created via the *cc
>>opcode variants are created in the opcode and used exactly once just for
>>returning from the sub. So I'd do for these a per-interp
That's all fine and good, and the generic method cache will help here.
However... we can do better. What I'm thinking of is caching the
actual found method PMC pointer in the class somewhere (hanging off
the vtable or in the class' attributes or something) such that we
don't actually have to *d
At 6:46 PM +0100 3/17/04, Leopold Toetsch wrote:
Dan Sugalski <[EMAIL PROTECTED]> wrote:
Okay, as I see it there are two big things that we can do to speed
objects up. (Well, besides speeding up the creation of continuation
PMCs, which I am, at the moment, sorely tempted to put in a special
poo
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> Okay, as I see it there are two big things that we can do to speed
> objects up. (Well, besides speeding up the creation of continuation
> PMCs, which I am, at the moment, sorely tempted to put in a special
> pool for fast allocation)
I though about that a
Might be worth looking at Smalltalk papers too - they've been doing objects
forever. If I remember correctly, some smalltalks have an interesting form
of caching: they call the last thing the call resolved to, and redispatch as
necessary. So rather than looking things up before every call, you
46 matches
Mail list logo
