[perl #60048] CGP Does Not Work with PCC Runcore Reentry
Chromatic
# Please include the string: [perl #60048]
# in the subject line of all future correspondence about this issue.
# <URL: http://rt.perl.org/rt3/Ticket/Display.html?id=60048 >
Several tests fail with the CGP runcore (parrot -C) when multidispatch
re-enters bytecode -- in specific, anything that calls into src/pic.c from
Parrot_pcc_invoke_sub_from_sig_object causes failures.
The problem appears to be that CGP's PIC tries to poke into the bytecode
directly to find get_params and similar opcodes, while parameter-passing
information is in a context after Parrot_pcc_invoke_sub_from_sig_object.
One workaround is to enforce the use of the normal runcore only for calls back
into Parrot from Parrot_pcc_invoke_sub_from_sig_object, but that's just a
workaround. A better solution is to fix the PIC code to look in the
appropriate place in the context for return values. That seems like a good
task for the calling conventions branch.
-- c
Allison Randal
>
> Several tests fail with the CGP runcore (parrot -C) when multidispatch
> re-enters bytecode -- in specific, anything that calls into src/pic.c from
> Parrot_pcc_invoke_sub_from_sig_object causes failures.
>
> The problem appears to be that CGP's PIC tries to poke into the bytecode
> directly to find get_params and similar opcodes, while parameter-passing
> information is in a context after Parrot_pcc_invoke_sub_from_sig_object.
>
> One workaround is to enforce the use of the normal runcore only for calls back
> into Parrot from Parrot_pcc_invoke_sub_from_sig_object, but that's just a
> workaround. A better solution is to fix the PIC code to look in the
> appropriate place in the context for return values. That seems like a good
> task for the calling conventions branch.
I've been debating whether src/pic.c should be removed entirely. It's a
swodge of code that only gives a tiny speedup for 4 opcodes: 'infix',
'get_params', 'set_args', and 'set_returns'. And the 'infix' opcode has
been deprecated and will be removed in the calling conventions branch
(it was a nasty hack for the old MMD system). And it's not even really
the right speedup for 'get_params', 'set_args', and 'set_returns'.
There are also a pile of old, nasty MMD functions that should be deleted
and are only called from src/pic.c.
Allison
Geoffrey Broadwell
> chromatic mentioned on #parrot that if we remove PIC, we're going to break all the
> predereferenced runcores. After some discussion, this probably means ripping out:
>
> 16:42 <@chromatic> Everything other than the default core, the nearly-useless
> profiling core, and the gc-debug core.
>
> So, I vote we update the deprecation notice in trunk to include the runcores (which means
> delaying the removal until post-0.9.0), and then I can continue the mayhem and destruction
> that has begun in the branch.
>
> Comments?
This is certainly a biggie, but I believe we've been doing this on a
smaller scale more and more lately: removing functionality and/or
optimizations that we don't have the spare cycles to support.
On the one hand this is a good thing -- we'll actually hit 1.0 in a few
months. I'm all for getting that wider audience.
On the other hand, I'm somewhat concerned that Parrot 1.0 will either
itself be rather slow, or will architecturally force HLL implementations
to be slow. While looking for the IRC discussion mentioned by Coke, I
found the following interchange (slightly edited for clarity):
<donaldh> Hmm. Bad memory profile for rakudo. A piece of PIR that runs
a SQLite query and prints ~18000 rows tops out at 6 MB when
run with -G. The equivalent in Rakudo tops out at 1.6GB
<chromatic> PGE/PCT/Rakudo uses more STRINGs and PMCs. If you disable
garbage collection, Parrot won't reuse them.
<donaldh> Sure. I'm just realising how much pressure Rakudo is putting
on GC.
<pmichaud> rakudo is somewhat constrained by the architecture Parrot
provides, unfortunately.
This interchange raised a flag for me. Am I incorrect in seeing this as
a problem? Since Parrot 1.0 is supposed to be the stable interface for
HLL implementors to aim for, I'd hate for that interface to be very
suboptimal, performance-wise, even if it is technically sufficient to
get things to *work*. Or is the plan that Parrot 1.5/2.0 are going to
include the needed performance and functional improvements as part of
the push to production?
-'f
Chromatic
> On the other hand, I'm somewhat concerned that Parrot 1.0 will either
> itself be rather slow, or will architecturally force HLL implementations
> to be slow. While looking for the IRC discussion mentioned by Coke, I
> found the following interchange (slightly edited for clarity):
>
> <donaldh> Hmm. Bad memory profile for rakudo. A piece of PIR that runs
> a SQLite query and prints ~18000 rows tops out at 6 MB when
> run with -G. The equivalent in Rakudo tops out at 1.6GB
> <chromatic> PGE/PCT/Rakudo uses more STRINGs and PMCs. If you disable
> garbage collection, Parrot won't reuse them.
> <donaldh> Sure. I'm just realising how much pressure Rakudo is putting
> on GC.
> <pmichaud> rakudo is somewhat constrained by the architecture Parrot
> provides, unfortunately.
>
> This interchange raised a flag for me. Am I incorrect in seeing this as
> a problem?
Yes and no.
That has nothing to do with runcores. The number of GCables allocated is,
more or less, constant between runcores.
Ideally, the PIR emitted from Rakudo would be require just about as many
GCables as hand-written PIR, but if you want to compare that, you're going to
have to precompile Perl 6 source to PIR, so that you're not running PGE and
PCT and seeing all of the memory they use as well. Compare like to like.
I'm not pleased about performance numbers right now either, but the known
problems are the multiple calling conventions conversions to compare an
Integer PMC with anything else through MMD and our garbage collector. (I
suspect Parrot's calling conventions are likewise full of strange decisions.)
You (or anyone else) is very much free to dig into that.
If removing poorly-written, undertested, undocumented, experimental code
that's never worked quite right helps us concentrate on the important things,
I'm all for it.
-- c
Chromatic
> CGP is too important to be deprecated over something as small as this.
If it were important, we'd test it and maintain the code. We don't, ergo....
-- c
James Keenan via RT
> On Thu Jan 29 06:15:28 2009, Whiteknight wrote:
> >
> > has the remove_pic branch landed yet?
>
>
> Well, it's still an active branch in SVN. So I would guess not.
Per discussion on the mailing list, we're removing the remove_pic branch
(r41287). Whiteknight already has this ticket.
kid51