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
