Compilers Targetting Parrot | Hacker News Reader

Compilers Targetting Parrot

wknight8111.blogspot.com

32 pointsdraegtun16 comments

This returns me to the question I asked here: http://news.ycombinator.com/item?id=1361382

If I'm compiling, what should I target?

I could target LLVM, C, some high-level compilable langauge, or now, Parrot.

There doesn't seem to be any cogent, clear, knowledgable discussion of the various features and merits. I suppose asking for one is like asking "which language is best," and the answer will always be "it depends."

I've used Parrot as a target for a language implementation. It supports a lot of stuff out of the box (even multimethods!) and it's quite easy to get started. It also provides tools to help you build a compiler, like a parser generator integrated with the rest of the system. The problem is that right now it is quite slow, slower than Perl or Python, and a bit buggy. It would be an ideal target platform for dynamic languages otherwise. I wouldn't use it for something needed in production at the moment.

> a bit buggy

Anything off the top of your head that you've been bit by?

Threading just doesn't work (it's going to be rewritten from scratch). Sometimes there are segfaults within managed code and sometimes there are memory leaks. Sometimes an assertion in the VM fails, causing the program to halt with a stack trace. A few releases ago the compiler of Parrot's assembly language reported wrong line numbers in error messages, but this has been fixed.

All those "sometimes" seems to suggest that Parrot is much more than a bit buggy.

A memory leak is one thing, but segfaults and assertion failures... Down to brass tacks: is this thing usable in its current state?

> Down to brass tacks: is this thing usable in its current state?

Experimentation and quick and dirty prototypes? Yes. Production code? No.

For the more static languages, LLVM seems hot and well-supported right now. There is a rich tradition of compiling via C, with good and bad results.

Gambit Scheme compiles via C and is one of the fastest Scheme systems around, with good interoperability via C. The Glassgow Haskell Compiler can also compile via C, but that's, AFAIK, an unmaintainable mess (search for "evil mangler").

Whatever seems like the most fun to you, of course.

Also: there are many more possible compilation targets than ones you list.

Yes, exactly, and that's why I was asking for recommendations and suggestions. I have been largely unable to find anything that gives a sensible overview of the technology and the various trade-offs.

Hence my question, although it seems like this is the wrong audience/forum.

There is no technical answer. OK, there are terrible answers, but not everyone agrees about which those are. In the end making a compiler is a world-affecting act: both to your own, and to those of others. You have to decide socially which group you want to associate yourself with, what kind of world you want.

Parrot's been claiming that it's slow and incomplete now, but a solution to that is just around the corner for a few years.

Maybe that's true, but I think that'd be the main concern of any compiler writer thinking of targeting it. It's not a mature platform with known pros and cons, unlike the JVM or LLVM.

I hope it all turns out for the best and Parrot delivers on its promises. But I can see why e.g. the PHP team isn't rushing to target it given the state of its native languages.

These things take a long time. Heck, it might even be a bit early to call LLVM mature. Sure, it supports a C and C++ compiler, but I don't think it has anything production-ready for much else.

It's in extensive use by Apple on the iPhone and in XCode, and outside Apple. The JVM is also well understood and widely deployed.

By comparison the Parrot project with the widest use is Rakudo, which is still just at a testing stage. Maybe there's some larger user of Parrot that I haven't heard about, so correct me if I'm wrong.

Lua 5.2 has been feature complete on Parrot for years. Like LLVM and the JVM, we'll keep tuning and improving and fixing bugs and adding features to make language implementation easier, but the correlation between "maturity" and "use" is strong.

That's interesting. Are there any recent benchmarks of Lua on Parrot v.s. LuaJIT? The only thing I could find was this from 2007 where it was ~2 orders of magnitude slower: http://www.nntp.perl.org/group/perl.perl6.internals/2007/09/...

The URL to the benchmark script was broken so I couldn't run it.

Don't get me wrong, I think Parrot's very neat. But I could see why compiler implementors would be sceptical of it since it's not feature complete, and seemingly not very optimized. So there's a lot of unknowns.

fyi - with the JDK7 - the JVM can also target the LLVM (for JIT'ing) through Project Zero (http://openjdk.java.net/projects/zero/)

One Bytecode to rule them all, One Bytecode to find them, One Bytecodeto bring them all and in the darkness bind them

:-)

Reply on news.ycombinator.com