Max Home IndustryВерсия 1.7 оптимизирующего компилятора Perl 5 для C/C++ под кодовым названием Tycho была выпущена в начале этого месяца. Проблема, которую пытается решить RPerl, заключается в низкой производительности Perl, достаточной для большинства случаев, но непомерно высокой для области реального времени.
Perl торгует скоростью для гибкости, поскольку он заботится о многих вещах, чтобы программисту не пришлось этого делать, таких как привязка хэшей (термин, который относится к сложной внутренней функциональности), подсчет ссылок, автоматическое преобразование типов, закрытие, автоматическая загрузка и многое другое.
Еще одна проблема, которая не позволяет Perl ускорить свойственный ему процесс компиляции, заключается в том, что он не выдает байт-код, а вместо этого что-то называется Op-деревом. Это дерево операций похоже на AST, но не совсем, поскольку каждый узел дерева операций перегружен сложным набором инструкций
Вместо этого использование байт-кода позволит интерпретировать код Perl с помощью современных виртуальных машин, таких как RPython или LLVM, что приведет к значительному повышению производительности
Однако это сложная задача, поскольку она потребует полного или, по крайней мере, тяжелого переписывания внутренних компонентов Perl, что слишком сложно и отнимает слишком много времени.
Однако именно так поступил Perl 6, решив начать с чистой базы кода и нарушить обратную совместимость, испустив байт-код для MoarVM или JVM. По словам Ларри Уолла, это «Perl 5 сделано правильно», предполагая, что Perl 6-это попытка исправить все ошибки в дизайне Perl 5
Альтернативой является работа с урезанной версией или подмножеством Perl, которые могут быть фактически скомпилированы в C или даже переведены в байт-код.
Это то, что уже происходит с компилятором Perlito, который переводит Perl в Javascript для бэкенда V8 или Perl в Python для бэкенда RPthyon.
Были попытки преобразовать op-дерево Perl в формат байт-кода, а именно с модулями B::Bytecode, но этот байт-код никогда не предназначался для использования в виртуальной машине, а просто для замораживания op-дерева на диск, чтобы его можно было позже загрузить и интерпретировать снова, что дает Perl определенную независимость от платформы.
Ближе всего к переводу собственного кода когда-либо был достигнут perlcc, компилятор perl-to-c, но он страдал от серьезных проблем с надежностью и, наконец, устарел в версии Perl 5.10.
Цель RPerl аналогична цели perlcc — компиляции Perl в код C, но для подмножества, которое может быть статически скомпилировано, следовательно, R для ограниченного Perl.
Таким образом, можно избежать переписывания внутренних компонентов Perl,и вместо этого достигается компромисс между удалением частей с высокой магией, которые не могут быть статически скомпилированы, что обеспечивает гибкость для производительности и позволяет работать только с частями с низкой магией, которые могут быть статически скомпилированы
«высокая магия» относится к наиболее сложным и гибким частям Perl , в то время как «низкая магия» — это те части Perl, которые можно заставить работать быстро
Отсутствие высокой магии означает, что код Perl, написанный для RPerl, не может использовать богатые возможности языка, такие как автоживификация, связанные переменные, большие двоичные объекты, ссылки на код, слабые ссылки, магические значения и т. Д.То, что можно и нельзя делать, задокументировано в «Заповедях Perl с низкой магией».
Добавьте к этой сложности привычку Perl вызывать среду выполнения на этапе компиляции,следовательно,запускать код, результаты которого впоследствии используются в дальнейшей компиляции, и наоборот, и вы увидите, откуда берется цитата «только Perl может анализировать Perl».
Хотя отсутствие высокой магии удаляет функциональность с языка, идея заключается в том,что доменные приложения (научные,математические, игры), которые нуждаются в повышении производительности RPerl, в любом случае не используют эти функции
Тесты показывают впечатляющий прирост производительности. В одном случае для синхронизации реализации алгоритма сортировки пузырьков потребовалось 15 секунд Perl,по сравнению с всего 0,04 секундами с RPerl!
(нажмите, чтобы увеличить)
Помимо повышения производительности, эти улучшения также могут повысить популярность Perl среди компаний, которые в настоящее время могут неохотно принимать его из-за ограничений скорости
Будущее держит мысли о том, чтобы каким-то образом объединить части, которые могут быть статически скомпилированы, с JIT для динамических частей, которые могут быть интерпретированы, а также увеличить охват частей высокой магии
Уилл Брасуэлл, руководитель RPerl, также участвует в тесно связанном проекте P11,который охватывает идею повторного объединения Perl 5 и Perl 6,
Недавнюю презентацию по этому вопросу смотрите в видеопрезентации Google hangouts от 11 апреля на RPerl и Perl11.
В последнем выпуске еженедельника FLOSS Рэндал Шварц и Аарон Ньюкомб представляют часовое видеоинтервью с Уиллом Брасвеллом о RPerl.