Slashdot Mirror

This could be one reason why running perl5 in the Parrot VM never really took off. Perl 6 will be a bit better specified, I hope, and so easier to write on top of a specified virtual machine.

Then run it with Ponie or your existing Perl 5 compiler, or add package main; at the start if you change your hash-bang line to /usr/bin/perl6 instead of /usr/bin/perl.

The point of the check is to re-use modules, not standalone scripts, so that you can migrate your code to Perl 6 gradually.

When we say "optimized bytecode compiler" these days, we generally mean that it does JIT. I know, I know, it's bad use of the terminology, but generally that's what people mean.

Ruby has one other massive advantage over Java on the medium-term horizon: Parrot. The Ruby-on-Parrot effort is progressing nicely, and when that is complete, Ponie will give Ruby transparent access to all of CPAN (thought yet another JITted bytecode system) even for those who don't like or can't use Perl.

At that point, Ruby becomes (IMHO) the most attractive HLL in existance (until Perl 6 lands... IF Perl 6 lands...)

m{[a-z][A-Z]+}
m{^(?:\w+\d|\S+(?:\'s)?)$}

m{<[a-z]><[A-Z]>+}
m{^[\w+\d|\S+[\'s]?]$ }

$r1 = rx:p5{[a-z][A-Z]+};
$r2 = rx{[\w+\d|\S+[\'s]?]};
$r3 = rx{^[<$r1>|<$r2>]$};

Does Parrot use References Counting (limited by virtual memory)? or
Does Parrot use Mark-Sweep Collection or Copying Collection (limited by physical memory)?

Unlike Perl 5 today, Parrot will not use reference counting. This is one of important difficulties which the Ponie project has to overcome. Please let me quote the most relevant parts of Parrot documentation.

Parrot FAQ:

You're not using reference counting. Why not?

Reference counting has three big issues.

1. Code complexity
2. Every single place where an object is referenced, and every single place where a reference is dropped, must properly alter the refcount of the objects being manipulated. One mistake and an object (and everything it references, directly or indirectly) lives forever or dies prematurely. Since a lot of code references objects, that's a lot of places to scatter reference counting code. While some of it can be automated, that's a lot of discipline that has to be maintained.
3. It's enough of a problem to track down garbage collection systems as it is, and when your garbage collection system is scattered across your entire source base, and possibly across all your extensions, it's a massive annoyance. More sophisticated garbage collection systems, on the other hand, involve much less code. It is, granted, trickier code, but it's a small chunk of code, contained in one spot. Once you get that one chunk correct, you don't have to bother with the garbage collector any more.
4. Cost
5. For reference counting to work right, you need to twiddle reference counts every time an object is referenced, or unreferenced. This generally includes even short-lived objects that will exist only briefly before dying. The cost of a reference counting scheme is directly linked to the number of times code references, or unreferences, objects. A tracing system of one sort or another (and there are many) has an average-case cost that's based on the number of live objects.
6. There are a number of hidden costs in a reference-counting scheme. Since the code to manipulate the reference counts must be scattered throughout the interpreter, the interpreter code is less dense than it would be without reference counts. That means that more of the processor's cache is dedicated to reference count code, code that is ultimately just interpreter bookkeeping, and not dedicated to running your program. The data is also less dense, as there has to be a reference count embedded in it. Once again, that means more cache used for each object during normal running, and lower cache density.
7. A tracing collector, on the other hand, has much denser code, since all it's doing is running through active objects in a tight loop. If done right, the entire tracing system will fit nicely in a processor's L1 cache, which is about as tight as you can get. The data being accessed is also done in a linear fashion, at least in part, which lends itself well to processor's prefetch mechanisms where they exist. The garbage collection data can also be put in a separate area and designed in a way that's much tighter and more cache-dense.
8. Having said that, the worst-case performance for a tracing garbage collecting system is worse than that of a reference counting system. Luckily the pathological cases are quite rare, and there are a number of fairly good techniques to deal with those. Refcounting schemes are also more deterministic than tracing systems, which can be an advantage in some cases. Making a tracing collector deterministic can be somewhat expensive.
9. Self-referential structures live forever
10. Or nearly forever. Since the only time an object is destroyed is when its refcount drops to zero, data in a self-referential structure

In the name of the entire Slashdot community, I would like to thank Larry Wall for the absolutely amazing work he is doing. Thanks Larry! There are many people working very hard to make our dream come true and give us the most innovative and cutting-edge programming language in existance, which Perl 6 is soon going to be. It would not be possible without all of the Perl 6 and Parrot contributors. Please let us also not forget about brave people who still actively maintain Perl 5 and will keep doing it even after Perl 6 is ready. The Ponie project shows us that Perl 5 is not going away. The work of all of those people is invaluable. And this is all to give us free software development platform of the 21st century, while uniting Perl, Python, Ruby, Tcl, Scheme, Ook, Forth, Befunge, BASIC and many other languages thanks to Parrot, finally allowing them all to seamlessly work together and ending the flame wars between them. Thank you!

And don't forget about Ponie, the project to build a Perl 5 interpreter on top of Parrot. That means that Perl 5 should continue to be useful even if the existing core code is eventually scrapped. This, of course, is one of the principal advantages of having a multilingual VM; any language that can target that VM can be maintained with much less effort.

In these instances filters like SpamAssasin may even add to the problem since they often consume more overhead than even SMTP daemons do, so that usually goes out the window as well (It's great, but not on a large scale (perl)).

It's not just you, but about 80% of the syntax stays the same. Much of the rest requires a few parser rule overrides. See ... And Now For Something Completely Similar, also by Damian.

Backwards compatibility is a huge concern. That's why Ponie exists and why Dan's so careful about supporting Perl 5 semantics on Parrot. (As well, I expect 80% of the core Perl 5 tests will port to Perl 6 with surprisingly little work.)

Just to give one current, more or less viable Parrot application that I know of, the virtual machine been embedded as mod_parrot , which can in principle allow you to run Parrot bytecode in Apache. Why would anyone want to write web applications in what amounts to assembly code? Well of course, most people wouldn't, but as Perl6 matures this could become a viable competitor to mod_perl ...and mod_python , mod_tcl , mod_scheme , etc.

More to the point, the development of Parrot has forced a cleanup of the Perl API. The current situation where the reference implementation is the only implementation has never been theoretically clean -- other languages, like Python, C, and Java, have long had multiple implementations, and this has consistently been a healthy thing for the evolution of the language. Abstracting out the virtual machine layer will allow Perl6 to have a pluggable runtime layer (e.g. replace runtime compilation & execution of bytecode into, say, dynamic execution of precompiled bytecode (as Python does), or direct compilation from source to executable machine code (as C does). More recently & concretely, abstracting out the VM layer has been the motivation for Ponie -- an effort to re-implement Perl5 to run on Parrot, and in the process give Perl that abstracted alternate implementation that most other languages have. This will be a very healthy thing, both for Perl5 and for Perl6.

If there has been a dropoff in contributions, it isn't due to Parrot work. Dan Sugalski et al have done excellent work here, and I think most people in the community recognize this. If there has been a dropoff, the much more mundane explanation is probably just the taking economy: a whole lot of people just don't have the spare cash to give these days.