Во время работы в Headlands Technologies мне посчастливилось написать несколько утилит для упрощения создания высокопроизводительного кода на C++. Эта статья предлагает обобщенный обзор одной из этих утилит — OutOfLine. Начнём с поясняющего примера. Предположим, у вас есть система, которая имеет дело с большим количеством объектов файловой системы. Это могут быть обыкновенные файлы, именованные UNIX сокеты или пайпы. По какой-то причине вы открываете много файловых дескрипторов при старте, затем интенсивно с ними работаете, а в конце закрываете дескрипторы и удаляете ссылки на файлы (прим. пер. имеется в виду функция unlink). Первоначальный (упрощённый) вариант может выглядеть так: И это хороший, логически обоснованный дизайн. Он полагается на RAII для автоматического освобождения дескриптора и удаления ссылки. Можно создать большой массив таких объектов, поработать с ними, а когда массив прекратит существование, объекты сами очистят все, что было нужно в процессе работы. Но что насчёт производительности? Предположим, fd используется очень часто, а path только при удалении объекта. Сейчас массив состоит из объектов размером 40 байт, но часто используются только 4 байта. Значит, будет больше промахов в кеше, поскольку нужно "пропускать" 90% данных. Одним из частых решений такой проблемы является переход от массива структур к структуре массивов. Это обеспечит желаемую производительность, но ценой отказа от RAII. Есть ли вариант, сочетающий преимущества обоих подходов? Простым компромиссом может быть замена std::string размером 32 байта на std::unique_ptr<std::string>, размер которого только 8 байт. Это позволит уменьшить размер нашего объекта с 40 байт до 16 байт, что является большим достижением. Но это решение по прежнему проигрывает использованию нескольких массивов. OutOfLine — это инструмент позволяющий без отказа от RAII полностью переместить редко используемые (cold) поля вовне объекта. OutOfLine используется в качестве CRTP базового класса, поэтому первым аргументом шаблона должен быть дочерний класс. Второй аргумент — тип редко используемых (холодных) данных, которые связаны с часто используемым (основным) объектом. Так что же из себя представляет этот класс? Базовая идея реализации заключается в использовании глобального ассоциативного контейнера, который сопоставляет указатели на основные объекты и указатели на объекты содержащие холодные данные. OutOfLine может быть использован с любым типом холодных данных, экземпляр которых создается и связывается с основным объектом автоматически. Удаление основного объекта влечет автоматическое удаление связанного холодного объекта: При перемещении (move constructor/move assignment operator) основного объекта, соответствующий ему холодный объект будет автоматически связан с новым основным объектом-преемником. Как следствие, не следует обращаться к холодным данным перемещённого (moved-from) объекта. В приведенном примере реализации OutOfLine сделан некопируемым для простоты. При необходимости операции копирования легко добавить, в них достаточно лишь создать и связать копию холодного объекта. Теперь, чтобы это было действительно полезно, хорошо бы иметь доступ к холодным данным. При наследовании от OutOfLine класс получает константный и неконстантный методы cold(): Они возвращают соответствующий тип ссылки на холодные данные. Вот почти и все. Такой вариант UnlinkingFD будет иметь размер 4 байта, предоставит дружественный по отношению к кешу доступ к полю fd и сохранит преимущества RAII. Вся работа, связанная с жизненным циклом объекта, полностью автоматизирована. Когда основной часто используемый объект перемещается, редко используемые холодные данные перемещаются вместе с ним. Когда основной объект удаляется, удаляется и соответствующий ему холодный объект. Иногда, однако, ваши данные сговариваются, чтобы усложнить вам жизнь — и вы сталкиваетесь с ситуацией в которой основные данные должны быть созданы первыми. Например, они нужны для конструирования холодных данных. Появляется необходимость создавать объекты в обратном порядке относительного того, что предлагает OutOfLine. Для таких случаев нам пригодится "запасной ход" для контроля порядка инициализации и деинициализации. Это ещё один конструктор OutOfLine, который можно использовать в дочерних классах, он принимает тег типа TwoPhaseInit. Если создать OutOfLine таким образом, то холодные данные не будут инициализированы, а объект останется наполовину сконструированным. Для завершения двухфазного конструирования нужно вызвать метод init_cold_data (передав в него аргументы необходимые для создания объекта типа ColdData). Помните, что нельзя вызывать .cold() у объекта, холодные данные которого еще не инициализированы. По аналогии, холодные данные можно удалить досрочно, до выполнения деструктора ~OutOfLine, вызвав release_cold_data. Вот теперь все. Итак, что эти 29 строчек кода нам дают? Они представляют собой ещё один возможный компромисс между производительностью и простотой использования. В случаях когда у вас есть объект, часть членов которого используется значительно чаще других, OutOfLine может послужить легким в эксплуатации способом оптимизации кеша, ценой значительного замедления доступа к редко используемым данным. Мы смогли применить эту технику в нескольких местах — довольно часто возникает потребность дополнить интенсивно используемые рабочие данные дополнительными метаданными, которые необходимы при завершении работы, в редких или неожиданных ситуациях. Будь то информация о пользователях установивших соединение, торговом терминале с которого пришел заказ, или дескриптор аппаратного ускорителя, занятого обработкой биржевых данных — OutOfLine сохранит кеш чистым, когда вы находитесь в критической части вычислений (critical path). Я подготовил тест, чтобы вы могли увидеть и оценить разницу. Я получил примерно 10-ти кратное ускорение при использовании OutOfLine. Очевидно, что этот тест разработан для демонстрации потенциала OutOfLine, однако он также показывает насколько существенное влияние на производительность способна оказать оптимизация кеша, равно как и то, что OutOfLine позволяет эту оптимизацию получить. Поддержание кеша свободным от редко используемых данных может обеспечить сложно измеряемое комплексное улучшение показателей остального кода. Как и всегда при оптимизации, доверяйте измерениям больше чем предположениям, тем не менее надеюсь что OutOfLine окажется полезным инструментом в вашей копилке утилит. Код, приведенный в статье, служит для демонcтрации идеи и нерепрезентативен по отношению к продакшн коду. Программист C++/Scala/Go