Во-первых, надо понять, что я вообще понимаю под перфом, ведь понятие очень широкое. Так как мои интересы лежат в районе эффективности распределённых систем, то перф для меня — всё, что позволяет делать эти распределённые системы быстрыми. В зависимости от системы вам может понадобиться решать проблемы разного характера. Где-то это про сделать ручку для обработки данных батчами, чтобы по сети поменьше ходить. Где-то научиться нормально пользоваться БДшкой. Где-то надо почаще попадать в L1 кеш и префетчить данные. А где-то вообще выбросить всё что есть и сделать заново в другой парадигме. Вся широта проблем меня занимает. В разной мере в разное время.
На самом деле я бы расширил понятие перфа до слова эффективность. И разговаривал бы ещё про то, что такое эффективность команды или всех разработчиков на стеке Х. Что такое developer experience. Почему унификация помогает средне-большой компании экономить деньги и вот это всё. Тут конечно надо быть осторожным и не уйти в степь вида «дайте-ка я ещё померяю, кто у меня в команде больше коммитов делает и буду им оценочку на ревью повыше ставить». Я за здравое понимание «эффективности разработки», а не за вот это корпоративное обмазаться метриками и всем в нос им потом тыкать.
Но такие вещи я постараюсь в тег не заносить, чтобы не обманывать хардкорных си плюс плюс подписчиков.
Во-вторых, начать тег я хочу с концепции. Концепция хорошо показана в докладе с CppCon 2014: Data-Oriented Design and C++ от Mike Acton. Это даже тот самый классический доклад, который всем показывают по теме.
Я его смотрел когда-то пару лет назад. Смотрел не очень осознанно. А сейчас как-то естественным образом пришёл к понимаю подобного направления и случайно ещё наткнулся на доклад, который вроде про то самое.
Суть хорошо показана в первой части (где-то первые 30 минут, дальше начинаются примеры кода). Кратко её сформулировать можно так: данные это всё. Основная проблема: при решении задач мы часто оперируем ментальными моделями, которые хорошо выглядят с точки зрения нашего человеческого понимания объектов, трансформаций данных и решения проблемы «переложить объект слева направо». Но так как компуктеры работают не так, как мы думаем, необходимо взять себя в руки и подумать про то, как данные должны трансформироваться (фактически единственно важный вопрос при проектировании). И из этого ответа у вас вытекают все возможности решений.
Фактически весь перф это про data oriented design. Ведь вам не нужно ускорять то, что согласно данным не нужно ускорять. И нужно то, что нужно. Вам нужно знать, как ваши данные выглядят, какие там взаимосвязи. Как они используются. Желательно знать как можно больше. Вы хотите решать задачу для наиболее common случая, потому что это статистически принесёт больше пользы.
Короче знайте свои данные.
Есть ещё доклад Vittorio Romeo «More Speed & Simplicity: Practical Data-Oriented Design in C++». Несмотря на какой-то околоискуственный пример, тут неплохо показана попытка сдвига мышления от привычной OOP парадигмы в сторону DOD.
Особенно, пусть это и не относится особенно к делу, красиво задвинул в конце про адекватный интерфейс для SoA.
У меня вот прям после некоторого количества информации по этой теме какой-то сдвиг в голове случился, и некоторые вещи обрели новый, более устойчивый смысл, а некоторые его радикально потеряли. Будем наблюдать, какие плоды это в итоге принесёт.
@thisnotes. Patreon.
Спасибо Artyom Garkavy и niki4smirn.
На правах мегапатрона послание подписчикам от Artyom Garkavy:
Try it today: google.com.