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
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%
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 files,
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
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-
PARROT is
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
a second
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_
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%106%
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
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
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
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
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
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 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
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
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 tasks.
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 scripts really do
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 doesn't
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,
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 some
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 [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 stacks, control stack
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 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
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
--- 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.)
However,
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
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 find
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 current
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
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 see
35 matches
Mail list logo
