RFC: Move build tools to Perl5, developer tools to Perl6

Christoph Otto christoph at mksig.org
Sat Feb 23 04:06:50 UTC 2013


The ops2c-necromancy branch reminds me why we felt the way we did about
ops2c.  Nobody could accuse it of being an elegant or smart tool.  A
proper compiler based on NQP or Rakudo would generally be preferable
but there are a few factors that make it less attractive.



The big one is that modern NQP has a non-trivial setting.  Code can't
just be compiled down to PIR or pbc and treated as a standalone
fakecutable that links against libparrot.so .  If NQP has to be
installed and working before Parrot, NQP or Rakudo's ops can be
bootstrapped, everyone's toolchain becomes much more brittle.  NQP's
ops have been changed in 16 commits so far this month and pm has stated
that we should not assume that NQP/Rakudo's ops will remain relatively
static.  The ops compiler needs to be a tool that works no matter what
state the user's system is in.  P5 is a better foundation for that
purpose because we can safely assume that it's installed and working,
whether the system it's on has an ancient installed Parrot, a broken
NQP or no Parrot at all.



The goals are to reduce dependence on a dead-end tool (NQP-rx) and to
provide a robust ops preprocessor.



Yes, we could decide on a stable-ish NQP version, check in NQP.pir, all
of NQP's stage 2 PIR and its post-processed dynops (and hope that
they're for the right Parrot version), then integrate them with our
build, then make sure that they worked correctly both from Parrot's
build and install directories, then make sure that they didn't conflict
with upstream NQP or ancient NQP-rx when installed
("/usr/local/bin/parrot-nqp-but-not-the-old-one-that-we-already-install
-called-parrot-nqp"?), then make sure that they were regularly updated,
then the deal with upstream NQP changes that break parrot-nqp-not-rx,
then subscribe to the advil of the month club.  I'd rather not go down
that path and it's not immediately clear that it'd be in Parrot's
interest to even accept such a patch, given that we're in a do or die
regarding performance.  I'm not entirely adverse to leaving opsc as
part of the build since ripping it out won't lead to an immediate
performance gain, but moving to NQP proper isn't a good option.



Working on opsc was great but it was a misstep to depend on NQP-rx at
the time.  It's unfortunate, but progress at this point does mean
moving in the opposite direction.



Christoph





On Fri, Feb 22, 2013, at 4:16, Vasily Chekalkin wrote:

Hello.

Moving opsc back to perl5 is the biggest mistake you can make. Upgrade
opsc to modern nqp is the way.

Keywords: JIT, compile-time optimisations, PBC emitting, kill PIR with
fire.

--
Bacek



On Fri, Feb 22, 2013 at 3:11 PM, Christoph Otto
<[1]christoph at mksig.org> wrote:

On Thu, Feb 21, 2013, at 20:02, Brian Gernhardt wrote:

>

> On Feb 21, 2013, at 10:04 PM, Jimmy Zhuo <[2]jimmy.zhuo at gmail.com>
wrote:

>

> > Well, the original front is not written by PIR, it's by C.

>

> And whiteknight rewrote it in Winxed because it was clearer and
faster.

>

>
[3]http://whiteknight.github.com/2011/01/20/parrot_in_parrot_new_fronte
nd.html

> [4]http://whiteknight.github.com/2011/08/08/frontend_parrot2.html

> [5]http://irclog.perlgeek.de/parrot/2011-08-19#i_4300881

>

>

> I don't think the frontend is _the_ reason to keep Winxed around.
The

> reason to keep it in core is so that I never have to write a single
line

> of PIR again.

>

> ~~ benabik

That's the biggest thing winxed has going for it and the reason why

there's no reason for it to go away.  Its runtime requirements are much

less complicated than full nqp and it can compile code down to (mostly)

standalone PIR.  If you've ever written straight PIR, you'll know why

that's a good thing.  I'm not saying that its use should be expanded,

largely because the path to a Parrot that continues to exist 24 months

from now involves cutting things out rather than adding them, but
winxed

isn't hurting anything and could potentially help us later if we're
able

to boost Parrot's performance sufficiently.



I'm looking at much of the current work as a warm-up before the main

event.  Ripping out opsc will reduce Parrot's dependence on nqp-rx but

the real speed gain is profiling and optimizing, especially in
improving

pcc (as has been mentioned).  Other things are easier to do and

relatively harmless, but only profiling and optimizing for nqp are what

will get Parrot into an attractive state.



Christoph

_______________________________________________

[6]http://lists.parrot.org/mailman/listinfo/parrot-dev

References

1. mailto:christoph at mksig.org
2. mailto:jimmy.zhuo at gmail.com
3. http://whiteknight.github.com/2011/01/20/parrot_in_parrot_new_frontend.html
4. http://whiteknight.github.com/2011/08/08/frontend_parrot2.html
5. http://irclog.perlgeek.de/parrot/2011-08-19#i_4300881
6. http://lists.parrot.org/mailman/listinfo/parrot-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.parrot.org/pipermail/parrot-dev/attachments/20130222/0855a4f8/attachment-0001.html>


More information about the parrot-dev mailing list