#python #common
Метод, которым python решает проблемы с ромбовидным наследованием.
https://ru.wikipedia.org/wiki/C3-линеаризация
Метод, которым python решает проблемы с ромбовидным наследованием.
https://ru.wikipedia.org/wiki/C3-линеаризация
#common #python
Не знаю, насколько вам заходит читать про сборщики мусора, но осталось совсем чуть-чуть : )
Собсна python GC.
Стандартный CPython использует подсчёт ссылок и сборщик мусора с поколениями [habr]. Второй необходим в силу того, что стандартный алгоритм подсчёта ссылок не учитывает циклы, возникающие в процессе жизнедеятельности программы.
Всего тут три поколения, для которых можно задавать границы того, сколько сборок мусора должен пережить объект, чтобы переместиться в следующее поколение.
Для разрешения циклов используется факт, что циклы могут возникнуть лишь при использовании различных контейнеров. Для каждого объекта внутри контейнера производится следующая операция: для всех объектов внутри этого контейнера, на которые ссылается зафиксированный объект, количество ссылок уменьшается на 1. Для всех объектов, счётчик ссылок которых остался больше 1, считается, что на них ссылаются объекты снаружи контейнера. Эти объекты кикаем из множества кандидатов на удаление. Также убираем из этого множества все объекты, на которые ссылаются только что убраные и т.д. Оставшиеся во множестве объекты можно удалять.
Подобный подход встречается и в других языках.
Например, в Kotlin/Native (это не обычный котлин, прошу заметить) такой выбор был сделан из-за простоты метода. Однако недавно от подсчёта ссылок решили отказаться, потому что с ним не получается достигнуть достаточной эффективности.
В отличие от подсчёта ссылок, сборщик мусора можно отключать.
Это может быть полезно для эффективности приложения в случае, если вы уверены, что приложение не создаёт циклов, или же готовы на некоторые утечки памяти в угоду скорости. Получается некоторый аналог неудаляющего аллокатора.
Другой интерпретатор python PyPy имеет cборщик мусора с другой моделью поведения. Incminimark -- инкрементальный трассирующий сборщик мусора с двумя поколениями. Основная настройка -- размер молодого поколения (nursery).
Большие объекты создаётся вне поколений.
Когда-то в PyPy вообще было 6 разных сборщиков, но решили от них отказаться. Ещё пару недель назад у меня была ссылка на старую документацию с пруфами, но сегодня по ней уже ничего нет. Вот так быстро мир меняется.
И CPython, и PyPy предоставляют множество возможностей для полуавтоматического управления сборкой мусора. Есть возможности вручную запускать отдельные минорные/мажорные сборки, временно включать/отключать сборщик мусора,
получать подробную информацию о поведении программы при сборке и т.д.
[1]. Как Instagram отключил gc и получил профит.
[2]. Потом что-то покрутили и вернули.
Не знаю, насколько вам заходит читать про сборщики мусора, но осталось совсем чуть-чуть : )
Собсна python GC.
Стандартный CPython использует подсчёт ссылок и сборщик мусора с поколениями [habr]. Второй необходим в силу того, что стандартный алгоритм подсчёта ссылок не учитывает циклы, возникающие в процессе жизнедеятельности программы.
Всего тут три поколения, для которых можно задавать границы того, сколько сборок мусора должен пережить объект, чтобы переместиться в следующее поколение.
Для разрешения циклов используется факт, что циклы могут возникнуть лишь при использовании различных контейнеров. Для каждого объекта внутри контейнера производится следующая операция: для всех объектов внутри этого контейнера, на которые ссылается зафиксированный объект, количество ссылок уменьшается на 1. Для всех объектов, счётчик ссылок которых остался больше 1, считается, что на них ссылаются объекты снаружи контейнера. Эти объекты кикаем из множества кандидатов на удаление. Также убираем из этого множества все объекты, на которые ссылаются только что убраные и т.д. Оставшиеся во множестве объекты можно удалять.
Подобный подход встречается и в других языках.
Например, в Kotlin/Native (это не обычный котлин, прошу заметить) такой выбор был сделан из-за простоты метода. Однако недавно от подсчёта ссылок решили отказаться, потому что с ним не получается достигнуть достаточной эффективности.
В отличие от подсчёта ссылок, сборщик мусора можно отключать.
Это может быть полезно для эффективности приложения в случае, если вы уверены, что приложение не создаёт циклов, или же готовы на некоторые утечки памяти в угоду скорости. Получается некоторый аналог неудаляющего аллокатора.
Другой интерпретатор python PyPy имеет cборщик мусора с другой моделью поведения. Incminimark -- инкрементальный трассирующий сборщик мусора с двумя поколениями. Основная настройка -- размер молодого поколения (nursery).
Большие объекты создаётся вне поколений.
Когда-то в PyPy вообще было 6 разных сборщиков, но решили от них отказаться. Ещё пару недель назад у меня была ссылка на старую документацию с пруфами, но сегодня по ней уже ничего нет. Вот так быстро мир меняется.
И CPython, и PyPy предоставляют множество возможностей для полуавтоматического управления сборкой мусора. Есть возможности вручную запускать отдельные минорные/мажорные сборки, временно включать/отключать сборщик мусора,
получать подробную информацию о поведении программы при сборке и т.д.
[1]. Как Instagram отключил gc и получил профит.
[2]. Потом что-то покрутили и вернули.
👍5❤1
#cpp #python #highload
0. [fact] В С++ можно брать указатели на goto метки.
godbolt.
ChatGpt говорит, что это только у GCC, но с Clang тоже компилится.
Можно, но не нужно❌
1. [talk] Why Is My C++ Build So Slow? Compilation Profiling and Visualization.
Samuel Приветт рассказывает про проблему медленной компиляции, как её детектить и что с ней делать.
Интересно как-нибудь потыкаться, насколько сложно упомянутые им инструменты притягиваются в большие промышленные проекты вроде нашего. Может получится пост!
2. [article] Python's new t-strings.
Одной из (насколько я понял) крутейших фичей в python 3.14 являются t-strings. В статье кратко про то, что это такое и зачем может быть нужно.
Я пока не прям въехал с точки зрения недомашних примеров. Верю, что опыт всё порешает. Если вам ждать не хочется, вот репозиторий из статьи с большим кол-вом примеров.
Рядышком докину статью про то, какие фичи в новом питоне появляются. Или можете официальную документацию посмотреть.
3. [article] Improving Pinterest Search Relevance Using Large Language Models.
Чувак из Pinterest рассказывают про то, как применяют LLM для улучшения качества поиска. Если кратко, то
- на основе разметки выдачи на релевантность людьми учат огромную тяжёлую LLM предсказывать релевантность выдачи
- на основе тяжёлой LLM учат student LLM, чтобы использовать её в онлайне (т.к. она легче и инфересится быстрее)
Ну и всё. Там они ещё порассказывали, какие LLM использовали и какие результаты получились в их экспериментах.
Я не поклонник LLM во всех дырах. И потому статья местами воспринимается как что-то, что написали, потому что надо было показать, какие все передовые. Но может я скептик.
0. [fact] В С++ можно брать указатели на goto метки.
void computed_goto_example(int state) {
static void* dispatch[] = { &&State0, &&State1, &&State2 };
goto *dispatch[state];
State0:
//
return;
State1:
//
return;
State2:
//
return;
}
godbolt.
ChatGpt говорит, что это только у GCC, но с Clang тоже компилится.
Можно, но не нужно
1. [talk] Why Is My C++ Build So Slow? Compilation Profiling and Visualization.
Samuel Приветт рассказывает про проблему медленной компиляции, как её детектить и что с ней делать.
Интересно как-нибудь потыкаться, насколько сложно упомянутые им инструменты притягиваются в большие промышленные проекты вроде нашего. Может получится пост!
2. [article] Python's new t-strings.
Одной из (насколько я понял) крутейших фичей в python 3.14 являются t-strings. В статье кратко про то, что это такое и зачем может быть нужно.
Я пока не прям въехал с точки зрения недомашних примеров. Верю, что опыт всё порешает. Если вам ждать не хочется, вот репозиторий из статьи с большим кол-вом примеров.
Рядышком докину статью про то, какие фичи в новом питоне появляются. Или можете официальную документацию посмотреть.
Если вы посмотрите в официальную доку, найдёте секцию под названием And now for something completely different. В ней есть какой-то факт про число pi. Ссылка, которую я вам оставил, является последней актуальной версией это странички и заканчивается на a7. Можно посмотреть предыдущие версии страницы, подекрементив чиселко и почитать другие факты про pi. Прикольно.
3. [article] Improving Pinterest Search Relevance Using Large Language Models.
Чувак из Pinterest рассказывают про то, как применяют LLM для улучшения качества поиска. Если кратко, то
- на основе разметки выдачи на релевантность людьми учат огромную тяжёлую LLM предсказывать релевантность выдачи
- на основе тяжёлой LLM учат student LLM, чтобы использовать её в онлайне (т.к. она легче и инфересится быстрее)
Ну и всё. Там они ещё порассказывали, какие LLM использовали и какие результаты получились в их экспериментах.
Я не поклонник LLM во всех дырах. И потому статья местами воспринимается как что-то, что написали, потому что надо было показать, какие все передовые. Но может я скептик.
Please open Telegram to view this post
VIEW IN TELEGRAM
🤯5👍4🔥2