This week's Perl 6 Summary
p6summ...@bofh.org.uk
Welcome to the latest Perl 6 summary, your handy cut out and keep guide
to the goings on in the crazy world of Perl 6 design and development.
It's been a rather quiet week this week; only 75 messages in
perl6-internals and a mere 57 in perl6-language. So, at least it's
palindromic.
We start off, as is traditional, with perl6-internals
The 2004 Performance challenge
Dan announced that he'd made a bet with Guido van Rossum that Parrot
would be faster at executing a pure python benchmark of some sort to be
determined. The details of the challenge will be announced at OSCON 2003
and the results at OSCON 2004. Dan stands to lose $10 and a round of
beer for the Zope/Pythonlabs folks. (Dunno how many of them there are
though...). We don't know what he stands to win yet, but I'd hope 'beers
from each of the Zope/Pythonlabs folks' are included.
For some reason nobody commented on this.
<http://makeashorterlink.com/?K2C815C63>
More Parrot Objects
Jerome Quelin wondered how Parrot objects would handle property
inheritance. Dan pointed out that properties don't get inherited and
Jerome realised he meant to ask about attribute inheritance. Attributes
*are* inherited but are mostly invisible to any methods but the methods
of the class that defines the attributes (though they will be accessible
(presumably through reflection)).
In another subthread, we got confused by multimethods.
<http://makeashorterlink.com/?O6D816C63>
<http://makeashorterlink.com/?O4E822C63> -- Multimethods
Bytecode Metadata
James Michael DuPont wanted to know what had been decided about Bytecode
metadata and outlined the things that he'd like to know about a given
bytecode. Leo Tötsch reckoned that what James wanted was either in the
bytecode right now, or was handleable by the framework that was in
place. He pointed James to docs/parrotbyte.pod in the Parrot
distribution.
Further discussions centred on the *amount* of metadata and whether this
would affect loading speed and efficiency, or get in the way of the
desired 'mmap and go' principle. Jürgen Bömmels pointed out that we also
had to be capable of passing meta data from a compiler 'through' IMCC
and on to the final bytecode. There was also a touching reunion between
James Michael DuPont and Gopal V. Ah...
<http://makeashorterlink.com/?E41925C63>
Multi programming language questions
Phil Hassey has been lurking, fascinated on the internals list for a
couple of months. This week he broke the silence by asking a couple of
questions about cross language function dispatch, string compatibility
and global scopes. For instance, PHP, Common Lisp and others are case
insensitive about functions. Which is okay when you're calling such a
function from a case sensitive language, but can be tricky if you call
out from a case insensitive to a case sensitive language. Dan thought
that there wasn't going to be much that could be done about this problem
(at least, not transparently) but seems to think that the other issues
raised shouldn't be too problematic.
<http://makeashorterlink.com/?R32931C63>
Random questions
David popped up and, after remarking on the amount of progress Parrot
had made since he last looked at it, had a few questions about various
bits and pieces. Leo and Dan provided a bunch of good answers.
<http://makeashorterlink.com/?X63912C63>
A Scheme for extending core.ops
Leo Tötsch seems to have got bored of 'just' being the Patch Monster and
has been producing some discussion documents proposing all sorts of
useful tricks for improving the design/speed/extensibility of Parrot's
internals. This week he turned his attention to core.ops. His plan
involves a way of reducing the size of core_ops, improving cache
locality and generally solving a raft of problems I didn't even know
Parrot had. His new scheme allows for a small core.ops, easy extension
and no execution speed penalty for non core ops. As is usual with Leo's
stuff, the scheme came with code. Gregor had a bunch of observations and
suggestions and he and Leo thrashed out a slightly modified scheme for
going forward.
<http://makeashorterlink.com/?P54921C63>
Week of the alternative runloops
Leo Tö offered a couple of different core runloops this week. First up
was the Computed Goto Prederefed (CGP) runloop which, essentially
combined a two runloop optimization techniques to provide what can only
be described as massive speedups. The -O3 compiled version ran
parrot_mops 6 times faster than the basic 'fast_core' and more than 3
times faster than the previous fastest core. People were impressed.
A few days later, Leo reached into his bag of tricks and pulled out the
CSwitch runloop that did predereferenced dispatch via a big C switch
statement. This loop is about 50% faster than the basic fast_core loop,
but slower than all the computed goto dispatched loops. At this point
Jason Gloudon pointed out that predereferencing can cause problems in a
multi threaded environment.
Quote of the Parrot development process so far:
"I'm a really bad C programmer" -- Leo Tötsch
<http://makeashorterlink.com/?R15942C63>
And that about wraps it up for perl6-internals this week. Dan's been
busy in Sebastapol with the Perl 6 Cabal thrashing out the design of
Perl 6 functions and other bits with Larry, Damian, Allison and
chromatic, which probably explains why he's not been driving the mailing
list for the week.
Meanwhile in perl6-language
It's been even quieter on the language list. Mostly interesting though.
Shortcut "?="
Miko O'Sullivan proposed a new assignment operator, "$var ?= $x : $y",
equivalent to "$var = $var ? $x : $y". It was pointed out that, for
correctness that should be "??=". Deborah Ariel Pickett wondered what
was the need for such an operator and couldn't imagine ever needing such
an operator.
<http://makeashorterlink.com/?V26962C63>
Language Discussion Summaries
Miko O'Sullivan proposed that members of the language list provide
summaries of the discussions in the group [What's this? Chopped liver?
-- Ed]. The idea being that each summary would describe a proposed idea
and then summarizes the list's feelings on the idea, and would be posted
on a website. The idea was basically well received, then the list fell
to quibbling about format, whether summaries should be posted to the
list where they could be picked up by the list summarizer, and whether
we were just reinventing RFCs all over again.
As of now, the only summary that actually exists is Miko's summary of
the proposed "??=" operator. Which I hadn't even bothered to read until
I came to write the summary.
<http://makeashorterlink.com/?T27923C63>
<http://www.idocs.com/perl6/> -- Summaries website
Newline as a statement terminator
Stéphane Payrard confessed that he would like newline to be a statement
terminator everywhere it can be. Everybody hated it. Deborah Ariel
Pickett came up with a neat example of why it was a really bad idea with
a simple ambiguous piece of code:
sub foo
{
print "abcde"
if $condition
{
print "fghij"
}
}
which could mean either:
sub foo {
print "abcdef" if $condition;
return sub {
print "fghij";
}
}
Or
sub foo {
print "abcde";
if $condition {
print "fghij";
}
}
And disambiguating with indentation is way too Pythonesque for many.
<http://makeashorterlink.com/?L18921C63>
Arrays vs. Lists
In his quest to exhaustively document what is known about Perl so far,
Michael Lazzaro asked for a definitive answer to the question "What's
the difference between an array and a list in Perl 6"?
Various answers were given but I think Uri Guttman came up with the most
succinct pair of definitions, which reduce to 'lists are read only,
arrays are read/write'. (That's the data structure itself, not the data
structure's contents, "($a, $b) = (1, 2)" doesn't modify either list,
but it does modify the lvalues in the left hand list).
<http://makeashorterlink.com/?J49912C63>
<http://makeashorterlink.com/?I1A923C63> -- Uri's definitions
Announcements, Acknowledgements and Trip Planning
This week's summary was prepared in the comfy chair with distractions
from cats, irc, former employers, bugs and poring over maps of the
Eastern Seaboard.
We're coming to America. This year, making a virtue out of a necessity
we're going to give ourselves a good long holiday in the States. We'll
be flying out to Boca Raton for YAPC, then taking a road trip up through
the Appalachians to New England, possibly swinging into Canada before
coming down through Michigan to Chicago and taking a slow train to
Portland, OR for The Perl Conference. If it looks like you might be on
our route, drop me a line...
Proofreading services were provided by Aspell and me. (I could lie and
say that they were provided by Leon Brocard, enabling me to work his
name into the summary somehow, but I think I'll do it in a parenthetical
comment instead.)
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 the secret of eternal
immaturity to p6summ...@bofh.org.uk
This week's summary was sponsored by Darren Duncan. Thanks Darren. If
you'd like to become a summary sponsor, drop me a line at
p6summ...@bofh.org.uk.
--
Piers
Leopold Toetsch
>
> The 2004 Performance challenge
> Dan announced that he'd made a bet with Guido van Rossum that Parrot
> would be faster at executing a pure python benchmark
[ ... ]
> For some reason nobody commented on this.
The CGP runloop was the comment ;-)
Thanks for the summary,
leo
Piers Cawley
Dan Sugalski
>p6summ...@bofh.org.uk wrote:
>
>>
>> The 2004 Performance challenge
>> Dan announced that he'd made a bet with Guido van Rossum that Parrot
>> would be faster at executing a pure python benchmark
>
>
You missed the pie as part of the penalty, though that might not have
hit the list.
The challenge currently stands at $10, a round of beer for
pythonlabs/zope folks (we've not determined Guido's beer debt yet)
and a cream pie at 10 paces, with a flavor of the target's choosing.
(Since Guido's going to get hit with it, he should at least get to
choose the flavor I'm going to lob at him. Hate to hit him with
something that'll trigger allergies)
The challenge system is x86 Linux with GCC, FWIW. I have this nagging
feeling we'll be able to muster something that'll run on it... :)
--
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
d...@sidhe.org have teddy bears and even
teddy bears get drunk
Nicholas Clark
> The challenge system is x86 Linux with GCC, FWIW. I have this nagging
> feeling we'll be able to muster something that'll run on it... :)
Are we free to use whichever runops core we feel like?
Nicholas Clark
Dan Sugalski
Yup. There's no restriction on that.
Leopold Toetsch
> The challenge system is x86 Linux with GCC, FWIW.
Nice ;-)
leo
Dan Sugalski
And not even my choice, but who am I to argue, right? :)
Piers Cawley
Welcome to the all new, entirely unaltered, all singing, all dancing
Perl 6 summary. Your beacon of reliability in the crazy world that is
Perl 6 design and development.
Another quiet week. Even quieter than last week in fact, unless my mail
spent some of the time up the spout, but I don't think so.
So, as is traditional, we kick off with perl6-internals
CGP - The Computed Goto Prederefed Runloop
Last week I mentioned that nobody seemed to have commented on Dan's bet
with Guido van Rossum that Parrot would outperform Python by OSCON 2004.
(I also missed the fact that the penalty for losing the bet now involves
cream pies as well as $10 and a round of drinks...). After I posted the
summary to the mailing lists, Leopold Tötsch informed me that he had
commented indirectly by announcing his new, improved, ludicrously quick
runloop that combines computed GOTOs and predereferencing. Whatever that
means.
This week, Leo and Nicholas Clark worked out how to combine the
blistering pace of the JIT core (for operations that had been translated
into hand hacked machine code) with the blistering pace of the CGP
runloop (for the other ops). As far as I can tell, this involved turning
the idea 'inside out', the VM actually starts up running JIT compiled
code and calls out to the CGP core to execute non-JITable sequences of
ops. The numbers for this approach look fantastic (quite stunningly
quick...) So Leo checked it in.
<http://makeashorterlink.com/?Y27C12083>
<http://makeashorterlink.com/?Q48C22083> -- Some numbers
<http://makeashorterlink.com/?G19C21083> -- Check in notice
Optimized runloops and threading issues
Last week we were reminded that JIT and predereferenced runloops don't
work in a threaded environment. This week Jerome Vouillon pointed out an
approach that looks like it could fix that (it seemed to convince Leo).
Dan (possibly playing mail catchup) said he was okay with having to fall
back to the old fast core (as opposed to the current, stupidly fast
core) in the presence of threads, but Leo seem to think that, using
Jerome's scheme we'll be able to have our cake, eat it and still throw
the cream pie at the Python team. Huzzah!
<http://makeashorterlink.com/?P2AC23083>
"keyed_int" issues
Leo Tötsch had wondered about why "{get,set}_<type>_keyed_int" vtable
methods needed to take an "INTVAL*" value instead of a plain "INTVAL" as
it introduced some possibly unneeded conditional code, a stack variable
for the key and made life hard for JIT code. It looks like the pointer
is a holdover from an early approach to doing multidimensional keyed
structures.
<http://makeashorterlink.com/?W2BC32083>
Changes to the calling convention and other fallout
Dan returned from the Sebastapol Perl 6 meeting with a few announcements
and one change in the parrot calling convention (how many calling
conventions have we had now?).
<http://makeashorterlink.com/?N2CC62083>
Macro support in IMCC
Jürgen Bömmels announced that he'd implemented macro expansion in IMCC
(Yay Jürgen!). Leo liked it, but requested a few changes before he'd
check it in, so hopefully, some time soon the mainline IMCC will have
macros, which is very nice.
<http://makeashorterlink.com/?A2DC15083>
Meanwhile, in perl6-language
Almost all the discussion was about the difference between arrays and
lists. Deborah Ariel Pickett came up with a good list of questions about
arrays and array references in scalar and list contexts, which Michael
Lazzaro answered (very neatly I thought) with a list of their different
contextual behaviours. Deborah extended Michael's list to hashes and
hashrefs in a reasonably obvious way. Smylers came up with a possible
new sigquote (after paraphrasing): "We should limit new features to
those that arise from a desire for the functionality rather than a
desire to use up 'spare' syntax". (Okay, it's not exactly *snappy*, but
I think it's important).
<http://makeashorterlink.com/?H1EC23083> -- Deborah's questions
<http://makeashorterlink.com/?C1FC42083> -- Michael's answers
And that wraps it up for the language list. I'm sure it'll pick up again
soon though. There are rumours of a draft apocalypse in the next couple
of weeks, and presumably that implies a real apocalypse soon after.
Assuming we haven't had another kind of Apocalypse in the mean time.
Announcements, Acknowledgements and AnotherWordBeginningWithA
This week's summary was again prepared in the comfy chair with
surprisingly few distractions apart from the late arrival of mail from
Leon Brocard announcing that he'd implemented a brainf*ck compiler in
brainf*ck, but that didn't really happen this week so I've got no excuse
for mentioning Leon's name in this summary.
Thanks to everyone who dropped us a line about our American Odyssey; I'm
hoping I'll have one of those web page things up at some point with a
rough itinerary in case anyone wants to come and throw rotten tomatoes
at me (or, preferably, buy me sushi).
Proofreading services were again down to Aspell and me.
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 17 inches of aluminium
goodness to p6summ...@bofh.org.uk
This week's summary was, once more, sponsored by Darren Duncan. Thanks
gre...@focusresearch.com
I agree with the policy of referring to Leo in the plural.
Regards,
-- Gregor