Delayed decision
Хочется рассказать об оптимизациях, которые откладывают выигрыши до лучших времён. Их можно увидеть во многих системах, например, можно посчитать какую-то статистику или выучить, как правильно располагать код. Сложность таких оптимизаций в том, что они должны "продать" будущее. Какого-то единого формата как их находить особо нет, кроме как приближать данные о прошлом в настоящее. Если бы кто-то умел это делать лучше остальных идеально, у нас бы не было HFT и подобных компаний, занимающихся этим 24/7.
Такие вещи происходят от самых верхнеуровневых решений до самых низких. Приведём пример верхнеуровневого решения: кеширование.
Вы никогда не знаете, какой элемент лучше всего вытащить при переполнении кеша. Точнее знаете -- тот, который будет позже всех использован в будущем. Такой кеш называют идеальным кешом. Против него хорошо можно бенчмаркать прошлые данные, надеясь, что новые будут очень похожими. На фоне всяких идеальных кешей начали возникать теории и полным полно стратегий вытеснения -- LRU, WLRU, GDSF, ARC. Все со своими интересностями, а насколько мы может приблизиться к оптимальному результату. Оптимальный результат называют OPT, Belady's и тд, если вдруг хочется посмотреть. Что делать? В целом бенчмаркать, особо больше ничего, можно динамически что-то считать, можно машинное обучение пытаться применить. Единственное -- решение должно приниматься достаточно быстро, это же кеши. Плюс в том, что вы знаете верхнюю границу идеального результата. Старайтесь подумать, а что такое идеально тут.
Более локальные решения происходят даже на уровне аллокаторов. В TCMalloc при аллокации блока мы префетчим ещё 1 блок того же размера, потому что это лучше продаёт будущее несмотря на то, что ухудшает микробенчмарки. С одной стороны это достаточно просто и не так уж и дорого, но с другой, чтобы такое найти, надо было потратить годы и подробно смотреть на паттерны доступа.
Здесь особо нет правил, есть стратегии как можно находить такие моменты, одна из основных -- пробовать сотни различных конфигураций. Потратьте время, чтобы эти конфигурации было легко проверять. Удивительные результаты моей карьеры я не особо понимаю глубинно, лишь интуитивно методом проб и ошибок. Это что-то достаточно уникальное для software как мне кажется. Как слишком много всего, что работает.
Хочется рассказать об оптимизациях, которые откладывают выигрыши до лучших времён. Их можно увидеть во многих системах, например, можно посчитать какую-то статистику или выучить, как правильно располагать код. Сложность таких оптимизаций в том, что они должны "продать" будущее. Какого-то единого формата как их находить особо нет, кроме как приближать данные о прошлом в настоящее. Если бы кто-то умел это делать лучше остальных идеально, у нас бы не было HFT и подобных компаний, занимающихся этим 24/7.
Такие вещи происходят от самых верхнеуровневых решений до самых низких. Приведём пример верхнеуровневого решения: кеширование.
Вы никогда не знаете, какой элемент лучше всего вытащить при переполнении кеша. Точнее знаете -- тот, который будет позже всех использован в будущем. Такой кеш называют идеальным кешом. Против него хорошо можно бенчмаркать прошлые данные, надеясь, что новые будут очень похожими. На фоне всяких идеальных кешей начали возникать теории и полным полно стратегий вытеснения -- LRU, WLRU, GDSF, ARC. Все со своими интересностями, а насколько мы может приблизиться к оптимальному результату. Оптимальный результат называют OPT, Belady's и тд, если вдруг хочется посмотреть. Что делать? В целом бенчмаркать, особо больше ничего, можно динамически что-то считать, можно машинное обучение пытаться применить. Единственное -- решение должно приниматься достаточно быстро, это же кеши. Плюс в том, что вы знаете верхнюю границу идеального результата. Старайтесь подумать, а что такое идеально тут.
Более локальные решения происходят даже на уровне аллокаторов. В TCMalloc при аллокации блока мы префетчим ещё 1 блок того же размера, потому что это лучше продаёт будущее несмотря на то, что ухудшает микробенчмарки. С одной стороны это достаточно просто и не так уж и дорого, но с другой, чтобы такое найти, надо было потратить годы и подробно смотреть на паттерны доступа.
Здесь особо нет правил, есть стратегии как можно находить такие моменты, одна из основных -- пробовать сотни различных конфигураций. Потратьте время, чтобы эти конфигурации было легко проверять. Удивительные результаты моей карьеры я не особо понимаю глубинно, лишь интуитивно методом проб и ошибок. Это что-то достаточно уникальное для software как мне кажется. Как слишком много всего, что работает.