Разборки с перлом
Давно хотел посмотреть, что у перла внутри. Но стоило глянуть на XS-исходники, как все желание трусливо пряталось за спину. А сегодня, наконец, встала задача, которую откладывать было нельзя. Надо было переписать узкое место в Очень Важной Программе на C.
Оказалось, что нужно было прочитать введение perlguts, справочник perlapi, соглашение о вызове подпрограмм perlcall и описание того "клея", который будет работать шлюзом между моей функцией на C и перлом, адаптируя параметры и возвращаемые значения.
Разбираться с XSUB так и не захотелось, нашел интересный интерфейс SWIG (www.swig.org) и модуль Inline. SWIG - вещь хорошая, но я ни разу не видел ни одного модуля, который с этой системой работал. Ставить на своем софте не стал, и посмотрел в сторону Inline::C.
Inline::C представляет собой интерфейс к комплиятору на C и прицеплялку бинарника к перлу через DynaLoader. При компиляции модуля Inline::C проверяет с помощью хэша наличие уже откомпилированной версии C-программы, если она отсутствует, вызывает компилятор. В случае ошибок компиляции не забывает вызвать die. В общем, одно удовольствие.
Внутренности подпрограммы писать надо на том самом perlapi. Выяснил много интимных подробностей о том, как работает менеджер памяти перла. Например, стало понятно, почему операция shift работает быстро O(1), а unshift медленно O(N). Названия функций API выглядят страшно SvROK, но на самом деле, это все аббревиатуры, причем с четкой логикой, по которой можно понять назначение любой функции по ее названию. Подумалось, что если бы перл писался в стиле софта для windows, то та же функция называлась бы ScalarValueReferenceOk, а исходники занимали бы в 2 раза больше места.
В результате Программа отлично заработала уже на C, все интерфейсы корректно работают, даже все юнит-тесты прошла с первого раза.
Общее впечатление - избыточность API. Хотя, похоже, что это все только для повышения производительности и удобочитаемости кода, который его использует. В сравнении с LUA, перл - просто монстр, хотя и обладающий на уровне ядра массой возможностей.
Оказалось, что нужно было прочитать введение perlguts, справочник perlapi, соглашение о вызове подпрограмм perlcall и описание того "клея", который будет работать шлюзом между моей функцией на C и перлом, адаптируя параметры и возвращаемые значения.
Разбираться с XSUB так и не захотелось, нашел интересный интерфейс SWIG (www.swig.org) и модуль Inline. SWIG - вещь хорошая, но я ни разу не видел ни одного модуля, который с этой системой работал. Ставить на своем софте не стал, и посмотрел в сторону Inline::C.
Inline::C представляет собой интерфейс к комплиятору на C и прицеплялку бинарника к перлу через DynaLoader. При компиляции модуля Inline::C проверяет с помощью хэша наличие уже откомпилированной версии C-программы, если она отсутствует, вызывает компилятор. В случае ошибок компиляции не забывает вызвать die. В общем, одно удовольствие.
Внутренности подпрограммы писать надо на том самом perlapi. Выяснил много интимных подробностей о том, как работает менеджер памяти перла. Например, стало понятно, почему операция shift работает быстро O(1), а unshift медленно O(N). Названия функций API выглядят страшно SvROK, но на самом деле, это все аббревиатуры, причем с четкой логикой, по которой можно понять назначение любой функции по ее названию. Подумалось, что если бы перл писался в стиле софта для windows, то та же функция называлась бы ScalarValueReferenceOk, а исходники занимали бы в 2 раза больше места.
В результате Программа отлично заработала уже на C, все интерфейсы корректно работают, даже все юнит-тесты прошла с первого раза.
Общее впечатление - избыточность API. Хотя, похоже, что это все только для повышения производительности и удобочитаемости кода, который его использует. В сравнении с LUA, перл - просто монстр, хотя и обладающий на уровне ядра массой возможностей.