Ponder, if you will, how you call a function:
foo(1, 2, 3)Or, if you prefer a low-level pseudocode (where Px are parameter slots),
P1 = 1 P2 = 2 P3 = 3 invoke fooNo big deal, and pretty straightforward. Yeah you can debate stack vs registers, parameter passing conventions, and stuff like that, but for now... it's irrelevant.
Next, ponder multimethod dispatch. Everything looks identical to the previous example, except that the invoke of the foo sub 'object' looks at the parameters and decides where it needs to go. (Presumably there's a list of sub-functions and their associated parameter lists that gets searched, or something. The exact mechanism is irrelevant here)
Okay, then... think about how we return from that sub. Now, in a 'normal' call/return scheme, the return value (and there's almost always just one) gets stuck in the return register or on the top of the stack, and the next entry on the stack's the return address. We yank out the return address and jump there. When the function/method returns the code that made the call yanks the result out of the return slot, wherever that is, and then keeps on going. Calls and returns are fundamentally different.
In a continuation passing system Things are a little different. The call is the same--fill in the slots and invoke the sub object, passing as one of the parameters the return continuation. The return, though... well, the return looks exactly like the call. That is, source which looks like:
return 12turns into
P1 = 12 invoke ReturnContinuationThis has a number of ramifications. First, it actually simplifies the compiler a bit, since you don't have two 'destination' control cases (function call and return) but just one. That means you can leverage your function call system to make it easy to return multiple values from a function, since the code gen's the same. (The code immediately after a function call is the same as the code at the beginning of a function.
This means you can do:
P1 = 12 P2 = "Foo" P3 = SomeObject invoke ReturnContinuationand return multiple values. If your language supports it, of course.
Now, even a cursory inspection will show that the function call and return continuation invocation are the same thing. What does this mean? Well, of course it means you can do MMD on function returns as well as on function calls.
What use this? Well, if you have a standard error convention you could easily set things up to dispatch to the error routine without having to code up the check -- the compiler can pass in a MMD return continuation. Still, most languages are ill-equipped syntactically to deal with this sort of thing, and annotating the function call itself would get unwieldy. Most languages but... not INTERCAL.
Everyone, I'm sure, is familiar with standard INTERCAL's COME FROM statement, which is the inverse of GOTO. And, I'm sure, everyone's also familiar with Quantum INTERCAL, which allows multiple COME FROM statements for the same label, so your program becomes a quantum superposition of all possible destinations which ultimately collapses (if the system or programmer doesn't first) into a result. Between that, though, there's a middle ground. If you annotate your COME FROM statements to note not only where control comes from but also the conditions in which it does (naming functions, since of course we're all using Functional INTERCAL for the good programming practices it allows) you've an amazing amount of expressive control flow at your fingertips. Cool, huh?
(I suppose you could annotate functions in lesser languages to do the same thing, and treat the function call as if it were a tail call into the annotated function, but that seems kinda wussy in comparison)
Scientists find evidence of Dholes in Croatia. Though they may not know it yet.
Here's hoping for their sake that the stars aren't right...
Or the Czec Republic?
Here's the scoop. We've scared up a non-Linux machine for Leo Tötsch, a man of prodigious parrot production, to use. That's good news, as he's x86/Linux only (behind a metered ISDN line) at the moment. This is causing us headaches with Parrot, since things that work just fine there fail on other platforms. Hence the scaring up the machine. What we need now is to get it to him
Leo's in Austria, and not going to EuroFoo, but the machine we've found isn't in Austria, but can go to EuroFoo. So we're hoping to get the machine and a person together so we can get the thing ferried over to Leo. (Leo's close to the Czec side of the country, hence the alternate point 'o origin question)
So if you'll be at EuroFoo and heading by Leo's place, give or take a few kilometers (or are willing to take a drive in the countrysude--I hear it's quite nice :) drop me a line at dan@sidhe.org and we'll see about getting you, Leo, and the machine all hooked up for delivery.
If you've been following along at home, you probably remember that I've been having ever so much fun with my well-travelled iBook and Apple Repair. At OSCON last week a few people pulled be aside (separately) and told me I should've said something--it would've been taken care of. Which, had I know it was going to be six weeks, I would've.
Well... it's happening again. This time the case screws are carrying a charge when the thing's plugged in, which means I've got something shorting across the case ground. I assume someone tightened some screws down too tightly or crimped a cable or something, but at this point I don't trust this beast for work. Since I do eventually learn from my mistakes, I did the sensible thing and got in touch with one of the folks who very generously offered help at OSCON.
As such, I'd like to very publicly thank George Papa, George Ruhana, and Danny Rosenthal of Peak6 (A Chicago-based equity options market-making firm, one of the largest in the US, to pull the official quote from the website) who've set me up with a Powerbook to replace the iBook. They're heavy Perl 5 users. Quoth George Papa:
We are a smallish trading/market making company (~70 people) doing some very interesting and challenging things. We have had good success using perl5 as a first class application language/environment at the heart of a project to (almost) fully automate the data processing, decision making and messaging necessary to trade and make markets in the entire listed equity options marketplace (options on the 2,000 largest US public companies) in a very unforgiving real time setting are looking forward to using parrot/perl6 as well.I worked, briefly, with George Papa when I did my time at Cantor Fitzgerald (I was starting as he was ending) and he's a good guy. Dunno how many folks who read this trade equity options, but if you do... look these folks up.
Thanks guys--thanks a lot.
Back in June I gave a presentation to the Boston ACM. The talk went much longer than I'd planned, and I only managed to get through one of the two sets of slides I had. I promised everyone I'd get an annotated version of the mystery presentation up as soon as I could. Of course, this was in the middle of my machine's "thrashing about and dying" phase, so it's taken a little longer than I'd originally planned.
Finally got it done, though, so if you're interested feel free to snag the annotated PDF of my Parrot Implementations talk. It doesn't cover everything, by any means, but it does talk about some of the interesting things we're doing as part of Parrot's development. (Well, I think they're interesting, at least)
The nicest part, by far, of OSCON is the folks that you get to talk to when you're otherwise ignoring the conference. At lunch Friday (which I owe Ingy for. D'oh!) I spent a good chunk of time talking with Autrijus about serializable continuations.
Autrijus needs 'em for doing linear web programming, and has, scarily enough, got them mostly working in Perl 5. (Which should, in and of itself, be sufficient to add him to the list of Scary-smart People of perl) He'd like more, and definitely wants them for parrot. We talked for a while about what he needs, what he wants, and how things work.
Y'know what?
We can do them. More to the point, we will do them. What's even more cool is that I know how to do it without having to serialize the bytecode. (Though there are cases where bytecode serialization is absolutely required. Basically if you're using bytecode that was entirely on-disk you don't need to)
This... should be fun. :)
Well, as you've probably already heard, I did get pied after all at OSCON. Since the stories have been a bit muddled, I figured I'd stir the waters a bit myself.
Originally the plan was for Guido to toss a pie at me (from 10 paces, at which range pies are... inaccurate) since I didn't meet the terms of the bet. I'd baked a pair of Key Lime pies for the event--I realize they're nowhere near traditional, but I figure if I'm going to be pasted with one, it's darned well going to be tasty. The room I was in at the time had an oven (long story, don't ask) and there's an upscale Safeway (regional supermarket chain) about 10 blocks from the con hotel (at the corner of 10th and Jefferson), so it wasn't a big deal. Key Lime pies are dead easy to make if you cheat and use a predone crust, and pretty simple even if you don't (this time I did).
So, I stood up in front of the Python Lightning talk audience and conceded. Guido, quite graciously, declined to toss the pie, and instead the two pies I made got taken down to the Apple reception and served out. That did disappoint the audience some, though almost everyone out for blood was from the perl side of things. They can cope.
Afterwards Fotango took some of us out for dinner, which was cool. (As was the discussion. I'm now pondering 3D Postscript) And that's where things got interesting.
Also happening that evening was the Perl Foundation auction. This is an annual event (though part of the tradition is to leave off planning for it until the last minute, so almost nobody knows about it in time--maybe someone should put in for a BOF slot for 2005 now), going on at about the same time as dinner. Turns out my boss was at the auction. I found this out when I got a phone call that went something like "They want to auction off hitting you with a pie. You game?" It's for a good cause (TPF's helped out Parrot with both equipment and people grants) so I volunteered, with a caveat--$500 minimum bid. Now, this wasn't a toss from a distance--this was a full on, right in front pie splot. No chance of missing with it.
Yeah, I did figure it was unlikely that this'd happen, since I knew the auction was slow. (If this'd been YAPC::EU I'd have said 1000 euro minimum and figure on a 80%+ chance it'd happen) I was the last thing on the list, and the auction lasted long enough that I was actually there when the auctioning happened.
And, of course, they managed it. Granted, it took a bunch of folks throwing cash in, but with a grand total of $520 (give or take a few bucks, I don't remember the exact amount) the pie was won. Schwern, as the largest contributor, got the honor of pie delivery. That's how one of the pies got delivered.
Since I was getting pied by the perl community, there was no way we could legitimately not give Guido his own shot. He'd passed so as not to pie me, but since I was getting pied anyway, well, he deserved his shot.
From there we had some scrambling for the second pie. (It probably would've helped if I realized we needed it before Friday morning, and moreso if I'd actually told people why I wanted someone to get a second pie) And more scrambling for time for the pie-ing. We'd figured it'd happen after the second morning keynote Friday, but instead it happened before Milton's closing keynote. For the best, really, as a lot of folks bailed on the second keynote, and I'm pretty sure that the reason that at least some folks stayed for it was for the pie-ing. (Not the fault of the speaker. The first keynote was about a phenomenally cool map collection and the software that was written to manipulate and serve it up to the world. The second keynote was some guy from Novell. Even if he didn't seem dull he was doomed)
Then there was the pie-ing itself. Here we should make an important safety tip: Always check with the con staff for impromptu things, not the hotel staff! That would've saved quite a lot of plastic sheeting, as the hotel folks got a bit enthusiastic and covered the entire stage and everything on it with plastic, half of which got taken down again, since undoing it after the event would've taken far too long. (Amazingly, the phrase "stage condom" wasn't actually uttered in public, at least not into a microphone)
The pie-ing itself was as you'd expect. Guido got the first splatting, and Nick Clark got the second. (Schwern passed the privilege on) Nick said something with the pie, but I didn't catch it, having Baker's Ear at the time. (Yes, I had an earful of cream pie. An eyeful too--I ended up tossing a pair of contacts a day early because they had a film of pie on 'em. Which is something worth keeping in mind if you're getting pied) There are, I'm sure, dozens, if not hundreds, of pictures of me getting splatted, and I fully expect 'em to all end up on the web. There may well be video too. The ballroom was wired for video and one of the last things Nat said before all the fun was "Look into the camera", so I bet there'll be mpegs of it too.
Well, the python lightning talks are over, and I've officially and publicly conceded the contest. In the end we only managed four of the seven tests (and I found that Leo's version didn't do import, so you actually need to do some cut-n-paste to get one of the tests running) and part of a fifth. Guido was quite gracious and didn't pitch a pie at me, and while he disappointed many in the crowd (Perl, Python, and the random spectacle seekers) I do appreciate it.
Anyway, here's what we do have for results.
| Parrot | Python | |
|---|---|---|
| b1 | 1.40 | 1.65 |
| b2: | 0.15 | 0.45 |
| b3: | 5.00 | 2.40 |
| b6: | 1.62 | 2.40 |
How do you duplicate them?
First, you need an optimized build of Parrot. By default we don't build parrot with optimizations. Why? Well, we're still deep in development. It's really a pain to debug an optimized build (or a core dump from an optimized build) because of some of the things the optimizer does, so we don't. Sensible for development, less sensible for performance checks. (On the other hand, if your code is snappy without optimizations, that's a cool thing too) So, when you configure pass in the --optimize flag.
Second, you need to do the runs on an x86 linux system. This is especially true when running with the JIT--each architecture has a different set of ops that get fast JITting, with the x86 doing best.
Third, you need to run the tests at least twice for Parrot. The driver harness in CVS compiles the python to bytecode and translates the python bytecode to parrot bytecode the first time things are run. Second and subsequent times use the cached bytecode and skip that step, for a pretty significant speedup.
Finally you do need a mildly thumped version of test b6. One of the things the translator doesn't do right now is python's import, so the bits imported from b5 need to be cut-and-pasted into the source for b6. From there... run the tests a few times. I found there was a fair amount of flux, so the times above are the best of five runs for both parrot and python.
I'm pretty sure the bad times on b3 are from the hack job done to implement python classes. That's one of the things that's going to get fixed up. And things will get fixed up. Finishing the translator is high on the list 'o things to do, one I'm hoping to get done by the end of August.