Это старый подход, когда volatile использовался для предотвращения оптимизаций компилятором. Но это было валидно, до того как memory model была формализована для С и С++.
Тоже напишу про мой опыт - был я не самый опытный пользователь (года это 98-00) и нам продали Pentium 66 разогнанный до 100 (об это я узнал сильно позже). Были из-за этого постоянные проблемы с вылетами и зависаниями.
Так вот, на этом компе стабильно работала только Windows 95 и 98 - стабильно в том смысле, что не разваливалась после зависаний. Все остальные - OS/2 Warp, разные линуксы - либо не работали после установки, либо просто не могли установиться.
Не очень понятно, как уменьшение размера на 0.06% так сильно влияет на скорость загрузки. У вас условно была библиотека 300Мб и осталась примерно столько же. Так все таки - за счет чего такой прирост производительности?
Есть важный нюанс: планировщик операционной системы сам решает, когда выделить потокам время на выполнение. При этом GIL в CPython заставляет поток освобождать его примерно раз в 5 миллисекунд.
* For the longest time, the eval breaker check would happen
* frequently, every 5 or so times through the loop, regardless
* of what instruction ran last or what would run next. Then, in
* early 2021 (gh-18334, commit 4958f5d), we switched to checking
* the eval breaker less frequently, by hard-coding the check to
* specific places in the eval loop (e.g. certain instructions).
* The intent then was to check after returning from calls
* and on the back edges of loops.
*
* In addition to being more efficient, that approach keeps
* the eval loop from running arbitrary code between instructions
* that don't handle that well. (See gh-74174.)
*
* Currently, the eval breaker check happens on back edges in
* the control flow graph, which pretty much applies to all loops,
* and most calls.
* (See bytecodes.c for exact information.)
Не знал про счетчики Морриса - спасибо!
Уточню, volatile необходимо использовать когда значение может измениться из вне, например, при работе с портами.
Атомики дают такие же гарантии, даже больше.
Это старый подход, когда volatile использовался для предотвращения оптимизаций компилятором. Но это было валидно, до того как memory model была формализована для С и С++.
Неожиданно, но приятно! Спасибо!
Тоже напишу про мой опыт - был я не самый опытный пользователь (года это 98-00) и нам продали Pentium 66 разогнанный до 100 (об это я узнал сильно позже). Были из-за этого постоянные проблемы с вылетами и зависаниями.
Так вот, на этом компе стабильно работала только Windows 95 и 98 - стабильно в том смысле, что не разваливалась после зависаний. Все остальные - OS/2 Warp, разные линуксы - либо не работали после установки, либо просто не могли установиться.
Хорошее дело, отличный разбор!
За ложку дегтя спасибо! Столкнулся с этим, но не разобрался в причинах.
Очень интересно, спасибо!
Я понимаю разницу. Автор поменял название статьи - в оригинале было - как уменьшить кодовую базу.
В текущем названии вопросов нет.
Статья интересная (без шуток) - спасибо!
Но все таки - как уменьшить кодовую базу? Потому что, например, ваш пример с дешаблонизацией кодовую базу только увеличит.
Спасибо что и иллюстрации поправили.
неопределенное
Ну и качество иллюстраций в статье просто потрясающее.
Я не ставлю под сомнение вашу честность :)
Просто совершенно не очевидно стоит ли игра свеч и масштабируется ли ваш опыт за пределы вашего проекта.
Не очень понятно, как уменьшение размера на 0.06% так сильно влияет на скорость загрузки. У вас условно была библиотека 300Мб и осталась примерно столько же. Так все таки - за счет чего такой прирост производительности?
Это напоминание о моей глупости - я думал я понимаю как работает GIL, а оказалось не понимаю. Будет повод разобраться глубже.
Спасибо!
Спасибо!
Спасибо организаторам за крутую конфу, а коллегам за очень интересные доклады! Узнал много нового!
Спасибо, было интересно!
Хотел бы добавить комментарий - не стоит забывать, что в случае
gc.set_debug(gc.DEBUG_LEAK)весь мусор уедет вgc.garbageи там и останется.