Piers Cawley <[EMAIL PROTECTED]> wrote:
> So why does the generated pasm work where the PIR doesn't?
The generated PASM is all one compilation unit. Your (local) labels are
fixed up properly. In your PIR code you had local labels (w/o)
underscore refering to different compilation units.
> I can
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
Piers Cawley <[EMAIL PROTECTED]> wrote:
[ Continuation usage ]
> Dan? Could you mandate this? Please?
As long as there are no usage patterns that precisely describe how
Continuations should work and how a PIR syntax could look like, there is
little to mandate ;)
> Preserving self and the curren
> I have quite a few fonts, the only one I can find where | is a broken
> bar is "Terminal", a font for DOS programs that uses the cp437
> charset, which is incompatable with latin1 (? and ? are AE and AF
> instead of AB and BB) and it dosen't even havI have quite a few fonts,
> the only one I can
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
Goplat wrote:
I have quite a few fonts, the only one I can find where | is a broken bar is
"Terminal", a font for DOS programs that uses the cp437 charset, which is
incompatable with latin1 (« and » are AE and AF instead of AB and BB) and it
dosen't even have a ¦. So, it dosen't seem like a proble
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
--- Juerd <[EMAIL PROTECTED]> wrote:
> Kara Perlistoj,
>
> the zip operator is a useful one. I like it a lot. But I've been writing
> zip() all the time, even though I think an infix operator is nicer. (Not
> for for though, because you also have commas in the pointy sub's
> parameter list.)
>
>
Kara Perlistoj,
the zip operator is a useful one. I like it a lot. But I've been writing
zip() all the time, even though I think an infix operator is nicer. (Not
for for though, because you also have commas in the pointy sub's
parameter list.)
However, the broken bar is in my opinion a bad choice
Brent 'Dax' Royal-Gordon <[EMAIL PROTECTED]> writes:
> Other times, we add lots of new features, and then stop to test them
> and find they're incredibly slow. (That's objects right now.)
In objects' defence, I'd just like to say that they are rather lovely.
Piers Cawley <[EMAIL PROTECTED]> writes:
> Leopold Toetsch <[EMAIL PROTECTED]> writes:
>
>> Piers Cawley <[EMAIL PROTECTED]> wrote:
>>> So, I'm trying to get my head 'round parrot's continuations. It's my
>>> understanding that, at creation time, a Continuation closes over the
>>> current user sta
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
Leopold Toetsch <[EMAIL PROTECTED]> writes:
> Piers Cawley <[EMAIL PROTECTED]> wrote:
>> So, I'm trying to get my head 'round parrot's continuations. It's my
>> understanding that, at creation time, a Continuation closes over the
>> current user stacks, control stack and lexical pad (and possibly
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
Paolo Molaro <[EMAIL PROTECTED]> wrote:
> [...]
>> > oofib 100%144%132%240%212%140%136%
> oofib.imc seems to use int registers for the arguments and the
> calculations,
That's true. The brain-builtin optimizer took care of that ;) While the
code of course is valid, it d
Paolo Molaro wrote:
> On 03/21/04 Jarkko Hietaniemi wrote:
> [...]
>
>>>oofib 100%144%132%240%212%140%136%
>
> [...]
>
>>That being said, people more conversant than me in Python/Ruby
>>(or Parrot) are welcome to carefully compare the scripts to verify that
>>the scrip
On 03/21/04 Jarkko Hietaniemi wrote:
[...]
> > oofib 100%144%132%240%212%140%136%
[...]
> That being said, people more conversant than me in Python/Ruby
> (or Parrot) are welcome to carefully compare the scripts to verify that
> the scripts really do implement the same tas
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 wrote:
Further optimization
will be seen as premature optimization. Our focus will
shift to making parrot actually work.
If we never optimize, we won't have the speed to run real-world
programs. But if all we do is optimize, we won't have the features to
run real-world program
Piers Cawley <[EMAIL PROTECTED]> wrote:
> So, I'm trying to get my head 'round parrot's continuations. It's my
> understanding that, at creation time, a Continuation closes over the
> current user stacks, control stack and lexical pad (and possibly some
> other stuff but those'll do for now).
Yes
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
Mitchell N Charity <[EMAIL PROTECTED]> wrote:
> ... Our focus will
> shift to making parrot actually work. To giving it
> working exceptions, io, embeddablility, and so on.
> Given Leo's numbers, it seemed a possibility worth suggesting.
> I can certainly imagine other policies. Like focusing on
I don't know about the continuation stuff, but you can't assume that
running imc --> pasm --> exec does the same thing as imc --> exec. I
ran into that before, and I don't think its going to get fixed until
the new imcc lands, at which point old-school pasm might even be
gone (although I don't know
Someday we will set aside our optimization focus.
Our architectural validation probe will be complete.
We will have established that yes, the parrot design
can support the required speed. Further optimization
will be seen as premature optimization. Our focus will
shift to making parrot actually wo
So, I'm trying to get my head 'round parrot's continuations. It's my
understanding that, at creation time, a Continuation closes over the
current user stacks, control stack and lexical pad (and possibly some
other stuff but those'll do for now).
So, it seems to me that the following code should p
Leopold Toetsch wrote:
> $ perl tools/dev/parrotbench.pl -c=parrotbench.conf -b='^oo'
> Numbers are relative to the first one. (lower is better)
> parrotj parrot parrotC perl-th perlpython ruby
> oo1 100%110%107%151%128%81% 110%
> oo2 100%109%1
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
Jarkko Hietaniemi <[EMAIL PROTECTED]> wrote:
> My Parrot, Python, or Ruby-fu are not as strong as they should be
> (caveat applicator), but here goes nothing: I added some simple oo
> benchmarks for "getters" and "setters".
And here are recent results (with the Patch WRT classoffset I checked in
On Sun, 2004-03-21 at 04:49, James Mastros wrote:
> Gerald E Butler wrote:
> > I've been investigating the possibility of creating a MACHINE
> > DESCRIPTION (aka BACK-END) for GCC to target PARROT. My thinking is
> > this: If a satisfactory GCC back-end targeting PARROT is created -and-
> > PAR
Mitchell N Charity <[EMAIL PROTECTED]> wrote:
> I find the following code sefaults in gc, around N=18.
> What am I overlooking...??
The code looks fine. It seems to be a problem with marking the register
stacks.
(gdb) bac
#0 0x080cba79 in pobject_lives (interpreter=0x82555b0, obj=0x1)
at sr
My Parrot, Python, or Ruby-fu are not as strong as they should be
(caveat applicator), but here goes nothing: I added some simple oo
benchmarks for "getters" and "setters". In the attached .tgz (destined
for examples/benchmarks) the included oon.txt explains what the heck are
all the different fil
Albeit its a bit dangerous to reuse return continuations, I couldn't
resist. Here is the reason why:
$ perl tools/dev/parrotbench.pl -c=parrotbench.conf -b=^oo
Numbers are relative to the first one. (lower is better)
parrotj parrot parrotC perl-th perlpython ruby
oo1 100%107
Gerald E Butler wrote:
I've been investigating the possibility of creating a MACHINE
DESCRIPTION (aka BACK-END) for GCC to target PARROT. My thinking is
this: If a satisfactory GCC back-end targeting PARROT is created -and-
PARROT is efficient enough (which from reading the documentation thus
f
35 matches
Mail list logo
