Parrot Updates

BorrisYeltsin writes: "A couple of updates for Parrot are in a recent This Week on Perl 6, most imporantly Parrot 0.03 is out! Get it here , the release notes are here. Also Adam Turoff has got together the Parrot FAQ version 0.2 which addresses some of the more common questions about Parrot and Perl 6."

Comments

Perl articles of the highest quality

[Anonymous Coward]

The complete developerWorks "Cultured Perl" series:

• A programmer's Linux-oriented setup
• Application configuration with Perl
• Automating UNIX system administration with Perl
• Debugging Perl with ease
• The elegance of JAPH
• Genetic algorithms applied with Perl
• One-liners 101
• Parsing with Perl modules
• Perl 5.6 for C and Java programmers
• Reading and writing Excel files with Perl
• Review of Programming Perl, Third Edition
• Save it with Perl
• Small observations about the big picture
• Writing Perl programs that speak English

Another good developerWorks resource is this long list of well-written Linux Tutorials.

April Fool's Joke

[jsse]

April Fool's joke can become reality. Remember not to make bad jokes next April. :)

Old News

[mshiltonj]

Parrot 0.0.3 was released way back on the 11th of dec, nearly three weeks ago.

If you want *new* news on perl/parrot, the latest parrot in CVS is now "fully-functional" (interpret that however you want.)

performance of big programs? compatibility?

[bcrowell]

I remember seeing a comment by Larry Wall (?) to the effect that Perl isn't appropriate for large programs, which is why Perl isn't written in Perl. But now they say they're writing Perl's source-code-to-Parrot compiler in Perl. Was the original statement due to Perl's relaxed (some would say sloppy :-) approach to types and data hiding, or was it related to performance issues, or both? Will the Parrot implementation perform better for large programs?

On a different topic, what about compatibility? Their FAQ says that, for instance, localtime will no longer return year-1900. Doesn't this break old code? They say there will be an automated Perl 5->Perl 6 converter, but it isn't going to fix stuff like year-1900...or is it?

Re:performance of big programs? compatibility?

[Elian]

The perl parser's not written in perl for efficiency (both speed and memory use) and convenience (yacc is nice for some things, after all) reasons. Parrot's addressing the efficiency issues, and at this point there's more than enough knowledge and tools to get a good perl parser written in perl.

As for compatibility, your perl 5 code will call routines that return perl 5 compatible values. The perl 6 code will call routines that return perl 6 compatible values. It'll work--it's a simple enough problem to deal with.

Spam

[Matts]

A large number of perl web sites have been spammed with this. I consider the manner in which it's been done quite rude, as it has in no way been personalised, and is very "spam" like in appearance (i.e. it's saying that DeveloperWork's articles are of the highest quality - well they would, wouldn't they?).

I'm not disputing the quality of the articles there, just pointing out that this has gone to several places, and even been posted on a few sites. I didn't post it on the one I admin because it was totally impersonal.

FAQ leaves me concerned.

[squiggleslash]

The "Parrot Implementation Issues" piece suggests to me that the developer hasn't done any research or have much idea of the field they're programming in. Now, of course, it could be that the FAQ is merely flippant, but:

• Java is not the only stack based interpreter out there - and is far from being a good example of one. Even ignoring FORTH which is a full blown language based around the idea, there's the UCSD p-System, and many propriety systems based on the same concept, most 8 bit computers during the eighties where implementations of other languages existed ran versions based on VMs because of processor limitations. Virtual machines are not that popular, so it's relatively rare to see them, and even rarer to see them entirely open.
• A stack based system has architectural advantages over a register based system. It may be the FAQ author considered them, but it'd be nice to actually see acknowledgement rather than an assumption that such advantages are easily explained away. Register systems have a finite structure which, ultimately, will limit the overall design of the end product and intrude into how efficient it can be. Stack based systems have no such limitations - a stack is a stack.
• The 68000 emulator on the Mac is somehow proof that register based VMs are the way to go? I'd make a sentence involving the words "Smoking", "Guy", "Is", "Crack" and "This" but I suspect it'd get modded down as flamebait. Look, the 68000 emulator is nice but it's designed like that because it had to emulate another real world machine, not because that's the best way of doing a VM. And it had the considerable advantage that the PowerPC was designed to make such emulation fast anyway, Motorola/Apple/IBM put it together as a replacement for the 68000 and emulation of 68000 instructions without crippling the CPU itself was high on their agenda. Ever run UAE on an Intel CPU? You need to get into Pentium territory to get it to look like a damned A500 (7.1MHz 16-bit external data bus 68000). And yeah, the custom chip emulation is half the trouble, but it's not the whole story. It's slow. Dreadfully, painfully, slow.

