Компилятор Perl 5.

pypy это JIT. Что-то на тему perl5+JIT гуглится, но ничто не напоминает хоть что-то рабочее.

Вам не нужен перл, поверьте.

perlcc был, сейчас не знаю как он.

просто постучи по клавиатуре раскрытой ладонью от балды, потом кулаком. Получишь сразу и самый нечитаемый и (как следствие) самый быстрый код на перле.

был perlcc, но он никогда толком не работал, и примерно лет пять назад, если не раньше, его выпилили.

получить высокую производительность

а покажи кусок с низкой производительностью

perl изначально создавался как интерпретируемый язык. хочешь канпелять - си в руки.

Нет ли для перла аналога pypy для питон чтобы получить высокую производительность?

В отличие от питона, перл парсит и запускает программу и так быстро. В контексте веб-сервера, mod_perl грузит скрипт один раз и не выгружает до перезапуска всего сервера.

А чтобы перловые приложения грузились быстро надо использовать соответствующие модули. Например, отказаться от Moose в пользу Moo.

Скажи лучше какую задачу ты хочешь решить, а не пытаться решить ее одним известным тебе способом.

Как его можно компилировать, если даже распарсить не получится?

Многие программы как-то медленно запускаются. Типа того же pimpd, хочется же чтобы они не интерпретировались, а компилировались и получить быстрый запуск.

Я там тока что привел пример где на мой взгляд запускает программу не очень быстро. И запуск тем медленнее, чем больше модулей подключено и сложнее код, а хотелось бы скорость запуска такую же или по крайней мере сравнимую со скоростью запуска на си.

Я это спрашиваю не столько для того что мне надо решить конкретную задачу, сколько чтобы узнать есть оно вообще или нет. Щас я на третьем курсе, думаю на какую тему писать диплом. Думаю, если для сего сделать эффективный компилятор, то это многим понравится. Было несколько проектов, правда на perlcc, не помню как оно называлось, но оно практически ничего не компилировало.

Также есть идея перенести некоторые фичи из perl 6, но так чтобы совместимость с perl 5 была на первом месте, то есть ничего не ломая. В rakudo они пошли каким-то странным путем, очередная вандервафля без совместимости с cpan вряд ли будет кому-то нужна, для веба решения на том же руби куда удобнее(и тормознутее).

Можно расположить все модули перла в tmpfs - в итоге сократится время доступа к файлам и их загрузка. Но это все ерунда. Есть staticperl - он создает бинарник со своей виртуальной файловой системой, при этом плюс в скорости загрузки вообще не ощущается, зато прибавляется масса других минусов.

Честно говоря, я не сторонник таких извращений, скомпилировать перловый код, чтобы он быстро запускался. Это означает только одно - кривая архитектура и/или неверно выбранный инструмент для решения задачи. Что, сложно переписать pimpd на си или пропатчить mpd ?

Никто ведь не патчит яву, чтобы она быстрее компилировала код (может и патчат, не знаю) ? Никто не добавляет в си динамическую типизацию на лету, ну, чисто по приколу.

Зато нынче есть масса людей, которые хотят «исправить» перл. Кто-то решил, что пора бы перлу стать второй явой, однако вся прелесть нынешнего тут же исчезнет. Веб-серверов нам мало, есть tomcat, запилим-ка под новый перл на vm и вебсервер perlcat! А че, прикольно, чуваки оценят «скорость» новой системы, а также что она жрет памяти не меньше явы! А то, что надо переписывать весь код никого не волнует; нагнать функционал CGI/PSGI/Plack - да не вопрос, кто-нибудь нафигачит, а мы будет строить новый перл!

И самое печальное, что перл уйдет со своей ниши. Много людей пишут парсеры конфигов/текстов на яве ? Много людей используют perl вместо lua/python в качестве простого и встраиваемого языка ? Задай себе вопрос почему именно так, а не иначе? Может с перлом все нормально, а это мы ненормальные раз пытаемся сделать из перла идеальный компилятор и интерпретатор в одном лице ?

Это к тому, что если решишь писать патчи, не забудь, что перл умеет грузить код/файлы «на лету» через require module, do script_name.

Замечательный текст. Посылаю вам лучи добра.

Если я правильно складываю 2 и 2, но компилятор перла принципиально не возможен: Perl Cannot Be Parsed: A Formal Proof.

То есть я так понял аналог pypy под него написать невозможно? Переписать-то совсем не сложно, там программа простая. staticperl у меня так просто не заработал, так что не могу сказать быстрее оно или медленнее.

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

Это как модная в народе теорема Гёделя о неполноте. Верна только для бесконечных множеств, а что будет на конечных никто даже не задумывался.

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

Ну а чо смеешься? Была идея написать простой, удобный, хорошо документированный интерпретатор/jit компилятор по типу pypy и иже с ним, для питона же как-то написали.

Правда меня вот ещё что останавливает, так это то, что на perl 5 стандарта вроде бы нет, к тому же он постоянно меняется.

Ну а чо смеешься?

Смеюсь? Видимо у вас хрустальный шар сломался.

Была идея написать простой, удобный, хорошо документированный интерпретатор/jit компилятор по типу pypy и иже с ним, для питона же как-то написали

Было много идей, но где результат? Вот когда появится новая пятерка, полностью повторяющая нынешнюю, вот тогда будет интересно. Скорее всего наплодят лишних сущностей, бросят в сильно сыром виде.

Правда меня вот ещё что останавливает, так это то, что на perl 5 стандарта вроде бы нет, к тому же он постоянно меняется.

Зачем вам эти «вроде бы»? Почитайте историю пятерки. Сейчас стандарт есть - это реализация интерпретатора на C. За изменениями можно наблюдать, проект открыт.

