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
Leopold Toetsch [EMAIL PROTECTED] writes:
Piers Cawley [EMAIL PROTECTED] wrote:
Leopold Toetsch [EMAIL PROTECTED] writes:
Csavetop becomes Cpushtopp 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
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 the vtable
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
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) = 317811 3.050051s
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/o COWed stacks.
Piers Cawley [EMAIL PROTECTED] wrote:
Leopold Toetsch [EMAIL PROTECTED] writes:
Csavetop becomes Cpushtopp 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
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
needs
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
pool for
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*);
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_
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
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
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 accummulated,
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 make sense
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
debatable
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 (and I
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 of pointers to
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 a
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.imc
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 is
: worth
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
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
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 the
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 aware of
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
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 like to
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)
Ok. First (and that
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
This idea involves two assumptions:
there are three kinds of people.
those that can count and the others ;)
~ibotty
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
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.
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 plain
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
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
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% slower.
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.
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 in
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, to the
two
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
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) They are:
1) A method cache. Which we need anyway, so this isn't
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,
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
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
pool
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
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-interpreter
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 or
It's always nice to have numbers when planning optimizations.
So I started fiddling with oofib.imc.
It seemed like we were spending a lot of time copying strings.
So I defined the method name strings once, in main,
$S3 = fibB
and replaced calls like
self.fibB(n2)
with
self.$S3(n2)
48 matches
Mail list logo
