CL standalone application.

> Для меня это пока тёмный лес. Написал HelloWorld, захотел сделать бинарь, а тут такие сложности.

Наоборот, все очень просто. Набиваешь в REPL код своего HelloWorld. Проверяешь, что работает. А затем тут же в REPL набиваешь ccl:save-application с нужными параметрами. И тогда полный слепок текущей системы будет записан как один (практически независимый) бинарь.

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

Такой бинарник запускается, кстати, быстро. У него мало зависимостей.

>Тут: компиляция->запуск->выполнение(компиляция?)
Нет никакого циклы.
Есть код, которые по совместительству, данные. Есть компилятор.
Вызываем компилятор когда хотим, запускаем скомпилированное тоже когда хотим.

> И всё-таки непривычно для компилируемого языка. Привычно это или бинарь или байт код, но не исходники. Они настолько быстро компилятся?

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

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

это eval

> И всё-таки непривычно для компилируемого языка.

Да ну? А JSP, или ASP.NET?

Привычно это или бинарь или байт код, но не исходники. Они настолько быстро компилятся?

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

Для закрытого софта можно купить коммерческий лисп.

Для закрытого коммерческого софта, даже для десктопов, заботиться о 30 мегабайтах рантайма во времена копеечных гигабайтов оперативной памяти это смешно.

> Опять таки для закрытого софта исходники мягко говоря не совсем подходят

Вполне себе подходят.

размер образа внушает почтение, хоть и сжатого.

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

>Да оставь ты их в покое, эти исходники. Никто не заставляет их таскать. Компилируй сколько хочешь заранее, распространяй бинарники.
Эх, а байт код был-бы меньшего размера и платформонезависимым.

> Эх, а байт код был-бы меньшего размера и платформонезависимым.

Да кого колышет платформонезависимость? Тебе лениво упаковать несколько разных бинарников для разных платформ? Тебя вообще волнует размер бинарников?

Если так, то пользуйся реализациями Лиспа для JVM или .NET. Их полно. Например, есть ABCL.

для JVM лучше тогда Clojure взять, она лучше к нему приспособлена

> Эх, а байт код был-бы меньшего размера и платформонезависимым.

Байт код зависит от виртуальной машины, которой может и не быть на компьютере. Посмотри как распространяются явовские аппликухи - почти все коммерческие приложения тащат вместе с собою в инсталяторе jre или jdk, а это больше, чем ужатый образ лисп-системы. Делают так, кстати, чтобы быть еще уверенным, что версия jre именно та, которая нужна. Что для линукса, что для винды. Так что, это еще большой вопрос, где получится меньше инсталяционный пакет.

А в дотнете кросс-платформенности нет и не будет...

>Если так, то пользуйся реализациями Лиспа для JVM или .NET. Их полно. Например, есть ABCL.
Когда есть выбор, это хорошо.

И ещё компиляция как-то кэшируется, чтобы при следующем запуске не компилировать всё заново?

> И ещё компиляция как-то кэшируется, чтобы при следующем запуске не компилировать всё заново?

Ты вообще о чем? Компилируешь ты один раз. Что там кешировать?

> И ещё компиляция как-то кэшируется,

чтобы при следующем запуске не компилировать всё заново?

Да, конечно.

Ты вообще о чем? Компилируешь ты один раз. Что там кешировать?

Это ты о чём?

>Объясните пожалуйста как сделать standalone приложение в clojure и sbcl. Что оно из себя представляет и как согласуется с тем, что лисп заточен больше на интерпретатор.

Зря ты меня не послушал и продолжаешь открывать рот...

> Такой образ и загружается быстрее, чем куча DLL-ок.

4.2

Приплыли. mmap уже стал дороже динамической линковки? Ты откуда упал и чем стукнулся?

В процессе работы программы это действительно жёсткий оверхед, так как происходит перезагрузка кэша кода. Если это делается очень редко, то ещё допустимо.

Чего-о-о....?

> mmap уже стал дороже динамической линковки?

1. А как по-твоему реализуется динамическая линковка в нынешнем гну-окружении? ;)

2. Всегда ли прилинкованная либа загружается в память? ;)

Алё, а кто ссылки патчить будет при динамической линковке? Одного mmap-а мало.

А ты погугли ;)))

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

> В процессе работы программы это действительно жёсткий оверхед, так как происходит перезагрузка кэша кода. Если это делается очень редко, то ещё допустимо.

Чего-о-о....?

Уже разобрались, что для CL это не актуально. А имел я ввиду самомодифицирующийся код, кэш кода не любит этого.

Я знаю, как elf устроен. Это медленнее, чем загрузка образа.

Устройство эльфа ортогонально реализации динамической линковки.

А сама линковка в ld сделана чертовски красиво. ))

Это медленнее

Прувы, прувы.

>Всегда ли прилинкованная либа загружается в память?

Всегда ли с диска в память целиком читается примапленный файл?

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

Свежая ссылка по теме: http://www.xach.com/lisp/buildapp/

Уже разобрались, что для CL это не актуально. А имел я ввиду самомодифицирующийся код, кэш кода не любит этого.

О каком кэше идёт речь? Процессора?

>О каком кэше идёт речь? Процессора?
Да.

Да.

Тогда рекомендую дочитать книжку, которую не дочитали.

О какой литературе идет речь?

а зачем, например?

>Тогда рекомендую дочитать книжку, которую не дочитали.
Это я вам советую почитать например интеловские мануалы, раз вы считаете, что модификация кода, не сказывается на производительности кэша кода процессора.

Это я вам советую почитать например интеловские мануалы, раз вы считаете, что модификация кода, не сказывается на производительности кэша кода процессора.

Читал. Там написано, что L1C при каждом переключении контекста сдувается. Как часто в лисповой программе маш.код меняется - уже неважно. Плохие компиляторы, не умеющие так же чётко писать на ассемблере, как я, чудовищно больше ущерба производительности наносят, чем «модификация кода».

>Там написано, что L1C при каждом переключении контекста сдувается.
Раз так, то хотите сказать, что кэш кода не нужен? Зачем все эти предсказания потока кода? Всё и так шуршит.

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

Раз так, то хотите сказать, что кэш кода не нужен?

Вы читать умеете?

>Вы читать умеете?
Вроде, но я не понял к чему здесь про загрязнение кеша при переключении контекста.

Вроде, но я не понял к чему здесь про загрязнение кеша при переключении контекста.

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

>К тому, что нереально редкое для процессора обновление кода в каком-то процессе совершенно ничего не значит по сравнению с весьма частым переключением контекста (и соотв. инвалидацией L1) в современной многозадачной системе.
Согласен, я по-началу не понял принцип компиляции лиспа, думал там постоянно компиляция/модификация проводится.