То есть я так понял аналог pypy под него написать невозможно?

Теоретически можно, а практически никому не нужно. Объясню просто, динамически подгружаемые модули в перле это не редкость. К счастью и не счастью, они представляют из себя файлы (пусть даже со строчкой XSLoad). С учетом особенностей @INC компиляция кода представляется неэффективным занятием: надо компилировать вообще все, надо научится налету линковать код (а есть модули, которые вообще удаляют все лишнее - функции, переменные и т.п., т.е. делинковать код, поправьте если некорректно выразился). В итоге получится уже не перл, а другой совершенно язык, т.к. он строится будет на иных концепциях.

Иными словами, компилируемый код на перле будет выглядить как miniperl + множество .so'шек для каждого модуля. Не знаю, в чем профит от такого, ибо я не видел ниодной реализации.

Путь «pypy» чреват тем, что будет тоже самое, что в питоне, яве и других языках с генерацией промежуточного байт-кода. Вопрос, зачем? Чем это решение будет лучше? Тем что будет на перле? Тогда зачем ты выбрал перл, если нравится подход с байткодом?

Неужели ты думаешь, что за 25 лет никто не отважился на такие эксперименты? Отважились, только я слышу не те цели у сегодняшних проектов: скорость, удобный ООП, построим новый CPAN. Основная цель должна быть четкой и ясной: делаем аналог полной явы с синтаксисом перла и точка. Вот когда осознаешь, что делаешь клон, да еще и не факт, что он получится хоть чем-то лучше, чем монстр-ява с ее 10+летней человеческой жизнью и овер 10 тыс. летним человеком-часом работы, тогда понимаешь, что врядли кому-то это вообще будет интересно, ну кроме как академических исследований.

Переписать-то совсем не сложно, там программа простая.

Перепеши на си. Уверен, тебя поддержат многие, потому что проблема вхождения перл-программ в дистрибутивы всех линуксов именно в том, что используется перл и CPAN с 10 тыс. активных модулей (всего около 23 тыс).

А судя по описанию pimpd он представляет лучшую замену mpc, и это хорошо.

staticperl у меня так просто не заработал, так что не могу сказать быстрее оно или медленнее.

~/staticperl install
...
~/staticperl perl -e 'print "Hello Perl\n"'

Выполнился ?

Я правильно понял что стандартом является сама реализация? Так я вроде бы о том и говорю что никакой исошки или чего-то такого насколько я знаю нет, разобраться по коду что там должно быть не так-то просто. Будь оно иначе у пятерки было бы столько же реализаций что и у шестерки, по крайней мере народ старался бы. А тут даже подвижек никаких не видно в этом направлении, скорее всего потому что проще перетаскивать фичи из шестерки и писать патчи к тому что есть.

А вот историю почитаю, конечно. Вернее я её читал когда-то, но она уже устарела видимо.

Про то что наплодят сильно лишних сущностей это намек на шестерку? Вроде бы процесс идет к тому что оно более-менее утряслось и движется к релизу. Но оно нереально тормозное и без совместимости с cpan никому(кроме энтузиастов) не нужное. Ладно бы там можно было просто сконвертить как python 2->3, но это вообще уже другой язык. Когда я читал про шестерку думал что там ещё пилят режим совместимости, но на него все положили болт, а жаль. Тогда можно было бы хотя бы попытаться сделать компилер следуя стандарту.

В голову начинает закрадываться мысль не забить ли мне на это дело, либо сделать что-то узкоспециализированное, типа языка для обработки строк(читай той же биоинформатики).

В голову начинает закрадываться мысль не забить ли мне на это дело, либо сделать что-то узкоспециализированное, типа языка для обработки строк(читай той же биоинформатики).

На западе принято поддерживать человека в любых его начинаниях, даже если факты о том, что это ненужно налицо. Так и родился Perl 6, что-то общество получило от него полезное, но судя по всему, цель никогда не будет достигнута. Но мы не на западе :)

Проведи исследования на сколько реально сделать компилятор на перле, задай вопрос на том же perlmonks, напиши авторам perl6, rakudo - спроси насколько реалистично это сделать.

А можно взять сегодняшний перл и с помощью него решить насущные проблемы. Написать xs-модуль, который мало будет уступать сишному коду.

Я правильно понял что стандартом является сама реализация?

Правильно.

[~/.staticperl] >> staticperl perl -e 'print "Hello Perl\n"'
Hello Perl
[~/.staticperl] >> staticperl perl =pimpd2 -ls
Can't locate App/Pimpd.pm in @INC (@INC contains: lib /home/neg/.staticperl/perl/lib .) at /usr/bin/site_perl/pimpd2 line 29.
BEGIN failed--compilation aborted at /usr/bin/site_perl/pimpd2 line 29.
[~/.staticperl] >> l =staticperl
▕ -r-xr-xr-x▏10 hour│  97K│/usr/bin/site_perl/staticperl

Это да. Но вот модули(из cpan) всякие не подхватывает, например вот то. Честно говоря не очень понял смысла ставить его локально, вообще надо просто почитать как с него программы использовать. Собсно то же самое касается и остальных модулей. Для его отдельный «дистрибутив» что ли делать надо?

Для его отдельный «дистрибутив» что ли делать надо?

Да. PERL5LIB у него «зашит» в бинарник и не перезаписывается вообще никак. Делаешь ~/staticperl cpan и ставишь руками нужные модули. А дальше можно собирать на основе того что есть свой бинарник (как приложение, так и бинарник перла) с ограниченным набором модулей. Это удобно для embedded систем, а также удобно разворачивать на серверах :)