Поговорим про sbcl, например

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

Ага, я версию под dragonflybsd сделал, правда без потоков. Там вообще какое-то закрытое общество, а в mailing lists dragonfly'я, наоборот, пообсуждали. А сейчас, сидя в туалете, у меня появилась идея, почему потоки не работают.

Но одно дело может и не нужный dragonfly, а другое дело это. И к тому же mv более кодеристый кодер

Кто-то из мастодонтов в мейллисте собирался (или просто на это сетовал, не помню) маркеры «грязных» областей с mprotect на что-то более разумное переделать, дабы гранулярность меньше была. Без этого от HP толку мало: весь прибыток в скорости от уменьшения TLB miss и менее пухлого VMA уходит на сканирование грязной двухмегабайтной страницы, и ещё сверху вагон с тележкой.

И патчить уже ничего не надо, в ядре появились transparent huge pages, оно само взлетит, если процесс ммапит количество памяти, кратное размеру HP. Ну только этот момент в SBCL/Linux поправить, и всё.

Кстати, вопрос для образования: а почему SBCL оперирует целыми страницами? Их как-то проще перемещать, чем более мелкие куски?

Кстати, вопрос для образования: а почему SBCL оперирует целыми страницами? Их как-то проще перемещать, чем более мелкие куски?

Атрибуты доступа страницы используются в механизме работы сборщика мусора. В конце цикла сборки вся память пула помечается, как недоступная для чтения и записи. При дальнейшей работе софта первое обращение к странице вызывает сегфолт, который отлавливается рантаймом, страничке ставятся read-write атрибуты. При следующем цикле сборки мусора у всех страничек пула просматриваются атрибуты доступа, и если они не read-write, то данные в них не трогались, и объекты в этой страничке сборщику можно не обрабатывать.

Плюсы: никакого оверхеда для SBCL (не нужно встраивать «грязные» маркеры), простая логика.

Минусы: оверхед для ядра, раздутые цепочки страничек, гранулярность слишком большая (в «попавшей» страничке может быть тронут только один объект, но буду просканированы все), трудности с использованием HP. А для типичного лиспософта, использующего SBCL, памяти надо много, и HP там очень в тему.

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

Вопрос касается создания standalone бинарников. Сабж я представляю как программу которая работает, оперируя, скомпилированными бинарными сущностями инструкций, которые подаёт исполнительной системе. Сабж - реализация компилятор очень динамичного языка и поэтому при создании бинарника вкладывает в него свой образ с рантаймом и всем инструментарием компилятора. Это весьма кстати при создании мощный программ-метапрограмм и здесь как-бы проблем нет. Но из малой популярности cl следует, что на практике подобные программы и их задачи редки и преобладают те задачи, где всё добро вложенное сабжем в исполняемый образ становится оверхедом. Одно дело при указании определённой опции, а также функции main для исполняемого бинарника скормить все ненужные этой функции main lisp-сущности сборщику мусора. Другое дело - определить каким-то образом, что main - элементарнейшая программа, которая линкуется с достаточно простыми функциями, в которых макросы серьёзной кодогенерацией не занимаются (знаете ли, такие программы на лиспе писать тоже удобно). Т.е. практически важное тело программы - кучка бинарных сущностей, которым компилятор для работы не нужен и можно их, перелинковав, упаковать в этакий хорошо оптимизированный исполняемый файл. Конечно это всё после указания пользователем опций и деклараций, что возможность загрузить swank и всё похачить не нужна. Ну вот, насколько это возможно?

Нужно на Clojure фигачить!

Был патч для sbcl который такое делал. Коммерческие реализации в основном этим и живут.

Где? Когда? Он попал в основную ветку?

По моему вот это. Давно. Нет и после каких-то изменений внури sbcl он вобще неработает. Ключевое слово был.

В лиспворксе tree shaker есть, этим и занимается.

Где тут оверхед? Тебе памяти что ли жалко?

которым компилятор для работы не нужен

Я б удивился, если бы ты показал прогу, где он нужен. Зато есть clos (который, наверно только, заинтегрирован с лиспом так, что его не выцарапать, стандартная библиотека итд, которые тоже есть в образе

Я б удивился, если бы ты показал прогу, где он нужен. Зато есть clos (который, наверно только, заинтегрирован с лиспом так, что его не выцарапать, стандартная библиотека итд, которые тоже есть в образе

В LW из-под шейкера лишний код со свистом улетает, аж диву даёшься.

А профит-то в этом есть кроме того, что образ меньше? Просто памяти-то сейчас никому не жалко. А во всяких встраиваемых вещах ситуация неоднозначная: для каких-то CL вообще не подойдет, а где-то «встраиваемая система» - это прям такой неслабый компьютер ;)

Ща вот подумал, что в sbcl должен быть способ сохранить некоторые объекты в образ локально в статическую память (для профита производительности). А вот фиг, пишет, что cheneygc is unsupported on this platform (у меня бздя).

Это к тому, что purify is a no-op on platforms using the generational garbage collector (x86, x86-64, ppc).

Жаль

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

А профит-то в этом есть кроме того, что образ меньше? Просто памяти-то сейчас никому не жалко.

Не памяти, размер на диске. Пересылать 70-90 мб. чушку иногда бывает накладно. Размер в памяти и так все больше от toplevel-а зависит. На небольших задачах в памяти будет 1-5 мб. от 40-мегового образа.

Пересылать 70-90 мб. чушку иногда бывает накладно.

Да ладно прям. К тому же, зачем пересылать образы?

На небольших задачах в памяти будет 1-5 мб. от 40-мегового образа.

40 мегов и будет на sbcl. Иначе что вообще бы в образе хранилось, в этих (40 - 5) мб?

К тому же, зачем пересылать образы?

Собирать на месте долго и черевато.

Иначе что вообще бы в образе хранилось, в этих (40 - 5) мб?

Компилятор c оптимизациями , CLOS с извращенями, Loop и format в всей своей многоваринтности. Для уже скомпилиированого и правильно (!) сохраненого в образ кода это нужно в многих случаях не целиком и лежит на всякий случай.

А, я тебя не понял, ты имеешь в виду именно твоего кода там мегабайт?

Собирать на месте долго и черевато.

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