Идея в том, что "последовательный поиск в отсортированном массиве" идет по значениям "двоичного дерева" для определенного уровня. Поэтому это можно в данном контексте назвать двоичным поиском.
В статье выше есть пример
[40|80]
/ | \
[10|20] [50|60] [90|100]
Вот для этого примера последовательный поиск идет сначала для значений 40, 80. Потом на уровень ниже и т.д.
Это старый подход, когда volatile использовался для предотвращения оптимизаций компилятором. Но это было валидно, до того как memory model была формализована для С и С++.
Тоже напишу про мой опыт - был я не самый опытный пользователь (года это 98-00) и нам продали Pentium 66 разогнанный до 100 (об это я узнал сильно позже). Были из-за этого постоянные проблемы с вылетами и зависаниями.
Так вот, на этом компе стабильно работала только Windows 95 и 98 - стабильно в том смысле, что не разваливалась после зависаний. Все остальные - OS/2 Warp, разные линуксы - либо не работали после установки, либо просто не могли установиться.
Не очень понятно, как уменьшение размера на 0.06% так сильно влияет на скорость загрузки. У вас условно была библиотека 300Мб и осталась примерно столько же. Так все таки - за счет чего такой прирост производительности?
Крутая статья, спасибо!
Идея в том, что "последовательный поиск в отсортированном массиве" идет по значениям "двоичного дерева" для определенного уровня. Поэтому это можно в данном контексте назвать двоичным поиском.
В статье выше есть пример
Вот для этого примера последовательный поиск идет сначала для значений 40, 80. Потом на уровень ниже и т.д.
В 3.15 размер будет больше - gh-133059: Increase PYNSMALLPOSINTS size by dg-pb · Pull Request #133160 · python/cpython
Размер кеша в новых версиях поменялся
Спасибо, интересно!
Не знал про счетчики Морриса - спасибо!
Уточню, volatile необходимо использовать когда значение может измениться из вне, например, при работе с портами.
Атомики дают такие же гарантии, даже больше.
Это старый подход, когда volatile использовался для предотвращения оптимизаций компилятором. Но это было валидно, до того как memory model была формализована для С и С++.
Неожиданно, но приятно! Спасибо!
Тоже напишу про мой опыт - был я не самый опытный пользователь (года это 98-00) и нам продали Pentium 66 разогнанный до 100 (об это я узнал сильно позже). Были из-за этого постоянные проблемы с вылетами и зависаниями.
Так вот, на этом компе стабильно работала только Windows 95 и 98 - стабильно в том смысле, что не разваливалась после зависаний. Все остальные - OS/2 Warp, разные линуксы - либо не работали после установки, либо просто не могли установиться.
Хорошее дело, отличный разбор!
За ложку дегтя спасибо! Столкнулся с этим, но не разобрался в причинах.
Очень интересно, спасибо!
Я понимаю разницу. Автор поменял название статьи - в оригинале было - как уменьшить кодовую базу.
В текущем названии вопросов нет.
Статья интересная (без шуток) - спасибо!
Но все таки - как уменьшить кодовую базу? Потому что, например, ваш пример с дешаблонизацией кодовую базу только увеличит.
Спасибо что и иллюстрации поправили.
неопределенное
Ну и качество иллюстраций в статье просто потрясающее.
Я не ставлю под сомнение вашу честность :)
Просто совершенно не очевидно стоит ли игра свеч и масштабируется ли ваш опыт за пределы вашего проекта.
Не очень понятно, как уменьшение размера на 0.06% так сильно влияет на скорость загрузки. У вас условно была библиотека 300Мб и осталась примерно столько же. Так все таки - за счет чего такой прирост производительности?
Это напоминание о моей глупости - я думал я понимаю как работает GIL, а оказалось не понимаю. Будет повод разобраться глубже.