Re: This week's summary
Piers Cawley <[EMAIL PROTECTED]> wrote: > More CPS shenanigans > I get the strong feeling that Leo Tötsch isn't entirely happy with the > new Continuation Passing Style regime. No, I'm really happy with CPS. Restoring the whole context by invoke'ing the return continuation is a very elegant and efficient way to do it, not speaking from tail calls ... > He's worried that the P6C tests > break, ... albeit this is still an issue. Nobody answered, if we need another Sub class implementing the old invoke/ret scheme ... > ... and that CPS subs are some 3 times slower for calling the sub. ... while this is solved. Jonathans patch that went in originally had this bad performance. But with separating the Sub/Continuation setup from the actual subroutine call (which amongst other things my patches did), performance is back again at the old level. In fact the current CPS implementation is faster then the old invoke/ret scheme. I estimate the final speed, when all needed context things are saved, to be about the same as invoke/ret w/o much context saving. > Whee! My first anniversary! Congrats and thanks for your great summaries. leo
Re: This week's summary
On Tue, 24 Jun 2003, Leopold Toetsch wrote: > Piers Cawley <[EMAIL PROTECTED]> wrote: > > He's worried that the P6C tests > > break, > > ... albeit this is still an issue. Nobody answered, if we need another > Sub class implementing the old invoke/ret scheme ... I'd say "no". P6C is now compiling to an obsolete architecture. While we should all step back and be impressed at how well Intel has maintained backward compatibility in the x86, there's no particular reason we should do so ourselves. Rather, someone (me) needs to port P6C to the new machine. > > Whee! My first anniversary! > > Congrats and thanks for your great summaries. Seconded. /s
Re: This week's summary
On Tue, Jun 24, 2003 at 06:14:52AM -0700, Sean O'Rourke wrote: > On Tue, 24 Jun 2003, Leopold Toetsch wrote: > > > > [...] Nobody answered, if we need another > > Sub class implementing the old invoke/ret scheme ... > > I'd say "no". P6C is now compiling to an obsolete architecture. > While we should all step back and be impressed at how well Intel has > maintained backward compatibility in the x86, there's no particular > reason we should do so ourselves. Rather, someone (me) needs to port > P6C to the new machine. /me shows ignorance yet again. For those of us who are not hardware types...what is "the new machine"? The Itanium? Does that really have enough market penetration at this point to be a worthy target? Or is the idea that, by the time Parrot is finished, it WILL have massive market penetration? > > > Piers Cawley <[EMAIL PROTECTED]> wrote: > > > Whee! My first anniversary! > > > > Congrats and thanks for your great summaries. > > Seconded. Thirded. Although the doings of the internals list fascinate me, they are usually totally over my head, so I long ago unsub'd. It's great to be able to follow along via the summaries. --Dks
Re: This week's summary
On Tue, Jun 24, 2003 at 07:58:32AM -0700, David Storrs wrote: > /me shows ignorance yet again. > > For those of us who are not hardware types...what is "the new > machine"? The Itanium? Does that really have enough market > penetration at this point to be a worthy target? Or is the idea that, > by the time Parrot is finished, it WILL have massive market > penetration? The machine they're talking about is parrot. A virtual machine, but a machine none the less. The "new machine" is the new calling conventions recently implemented. andrew -- Aquarius: (Jan. 20 - Feb. 18) Heartbreak is in the stars for you this week when the woman of your dreams confesses she cannot love a man with such an unholy appetite for pie.
Re: This week's summary
On Tue, Jun 24, 2003 at 04:04:29PM +0100, Andrew Wilson wrote: > On Tue, Jun 24, 2003 at 07:58:32AM -0700, David Storrs wrote: > > /me shows ignorance yet again. > > > > For those of us who are not hardware types...what is "the new > > machine"? The Itanium? Does that really have enough market > > The machine they're talking about is parrot. A virtual machine, but a > machine none the less. The "new machine" is the new calling conventions > recently implemented. > > andrew Ah. Of course; I got confused by the x86 references and took them too literally. Thanks for setting me straight. --Dks
Lightweight Object Existance Proxies
This idea seems to fit in a lot of places. It's more of a design
pattern than anything else, but one I think P6 can use to good effect
in the "standard library".
Lightweight Object Existance (LOE) Proxies
An LOE proxy is an object that proxies for another, heavier, object
that (maybe) doesn't exist.
The idea is that when "creating" an object, either from scratch or
rehydrating/thawing an object stored offline or serializing an object
stored on a separate node, is expensive or undefined, an LOE proxy can
be used.
This proxy could be used when a network of objects is being
instantiated, when a particularly smart garbage collector knew how to
push unused but persistent objects out of memory, and by some other,
sleazier, code (below).
It occurred to me yesterday, while reading DDJ, that this is a good way
to implement a ThreadLocal storage variable:
A thread will have its own scope. This behaves as you expect a scope to
behave with respect to other thread scopes, and serves as a divider
between the lexical scope of subs entered in the thread and scopes
active for this thread because they were entered in the parent thread
before the current thread was spawned.
An object declared C would simply create a shared
reference to an anonymous object in the threads scratchpad, and use
run-time resolution.
Thus:
sub A {
...
}
my $a is ThreadLocal;
for (0..10) {
thread &A;
}
Each thread would share the global scope, and behind the global scope
the zero-thread scope (which contains nothing).
The C call would create a thread scope, which would then be
overlain with a subroutine scope for sub A.
Scope stack:
Thread[Main]
::Global
Thread[0..10]
::A
The ThreadLocal object lives in ::Global context. If it were a valid
object that had to implement its own semantics, it would likely be slow
(& buggy!) unless there were also some sort of direct "copy on access"
support implemented in core (and perhaps slow even then).
But if the object were itself an LOE proxy, the proxy could dynamically
instantiate the new object and dispatch appropriately:
class ThreadLocal {
has%.thread2client;
method DISPATCH($self: $method, @args)
{
my $t = callcc($caller.cc, get_current_thread);
my $client = %.thread2client{$t} //= new $.class;
SUPER.DISPATCH($client, $method, @args);
}
}
=Austin
Re: object initialisers
On Thu, Jun 12, 2003 at 04:02:50PM +0200, Rafael Garcia-Suarez wrote:
> Nicholas Clark wrote:
> >
> > class Foo {
> > ...
> > std::size_t spare = 0
> > std::size_t allocate = 4096
> > std::size_t min_readline = 80
> >
> > and have the compiler know that if I specify a member initialiser in my
> > my constructor, then that should be used, otherwise to default to using
> > the value I say. (To avoid the inevitable search/replace if I want to
> > change that value)
>
> That's actually valid Java syntax (modulo a trailing C<;>). The default
> value can be any expression (as long as it doesn't involve a reference
> to the object being constructed, IIRC).
>
> In fact Java provides a notion of instance initialiser, run before
> any specific constructor you're invoking, that initialises such fields,
> and may run other code.
This wasn't quite what I was thinking about. I was more for typing
laziness (and avoiding cut&paste) - I'd like a default for the
instance initialiser, but only to be used (by the compiler's code
generator) if I don't specify a specific initialiser in that (overloaded)
constructor.
But currently I'm having my mind warped by C++, so I may not be sane.
Nicholas Clark
Re: object initialisers
--- Nicholas Clark <[EMAIL PROTECTED]> wrote:
> This wasn't quite what I was thinking about. I was more for typing
> laziness (and avoiding cut&paste) - I'd like a default for the
> instance initialiser, but only to be used (by the compiler's code
> generator) if I don't specify a specific initialiser in that
> (overloaded) constructor.
Would that be:
class X {
has $.attr1;
has $.attr2;
method new($class: ?$.attr1, ?$.attr2) {
$.attr1 //= 0; # Default value
$.attr2 //= 0; # Default value
}
}
Where the $.attr1 syntax is the already-discussed
"quick-constructor-assign" shortcut, and the //= allows you to specify
a default if the arglist failed?
=Austin
