It's quite possible. I even listed a (slightly incomplete) plan to
make it happen. The problem is that there's no NQP/Rakudo performance
improvement to be had for that extra work, so the biggest benefit is
the nice feeling of using a current NQP.
Christoph
On Sat, Feb 23, 2013, at 3:59, Vasily Chekalkin wrote:
Hello.
In the nutshell you are explaining that NQP can't be implemented in
NQP. Sorry, but "bootstrap problem" was already solved. Checking in
of generated C code is equivalent of checking in PIR.
Bacek.
On 23 Feb 2013 15:07, "Christoph Otto" <[1]christ...@mksig.org> wrote:
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
<[2]christ...@mksig.org> wrote:
On Thu, Feb 21, 2013, at 20:02, Brian Gernhardt wrote:
>
> On Feb 21, 2013, at 10:04 PM, Jimmy Zhuo <[3]jimmy.z...@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.
>
>
[4]http://whiteknight.github.com/2011/01/20/parrot_in_parrot_new_fronte
nd.html
> [5]http://whiteknight.github.com/2011/08/08/frontend_parrot2.html
> [6]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
_______________________________________________
[7]http://lists.parrot.org/mailman/listinfo/parrot-dev
_______________________________________________
[8]http://lists.parrot.org/mailman/listinfo/parrot-dev
References
1. mailto:christ...@mksig.org
2. mailto:christ...@mksig.org
3. mailto:jimmy.z...@gmail.com
4. http://whiteknight.github.com/2011/01/20/parrot_in_parrot_new_frontend.html
5. http://whiteknight.github.com/2011/08/08/frontend_parrot2.html
6. http://irclog.perlgeek.de/parrot/2011-08-19#i_4300881
7. http://lists.parrot.org/mailman/listinfo/parrot-dev
8. http://lists.parrot.org/mailman/listinfo/parrot-dev
_______________________________________________
http://lists.parrot.org/mailman/listinfo/parrot-dev
