The Perl 6 Summary for the week ending 20030112
... and we're back. Yup, it's summary time again. We'll dive straight in
with perl6-internals (as if you expected anything else).
More thoughts on DOD
Leopold Tötsch posted a test program showing the effects of PMC size and
timing of garbage collection and allocation and suggested ways of
improving the GC system based on the conclusions he drew from its
results. Leo, Dan and Mitchell N Charity discussed this further and
tried a few different approaches to try and improve performance (though
Mitchell did worry about premature optimization). Work in this area is
ongoing.
http://makeashorterlink.com/?Y3EB16513
The Perl 6 Parser
Dan asked about the current state of the Perl 6 parser, wanting to know
what was and wasn't implemented and wondered about adding the Perl 6
tests into the standard parrot test suite. Sean O'Rourke and Joseph F.
Ryan both gave a summaries of where things stood. Joseph also suggested
a few refactorings of the parser to deal with the fluidity of the
current spec (almost all the operators have changed symbols since the
parser was first written for instance).
http://makeashorterlink.com/?I6FB35513
LXR - Source code indexing
Last week I said that Robert Spier had 'started work on getting a
browseable, cross referenced version of the Parrot source up on
perl.org'. What actually happened was that Robert asked Zach Lipton to
do the work. This week Zach delivered the goods which, I must say, look
fabulous.
I'm sure that if someone were to extend LXR so it had a better
understanding of .pasm, .pmc, .ops and other special Parrot source types
then the community would be very grateful indeed. I know I would.
http://makeashorterlink.com/?K10C23513 -- Announcement
http://tinderbox.perl.org/lxr/parrot/source
Thoughts on infant mortality
Piers Cawley offered what he thought might be a new approach to dealing
with the infant mortality problem which got efficiently shot down by Leo
Tötsch. Which led to further discussion of possible answers, and it
looks like Leo's proposed solution involving a small amount of code
reordering and early anchoring will be the one that's tried next. All
being well it won't require walking the C stack and hardware register
set, which can only be a good thing.
Later on, Leo asked if it'd be okay to check in his work so far on
redoing the GC because he was up to 15 affected files and was starting
to worry about integration hell. Steve Fink wasn't sure about one of his
changes, so Leo checked everything else in.
http://makeashorterlink.com/?K41C21513
http://makeashorterlink.com/?S62C23513
Objects, finally (try 1)
Last week I mentioned that Leon Brocard's wishlist for the next Parrot
iteration included Objects. This week Dan posted his first draft of what
Parrot Objects would and wouldn't be able to do. The eleventh entry on
Dan's list (Objects are all orange) seemed to be custom made to please
Leon. There was a fair amount of discussion (of course), but the
consensus was positive.
http://makeashorterlink.com/?S13C31513
The benchmarking problem
Nicholas Clark crossposted to p5p and perl6-internals to discuss the
problems of benchmarking parrot against perl 5. One of parrot's aims is,
of course, to go faster than perl 5. The problem is, how do you measure
'faster'? Nicholas has been working on making perl 5 go faster and was
distressed to find out that using 'perlbench' a patch of his went 5%
faster, 1% slower, 0% and 1% faster, depending on what machine/compiler
combination he ran the benchmark on. Leo Tötsch commented that he'd
found performance varying by over 50% in a JIT test, depending on the
position of a loop in memory. Andreas Koenig commented that he'd come to
the conclusion that bugs in glibc meant that there was little point in
benchmarking Perl at all if it was built with a glibc older than version
2.3 (apparently malloc/free proved to be gloriously erratic...) I'm
afraid not much was actually resolved though.
http://makeashorterlink.com/?L64C22513
Meanwhile, in perl6-language
The discussion of Variable types vs Value types continued from the
previous week. Dan opined that Arrays weren't necessarily objects, which
brought forth squawks from Piers Cawley who pointed out that being able
to do:
class PersistentList is Array {
method FETCH ($index) {
...
}
...
}
would be much nicer than tying a value in the Perl 5ish fashion. Dan
reckoned that delegation would probably be enough which, IMHO seemed to
miss the point. Various other people chimed in to, essentially, tell Dan
that he was wrong, but I'm not sure Dan agreed with them.
Meanwhile, in a
