On Tue, 2008-12-23 at 17:31 -0800, Will Coleda via RT wrote:
> 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
