Slashdot Mirror
Parrot 1.0.0 Released
outZider writes "Parrot 1.0.0 was released last night! The release of Parrot 1.0 provides the first "stable" release to developers, with a supportable, stable API for language developers to build from. For those who don't know, Parrot is a virtual machine for dynamic languages like Perl, PHP, Python, and Ruby, and is best known as the virtual machine for Rakudo, the reference implementation of Perl 6."
One Bytecode to rule them all, One Bytecode to describe them, One Bytecode to bring them all and in the OS bind them.
Umm is it me or has the internet been slashdotted?!
The 2 times I want to read TFA as well, bah!
Don't panic
Sorry, exclamation points in summaries always throw me off.
I'll tell you what's wrong with it, my lad. 'E's slashdotted, that's what's wrong with it!
Knowledge is how to play a game, intelligence is how to win, wisdom is knowing what game to play.
What's the performance and stability like?
I remember doing some benchmarks more than a year ago and plain perl 5 was faster.
Hope it's much better now...
Did Bono take time of from being a pompous narcisist to contribute to the project? What other reason is there for this inane drivel being reproduced in the release announcement?
At least it's text only and we were spared a blast of bland, derivative corporate rock. I stopped reading after "U2", "Walk On" -- "Fuck Off" more like!
So there is a spec for Perl 6? Now there is something novel from Perl camp.
Fuck systemd. Fuck Redhat. Fuck Soylent, too. Wait, scratch the last one.
Remember that their plans for the 1.0 release was for a stable API for language implementors, not highly optimized performance.
Question from somebody who's done some compiler work with VMs but not Parrot...
What does Parrot do that other VMs can't (e.g. the .NET dynamic language runtime on the CLR, or the JVM?)
Without knowing better, it seems like a lot of duplicated effort to me...
Slightly off topic: Is there a compiler for Perl, that is not based on bytecode, and therefore is difficult to decompile?
Parrot 1.0.0 was released last night! The release of Parrot 1.0 provides the first "stable" release to developers, with a supportable, stable API for language developers to build from. For those who don't know, Parrot is a virtual machine for dynamic languages like Perl, PHP, Python, and Ruby, and is best known as the virtual machine for Rakudo, the reference implementation of Perl 6.
SQUAWK! On topic!
It included a mock press release: Perl and Python Announce Joint Development.
And a joint "interview" of Larry and Guido.
O'Reilly Media even tossed in a bogus book announcement: Programming Parrot in a Nutshell.
A few days later, O'Reilly published The Story Behind the Parrot Prank.
The name was eventually adopted by this project.
Considering the JVM is a stack machine VM for statically typed languages, .NET is a stack machine VM for statically-typed languages, and Parrot is a register machine VM built for dynamically-typed languages perhaps it's not so "me too".
Be very careful with your April Fool's jokes. They may someday become reality.
Hurry up and get the languages that target it up on http://shootout.alioth.debian.org/
And of course Parrot is Open Source. The clr is not and jvm was not at the time parrot was started.
This CLR is free software, but then it wasn't released until 2004.
The differences aren't nearly as profound as you might think. Keep in mind that when the software is translated from bytecode to native code via JIT is when the real magic happens.
Since the Java and .NET implementations are further abstracted from the underlying hardware implementation, their VMs have a lot of opportunity to optimize between the registers and the stack. They can even undo certain optimizations and realign their mappings between stack and registers. (The ability to reoptimize is why the JVM is referred to as "Hotspot". It looks carefully for "hot spots" in the code where much of the execution time is being spent, then optimizes the code according to how it has been used at runtime.)
The Parrot VM's use of registers makes it easier to map those registers to the underlying hardware, but it makes it more difficult for the JIT to decide what belongs in a register and what should be moved to stack. The bytecode may force the use of registers that end up not being ideal at runtime. Similarly, the VM may miss the opportunity to move critical stack information to registers, thereby slowing down the execution of the code. The obvious solution is to abstract away from the registers and treat them as part of the stack. From there, the JIT can treat these values holistically. And thus we end up with a solution that looks a lot like a stack-based VM.
Mod grandparent up. Mod parent down.
So, we might actually see something called Perl 6 released before the end of the century? They've only been talking about it for ever, it seems.
The Case for Virtual Register Machines, Brian Davis, Andrew Beatty, Kevin Casey, David Gregg and John Waldron, 12.6.2003, PDF
The paper is a case for interpreted register virtual machines, but it only makes a passing reference to virtual machines with just-in-time compilers.
They must have pulled the nails that held it to its perch!
I find that somewhat typical of beautiful theories. Everything is wonderful with stack based interpreters until someone points out that it borks the branch predictor. Good luck cooking up a telepathic branch predictor. (And you thought your original problem was hard?)
As for the JIT comment, most of the Java code I use on a daily basis (Eclipse, JIRA) suffers from extreme lurch.
Why does it take two minutes to close and reload the same Eclipse workspace? I think the network mandated virus scanner is so busy looking under the JIT compiler's skirt, it can't get anything done. Hardly a panacea.
These "Java moments" are livable, but I wouldn't discourage anyone from trying a different approach.
Tectonic shifts in computing begin with humble first steps like this. I know it was years worth of work, and you had to suffer lots of naysayers along the way. So, great job, and I hope to see less humble moves as we go forward.
Cheers,
Dave
The next goals are outlined here.
Basically, they target one major release every six months, bumping each time the version number by 0.5. The next focus are:
1.5: integration, interoperation, and embedding
2.0: production users
2.5: portability
3.0: independence from other languages (everything is parrot on parrot)
Interestingly, Opera's new ECMAscript engine has a register-based byte-code instruction set.
http://my.opera.com/core/blog/2009/02/04/carakan
Dr Sbaitso, are you back?
--- I am known for the ones who want to find me on the net. Is that a privacy risk or a privilege? One might wonder..
Swapping. The Windows VMM is extremely aggressive, swapping out any memory that hasn't been accessed recently, even if that memory isn't needed by another program. Unfortunately, this plays out badly when the garbage collector comes along and tries to scan the heap. The result is a lot of thrashing.
Linux doesn't have nearly the same difficulties with Java "lurching" as Windows does, because the Linux VMM is a bit more liberal in letting memory hang around. (Though Eclipse is likely to be a bad test case. The SWT framework isn't as optimized on Linux as it is on Windows. Try running Netbeans on both and see the difference.)
If you think about it, there's no conceivable way that slower CPU execution can lead to long, intermittent pauses of the type you describe. Poor Virtual Memory Managers, however, are an exact fit.
Windows VMM has been improperly tuned for years now. Microsoft has not recognized that modern PCs have a LOT more memory, leading to excess swapping. Vista supposedly makes an effort to fix this issue, though I have not personally tested it.
That's because register-based interpreters are faster than stack-based interpreters. Generally speaking, the fewer instructions you run in a bytecode interpreter, the faster it will execute. That is the argument made in the paper posted by mj41 above.
When you throw a JIT into the mix, things change rapidly. You stop being concerned about the interpreter speed and begin worrying more about machine code optimizations. What's good for the goose may be good for the gander, but what's good for the interpreter is not always good for the JIT.
Interestingly, there is only one Javascript JIT in wide distribution at the moment. That is Chrome's V8. Tamarin is also used in Flash 9 & 10 and is expected in future versions of Firefox.
Unfortunately, JITs are much more resource intensive to develop and maintain than interpreters. Thus a small company like Opera isn't going to make a JIT their first priority. A fast interpreter makes a lot more sense from their perspective. Especially when the Javascript engine spends the vast majority of its time in native APIs.
Javascript + Nintendo DSi = DSiCade
n/t
you had me at #!
That doesn't mean a register machine is any worse than a stack machine for JITting. In particular, some of the Dis papers from the Plan 9 research suggest that avoiding unnecessary memory access can improve execution speed as well. The approach they suggest there is clever register allocation with a register-based machine. For example, if you inline function calls, the JIT can reallocate the registers so there's no overhead of even passing parameters and receiving arguments.
how to invest, a novice's guide
The concept must be completely out of my reach. I look at Parrot and think, "OK I can write to the registers. This speeds up code for me on C. But, on C I'm writing to real registers. Parrot is a VM which means I'm writing to virtual registers which then gets translated to machine code." Wouldn't everything get lost in the translation depending on how well the VM is written for the specific arch of the machine Parrot is running on? Also, will the people running the code I'm writing need to have Parrot installed as well as Perl, Python...? I know I have to be misunderstanding the whole thing. That, or Parrot is a lot of overhead for a small increase in speed.
Having to work for a living is the root of all evil.
Ha - this may be the answer to a recent 'Ask Slashdot' article on Cross-Language Code Reuse:
Hope For Multi-Language Programming?
http://ask.slashdot.org/article.pl?sid=09/02/28/037256
From a comment there:
There is one possible bright spot I know of in the multi-language world: the development of things like the Parrot virtual machine, which is intended to be an efficient backend for all dynamic languages, including (but not limited to) Perl 6. It seems unlikely to me that this technical achievement is going to bridge the social barriers between the camps of language advocates, but you never know, maybe I'm underestimating Larry Wall's social engineering skills.
I'd love to have a VM that let me use my old Lisp code, and old Perl code, in a new Java program. ... and there have been similar 'Ask Slashdots' earlier
http://www.google.com/search?q=site:slashdot.org+personal+language+reuse
Quoting post-wash-up lyrics from a long since irrelevant band is symbolic.
Why does it take two minutes to close and reload the same Eclipse workspace? ... ... but lots of people I know, do like it. Also worth considering is the IDE from Oracle.
That is an Eclipse problem, not a Java problem. Eclipse is doing insane amounts of work during start up time, and has an absurd amount of meta data stored in the workspace. The whole idea that an IDE even needs a workspace is so strange
Try using an IDE like CodeGuide, www.omnicore.com. Or if you like it: IDEAs IntellyJ IDE or NetBeans from Sun. I don't really like NetBeans
In daily work CodeGuide e.g. is 100 times faster than Eclipse, but lacks the plugins.
angel'o'sphere
Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.