Lisp двоичный размер - программирование

Как я заинтересован в искусственном интеллекте, я недавно решил попробовать Lisp. После компиляции основного основного приложения с общим компилятором Lisp sbcl Я заметил, что полученный двоичный файл был очень большим (около 43 МБ). Меня интересует причина этого. Является ли эта распространенная проблема для (общего) Lisp и какова техническая основа такого поведения?

Ответ 1

В реализациях Common Lisp существует несколько различных архитектур:

Переводчик
механизм байтового кода (пример CLISP)
с помощью компилятора C (пример ECL)
собственный компилятор кода (SBCL, LispWorks, Clozure CL)

Обычно для интерпретатора и механизма байтового кода используется наименьший объем памяти. CLISP, таким образом, очень мала. SBCL OTOH генерирует относительно большой собственный код.

Во-вторых, существует несколько способов создания приложений:

сохранение изображения
сохранение оптимизированного изображения
компиляция кода C

Плюс еще более похоже на компиляцию в DLL.

SBCL в основном выполняет 1. Он выгружает память, содержащую данные и код, и включает в себя время выполнения. Таким образом, все, что у вас есть в запущенной системе (документация, ссылки на исходный код, списки аргументов, имена символов, информация об отладке, сам компилятор...), будет сбрасываться в изображение + время выполнения. Кроме того, генерируемый собственный код SBCL велик, в памяти выполнения есть много информации о кодах, а SBCL включает в себя все свои функции (включая компилятор).

Во время разработки часто работают (s/ed) с такими неоптимизированными приложениями или изображениями (с внешней средой выполнения), чтобы сэкономить время для загрузки кода и данных. Я сам использовал его с изображениями размером более 100 МБ.

LispWorks, например, делает 1 и 2. У него есть процесс доставки, где вы можете выборочно удалять файлы (например, документацию, некоторые функции, такие как компилятор, ссылки на источники,...). Это также использует древовидный шейкер, который может удалить неиспользуемые функции.

Оптимизация изображения также может означать, чтобы написать его сжатым способом и распаковать его при запуске. SBCL позволяет это, например.

Вариант 3 был выполнен в прошлом, но в настоящее время он не используется (кроме некоторых специализированных инструментов и приложений). Thinlisp, Stella, CycL,... являются такими инструментами доставки. Раньше для такого инструмента был также коммерческий поставщик (но этого больше не существует, IIRC последним владельцем его является Oracle). Обновление: фактически mocl, недавний генератор приложений Common Lisp для iOS и Android делает это. Он принимает большое подмножество Common Lisp и компилирует его в небольшие автономные мобильные приложения. Например, на iOS он генерирует компактный код C для Apple, снабженного компилятором C.