Welcome back to another episode in the ongoing saga that is the Perl 6 development process (or at least my attempt to describe it).
We kick off with perl6-internals.
Piers Cawley attempted to describe tail call optimizations, why they
were a good thing and why a caller saves calling convention made such
optimizations easier (possible?). He wondered if he hadn't just
succeeded in muddying the waters still further. Jerome Vouillon
appeared to understand what Piers was going on about and pointed out
that a caller saves scheme also helps with exception
handling. Benjamin Goldberg wondered about Perl 5's
semantics which can be looked at as a 'sort of' tail call (except you
don't actually get much of an optimization with Perl 5 as it stands)
and proposed a callee saves scheme for doing tail call optimization
which didn't optimize away an unnecessary pair of save/restores. Dan
pointed out that, while
goto &func (which is sort of like tail call
optimization in Perl 5) would have to be supported, tail call
optimization made more sense if you didn't have to use any special
syntax to make use of it.
David (Cuny?) wondered how he could determine the data type of an
arbitrary PMC and whether there were any pre-built Windows binaries of
Parrot available. Leon Brocard pointed him at the
in answer to the first question but punted on the second. Leo
Tötsch also pointed at
typeof. David noted that it didn't
seem to be available in his 0.0.9 installation and was recommended to
use the CVS version, and discussion drifted toward wondering when
Parrot 0.1.0 would see the light of day. (Not before at least one of
either objects or exceptions is implemented apparently).
Nobody answered the 'pre built Windows binary' part of David's question.
In last week's summary I mentioned that Sean O'Rourke had suggested getting IMCC to store a control flow graph in bytecode, which the JIT could use to optimize things more effectively. Sean read this and pointed out that it wasn't his idea but was actually an area of active research and gave a pointer to some information. He also pointed to a USENIX paper which discussed adding a full data-flow compiler into a JVM which could then generate code that ran faster than a lightweight JIT, especially for long-running programs. Sean's original link was to a subscription only site but Jason 'Research wants to be free' Gloudon found a public version of the paper. Dan was fascinated, but was worried about availability of engineering time, not wishing to presume on Leo, Daniel and everyone who's done JIT work.
Dan said that he'd 'rather have a lower-overhead JIT with a win for shorter programs than a high-overhead one with a win for long-running programs'. Leo pointed out that, at the moment we already have a high overhead JIT with most of the cost paid at load time and showed some of these costs. Dan and Leo then discussed what kind of metadata would be needed from IMCC (or some external tool) in order to improve matters.
Meanwhile, the original 'Using IMCC as JIT optimizer' thread continued as Leo committed some more changes both to code and to the documentation in jit.pod. The new version of the JIT optimizing IMCC should be platform independent and apparently runs 95% of Parrot's tests on an i386.
Phil Hassey wondered why we even had a set number of registers in the JVM in the first place. He wondered if it would be possible to have each block of code declare 'I need 12 registers for this bloc' and let the JIT system do the appropriate register spilling magic with the system registers. Leo said that this is approximately what the JIT optimizer does at the moment and outlined some of the problems associated with it.
Angel Faus had some questions and suggestions about the optimization approach that Leo was taking, with particular reference to the amount of copies to and from memory and proposed an efficient way forward. Nicholas Clark wondered if some of Angel's suggestions mean that imc (IMCC source code) had now usurped the role of parrot bytecode and muttered something about premature optimization and the lack of objects, exceptions, IO or a Z-code interpreter. Leo bridled slightly at 'premature optimization' and wondered what was important about a Z-code interpreter ('Z-code interpreter' is, according to Nicholas, 'obfuscated shorthand for ``dynamic opcode libraries'' and ``reading foreign bytecode''.')
Toward the end of the week, Leo checked in a final patch related to this experiment and commented that, to do things right, JIT optimization should move in the direction that Angel Faus had outlined.
http://citeseer.nj.nec.com/krintz01using.html -- Sean's first link
http://www-hydra.stanford.edu/publications/JVM02.pdf -- 'Free' paper
http://groups.google.com/groups -- IMCC as JIT Optimizer thread
http://groups.google.com/groups -- Leo's Last (-Oj) patch
Steve Fink announced that it had been brought to his attention that we were overdue for another release and announced that he'd like to have a Parrot feature freeze on March 8, with a Parrot 0.0.10 release a week after that (or a Parrot 0.1.0 release if someone sneaks objects or exceptions in under the wire...).
Jerome Quelin wondered about a codename and Benjamin Goldberg
commented that 'we don't have any of objects, exceptions, or a
real IO system' and suggested that we use 'Kakapo', which is a large,
flightless parrot. Garret Göbbel suggested the rather wonderful
'Orange Juice' in homage to Leo's recent work on the
Dan outlined his plan for the string rework (discussed last week). Nobody said anything, maybe they liked it.
Dan also outlined some requirements for the final Parrot build system, again, nobody comment.
And, right at the end of the week, he released his second attempt at an object spec. This one definitely got comments, but I'll cover them in the next summary.
http://groups.google.com/groups -- Strings
http://groups.google.com/groups -- Builds
http://groups.google.com/groups -- Objects
Steve Peters released a flurry of patches to eliminate compilation warnings during Parrot compilation. Leo wasn't sure about one of them, but I assume that most of them will be applied at some point.
Things were even quieter than last week with all of 10 messages, one of which was last week's summary.
Paul Johnson had observed that changing the order of evaluation (of terms in a list) -- which is currently undefined in theory whilst being left to right in practice -- would almost certainly break a great deal. He suggested that it would be sensible for Perl 6 to define such an order.
Larry agreed, commenting that 'The fact that Perl 5 doesn't define it is merely an oversight, brought on no doubt by a lack of oversight. But as you point out it can deduced by observation of all the various implementations of Perl.' Which made at least one person smile.
Last week, Simon Cozens asked that someone 'please compile a list of all the ``is foo'' properties that have been suggested/accepted as being pre-defined by the language.' as he couldn't keep track of them all.
This week someone (who also happened to be Simon Cozens) did just
that. Allison Randal went through Simon's list commenting on what he'd
got right and wrong, and explaining the general rule (properties and
traits are lower case, class names are capitalized, so
mean that something is a 'Foo', while
is bar relates to a 'bar'
property). The rest of the thread was taken up with confusion between
Munich and Zurich.
I'm getting the feeling of someone sat in the calm before the storm. perl6-language has been very quiet these last few weeks, I'm guessing that people don't want to distract Larry from the important business of producing an Apocalypse. Rumours abound of a draft in circulation among the Perl 6 core design team... Maybe this week will see its publication and the level of discussion in the language list will rise once more. Until then I'm enjoying the calm.
Still no American Odyssey web page. One day, I promise.
If you appreciated this summary, please consider one or more of the following options:
- Send money to the Perl Foundation at http://donate.perl-foundation.org/ and help support the ongoing development of Perl.
- Get involved in the Perl 6 process. The mailing lists are open to all. http://dev.perl.org/perl6/ and http://www.parrotcode.org/ are good starting points with links to the appropriate mailing lists.
- Send feedback, flames, money, job offers or a Schneider 90/5.8 Super Angulon XL lens to email@example.com
This week's summary was again sponsored by Darren Duncan. Thanks Darren. If you'd like to become a summary sponsor, drop me a line at firstname.lastname@example.org.