Maybe all these issues were answered, but if you're going to put together a FAQ, a "Yeah, I thought of it, but those ideas suck, mine's much better, but I'm not telling you why, indeed, I'm going to use the worst possible examples to demonstrate how little research I did into this" answer isn't terribly inspiring.

Adam might want to have a gander at gForth, which is a stack based system written in C, and runs a hell of a lot faster, in my experience, than any CPU emulator I've seen, 68000 or anything else.

Re:FAQ leaves me concerned.

[Elian]

The "Parrot Implementation Issues" piece suggests to me that the developer hasn't done any research or have much idea of the field they're programming in. Now, of course, it could be that the FAQ is merely flippant

That would generally be the case. Most of the folks reading FAQs on this stuff don't have the background for a good discussion on this stuff, and the FAQ really isn't the place for it.

* Java is not the only stack based interpreter out there - and is far from being a good example of one. Even ignoring FORTH which is a full blown language based around the idea, there's the UCSD p-System,

Forth doesn't count--it's really not an interpreter or VM as such. And the UCSD p-System (which I did know about) ran on systems that are profoundly obsolete. The base hardware's a bit more capable than the 6502s in Apple ][s. (Much as I liked both)

One example I didn't mention but should have was Visual Basic, which is apparently a stack-based interpreter system.

A stack based system has architectural advantages over a register based system. It may be the FAQ author considered them, but it'd be nice to actually see acknowledgement rather than an assumption that such advantages are easily explained away. Register systems have a finite structure which, ultimately, will limit the overall design of the end product and intrude into how efficient it can be. Stack based systems have no such limitations - a stack is a stack.

And register based systems have advantages over stack based systems. An awful lot of stack thrash is avoided in a register system--with more temp values handy you don't have the extraneous dups, stack rotates, and name lookups.

And just because we have registers doesn't mean we don't have a stack. We do. (Several, actually) But registers let us toss a lot of the useless shuffling.

The 68000 emulator on the Mac is somehow proof that register based VMs are the way to go ...Ever run UAE on an Intel CPU? You need to get into Pentium territory to get it to look like a damned A500

The 68K emulation on the Mac is proof that it works and is viable, not that it's the way to go. And UAE's troubles are as much architectural issues (the x86 chip is really register starved) as anything else.

Parrot's ops are generally not as low-level as machine instructions, so even if the register system was dreadfully inefficient compared to a stack system (and it's not, parrot's numbers are good) not that much time is spent dealing with it anyway. (Though I don't want to trade off even 3% speed hits)

Maybe all these issues were answered, but if you're going to put together a FAQ, a "Yeah, I thought of it, but those ideas suck, mine's much better, but I'm not telling you why, indeed, I'm going to use the worst possible examples to demonstrate how little research I did into this" answer isn't terribly inspiring.

This is dead-on. I'll get some more meat into the FAQ.

Adam might ...

I might, actually. Adam just pasted in my answers to the technical stuff.

Re:FAQ leaves me concerned.

[Elian]

