Parrot и Rakudo - перезагрузка

Как говорилось в "Parrot: PIR, PASM и L1", разработчики Parrot вынуждены переписать всю низкоуровневую часть проекта, неизменным останется лишь PIR и PGE.

Но, как показали разработчики Rakudo в Hague grant work: the new regex engine and NQP, PGE не слишком удобен на практике. Они собираются отказаться от него в пользу NQP-rx. Соответственно, PIR ждет та же учесть, которая постигла PASM с появлением первого.

Таким образом, по моему вменению, приобретя колоссальный опыт, разработчики Parrot и Rakudo вернулись почти к той же точке, с которой начинали.
Но не все так печально. Главное есть люди, есть идеи, есть решимость.

Да наступить "Рождество" в Perl мире!

Parrot: Request Tracker и Trac Tracker

Разработчики Parrot отказались от использования Request Tracker в пользу Trac Tracker. А на душе остался осадок: ведь первый написан на Perl, а второй на Python.

Как-то не очень выглядит ситуация, когда разработчика виртуальной машины, предназначенной в первую очередь для языка Perl, уходят с инструмента, написанного на Perl, тем более, что этот инструмент весьма не плох.

Но может в Trac есть нечто, о чем я не знаю?

Perl - когда наступит Рождество

• Parrot 2 - начало 2010 года (по материалом Parrot рассылки для разработчиков)


• Perl 6 - весна 2010 года (объявлено на YAPC::Europe 2009)


• Parrot 3 - начало 2011 года

Parrot: PIR, PASM и L1

PASM слишком низкоуровневый для человека и
слишком высокоуровневый для машины.

Часть критического кода, используемого виртуальной машиной Parrot, написана на PIR, а часть на С. Постоянное переключение между этими слоями: PASM (PIR) регистрами и C стеком, - существенно снижает производительность Parrot.

Поэтому сейчас ведутся работы по переписыванию некоторых частей с C на PIR. Это уже было сделано для подсистемы ввода-вывода, и что, как показала практика, повысило ее производительность.

Однако не все, что хотелось, можно переписать с C на PIR.

В связи с этим в среде разработчиков Parrot ведутся обсуждения о создании внутреннего языка специального назначения, известного под рабочим названием L1. Это язык будет максимально простым и быстрым.
Если провести аналогию с процессорами, то L1 - это аналог микрокода, на котором реализованы CISC команды поверх RICS ядра процессоров таких как x86.

По аналогии с PIR (PASM) L1 будет компилироваться в байткод L1BC, который будет исполнятся подсистемой, условно называемой nanoparrot.

Не надо пугаться, обычной PBC никуда не денется! Он будет на лету транслироваться в L1. Так что разработчики компиляторов языков высокого уровня ничего и не заметят, кроме прироста производительности! :-)

В заключении можно сказать, что:
PASM - слишком низкоуровневый для человека и появился PIR.
PASM - слишком высокоуровневый для машины и создается L1.

P.S.
Ссылки по теме:
https://trac.parrot.org/parrot/wiki/L1Recap
http://wknight8111.blogspot.com

Скорость Rakudo

Как говорилось в предыдущей заметке пришло время посмотреть на Rakudo (Parrot реализация Perl6) с практической точки зрения.

Собираем свежие Parrot и Rakudo (2009-06-30) и запускаем:

 > time ./perl6 -e 'say "Just another Perl Hacker"'
 Just another Perl Hacker
 3.180u 0.203s 0:04.19 80.6%     4979+37881k 0+10io 0pf+0w

Что-же так долго?!

Посмотрим NQP - Not Quite Perl (6):

 > cd compilers/nqp
 > time ../../parrot nqp.pbc -e 'say("Just another Perl Hacker")'
 Just another Perl Hacker
 0.518u 0.031s 0:00.70 77.1%     31+5715k 0+10io 0pf+0w

И Perl5:

 > time perl -e ' print "Just another Perl Hacker\n"'
 Just another Perl Hacker
 0.000u 0.010s 0:00.01 100.0%    0+0k 0+0io 0pf+0w

Подробное, исследование показало, что основное время занимает загрузка самого perl6.pir. Так что, вероятно, следует направить дальнейшие поиски причины медлительности Rakudo непосредственно в сторону Parrot.

Parrot 2009 - взгляд с 2002 года

Parrot 2009 - a 2002 point of view

Недавно на своем стареньком компьютере обнаружил parrot 2002 года (версия 0.0.9)!

Да, много воды утекло. Тогда parrot ничего не знал о PASM, а PBC создавался при помощи perl:

 perl assemble.pl -o foo.pbc foo.pasm
 parrot foo.pbc

Конечно этот байт-код не понятен текущей версии parrot (1.3.0).

Да что говорить о PBC, если даже PASM того времени уже большей частью не совместим с современным. Например, полностью убран "классический" вариант вызова подпрограмм - следует использовать стиль передачи продолжений (Continuation-passing style), что позволило писать более компактно.

Убрали также пользовательский стек и стеки регистров, вместо них следует использовать Array PMC.

Полностью изменились Parrot Calling Conventions. Что сделало Parrot совершенно другим, а не тем, которым я знал его в 2002 году.

Текущие состояние parrot позволяет сказать:
Да здравствуют продолжения и сопрограммы!
Да здравствуют легковесные user-level потоки!
Да здравствуют возможность dataflow execution!

И самое главное, появился PIR (Parrot Intermediate Representation), за которым прячутся все тонкости работы с подпрограммами, и с которым отпадает необходимость жонглировать регистрами.

На PASM уже никто не пишет и его не развивают. Все используют PIR!

PIR - это:
+ subroutine linkage
+ named, optional, and slurpy parameters
+ method calls
+ multimethod dispatch
+ register allocation
+ macros

Имеется также Parrot Compiler Tools - набор инструментов для написание компиляторов с различных языков. Rakudo уже давно использует его. Вероятно, скоро и сам Parrot не будет нуждаться в perl.

Parrot набрал силу. Это уже не ребенок, а отрок.
Настала пора посмотреть в сторону Perl6 (Rakudo) с практической точки зрения.