[perl #60048] [BUG] [MMD] CGP Does Not Work with PCC Runcore Reentry

[chromatic]

On Tuesday 23 December 2008 18:47:23 Geoffrey Broadwell wrote:

> 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