Since this seems to be serious, please consider the advantages of a mixed register+stack machine. With 3 32 bit stacks and one 64 bit stack (though if you are using FORTH, you can use the FORTH model, and drop the last one at the expense of having a set of double-cell primitives.

This has been part of the design from the very beginning. In addition to a general purpose stack, each of the register types has a stack associated with it so you can push and pop all the registers of a particular type at once.

The reason for hardware registers is that in hardware fast memory is an expensive and scarse resource.

That's not the only reason. Bits and memory bus bandwidth are also scarce resources, and a small set of named scratchpad spots allows for significant speedups over fully qualifying everything with a memory location.

But in a software implementation, the registers run in the same memory space as the rest of the program. So they loose many of their advantages.

Many, but not all. The stack thrash is a big issue as well and, while there are ways to get around it by allowing references back in the stack, they're generally more awkward than a plain register setup.

There's also an awful lot of literature on writing optimizers which is geared towards register machines, as that's what everyone's CPU is these days. I've not found much readable literature on optimizing a pure stack-based system.

They can, however, save a level of indirection. And that can speed things up if it's on something that is being done frequently. So one alternative is to define the largest stack frame that one wishes to allow for, provide a way for a stack frame to be copied to a fixed location, and then have analogous operations based either on the fixed location, or on a stack frame pointer in the stack. So the stack is a set of modifiable stack frames (though only the top stack frame at any time is resizeable).

Congrats, you just described a register-frame system. Which is what we already have. :)

However, if one isn't modeling an existing hardware implementation, then the virtual machine should not end up looking like any of the hardware.

One is always modelling hardware. That's what this stuff ultimately runs on. You can't ignore the underlying system if you want really good performance. And while a good chunk of our userbase is running on register-starved systems (x86) a lot aren't. The design's not got any serious disadvantages relative to a stack system on x86, and some good advantages on machines with plentiful registers (alpha, sparc, PPC, MIPS, IA64) so it's a win.

Re:Perl Documentation

[hey!]

Moderators -- don't mod somebody flamebait because you disagree with them. The above was offtopic, maybe.

I happen to disagree with a lot of what the writer says, but I think he was making substantive comments, to which I think I can respond.

Perl is emphatically not an object-oriented language.

Perhaps true depending on the criteria you use, but over the years I've come to care a lot less about this kind of taxonomic issue and more about getting things done without a fuss. The question I'd prefer to ask is, does it support object oriented design? Personally, I'd probably go with Python or Java for a project requiring large scale OO design. However, serious Perl hackers get by pretty well in Perl.

Too many simple tasks are pointlessly complicated.

True, but many complex tasks are very easy in Perl too. A lot of language flamewars unconsciously adopt a desert island scenario: if you had to do ALL your work in one language, what would that language be like? Well, you don't have to get by with one language.

Perl is notoriously impossible read and maintain.

This is simply untrue. Speaking as a very occaisional and non-expert Perl user who has had at various points needed to maintain some fairly complex perl CGIs, well structured Perl is quite easy for the non-Perl guru to maintain. This is not to say there aren't subtle issues (e.g. confusing scalar and array contexts) that can't bite a newbie trying to add substantial new functionality to Perl software, but when code has been written by a Perl expert and it is well structured, Perl is in fact very easy to maintain.

If there is a kernel of truth to this myth, it is perhaps that Perl tempts the inexperienced to create obfuscated code. However, an experienced coder with good habits will produce highly maintainable code.

Perl attempts to be all things to all people and ends up being second-rate at everything.

First of all, Perl beats anything else I've tried hands down for doing filter type programs (i.e. transforming input streams). When you do a lot of this kind of thing, it's very convenient to have a tool that spans the range of complexity from things you would do in awk to things you'd use lex and yacc for. If this is the kind of work you do, then Perl is for you. If this kind of work is not what you do or is just a very small part of what you do, then Perl will probably seem somewhat pointless to you. However, you shouldn't expect your experience to be universal.

Secondly, IMO the fact that a language is general purpose (like Perl) doesn't mean it has to be the best, or even a very good solution for every kind of problem you can imagine. There are some languages out there which are fairly good for a wide variety of problems (Java comes to mind); that is an important niche. However there are niches for languages that are excellent at one or two things. These still need to support styles of work that may not be their strongest suit, however, because real world programs have to address a mix of issues.