Во время работы в Headlands Technologies мне посчастливилось написать несколько утилит для упрощения создания высокопроизводительного кода на C++. Эта статья предлагает обобщенный обзор одной из этих утилит — OutOfLine.

Начнём с поясняющего примера. Предположим, у вас есть система, которая имеет дело с большим количеством объектов файловой системы. Это могут быть обыкновенные файлы, именованные UNIX сокеты или пайпы. По какой-то причине вы открываете много файловых дескрипторов при старте, затем интенсивно с ними работаете, а в конце закрываете дескрипторы и удаляете ссылки на файлы (прим. пер. имеется в виду функция unlink).

Первоначальный (упрощённый) вариант может выглядеть так:

class UnlinkingFD {
  std::string path;
 public:
  int fd;

  UnlinkingFD(const std::string& p) : path(p) {
    fd = open(p.c_str(), O_RDWR, 0);
  }
  ~UnlinkingFD() { close(fd); unlink(path.c_str()); }
  UnlinkingFD(const UnlinkingFD&) = delete;
};

И это хороший, логически обоснованный дизайн. Он полагается на RAII для автоматического освобождения дескриптора и удаления ссылки. Можно создать большой массив таких объектов, поработать с ними, а когда массив прекратит существование, объекты сами очистят все, что было нужно в процессе работы.

Но что насчёт производительности? Предположим, fd используется очень часто, а path только при удалении объекта. Сейчас массив состоит из объектов размером 40 байт, но часто используются только 4 байта. Значит, будет больше промахов в кеше, поскольку нужно "пропускать" 90% данных.

Одним из частых решений такой проблемы является переход от массива структур к структуре массивов. Это обеспечит желаемую производительность, но ценой отказа от RAII. Есть ли вариант, сочетающий преимущества обоих подходов?

Простым компромиссом может быть замена std::string размером 32 байта на std::unique_ptr<std::string>, размер которого только 8 байт. Это позволит уменьшить размер нашего объекта с 40 байт до 16 байт, что является большим достижением. Но это решение по прежнему проигрывает использованию нескольких массивов.

OutOfLine — это инструмент позволяющий без отказа от RAII полностью переместить редко используемые (cold) поля вовне объекта. OutOfLine используется в качестве CRTP базового класса, поэтому первым аргументом шаблона должен быть дочерний класс. Второй аргумент — тип редко используемых (холодных) данных, которые связаны с часто используемым (основным) объектом.

struct UnlinkingFD : private OutOfLine<UnlinkingFD, std::string> {
  int fd;

  UnlinkingFD(const std::string& p) : OutOfLine<UnlinkingFD, std::string>(p) {
    fd = open(p.c_str(), O_RDWR, 0);
  }
  ~UnlinkingFD();
  UnlinkingFD(const UnlinkingFD&) = delete;
};

Так что же из себя представляет этот класс?

template <class FastData, class ColdData>
class OutOfLine {

Базовая идея реализации заключается в использовании глобального ассоциативного контейнера, который сопоставляет указатели на основные объекты и указатели на объекты содержащие холодные данные.

  inline static std::map<OutOfLine const*, std::unique_ptr<ColdData>> global_map_;

OutOfLine может быть использован с любым типом холодных данных, экземпляр которых создается и связывается с основным объектом автоматически.

  template <class... TArgs>
  explicit OutOfLine(TArgs&&... args) {
    global_map_[this] = std::make_unique<ColdData>(std::forward<TArgs>(args)...);
  }

Удаление основного объекта влечет автоматическое удаление связанного холодного объекта:

  ~OutOfLine() { global_map_.erase(this); }

При перемещении (move constructor/move assignment operator) основного объекта, соответствующий ему холодный объект будет автоматически связан с новым основным объектом-преемником. Как следствие, не следует обращаться к холодным данным перемещённого (moved-from) объекта.

  explicit OutOfLine(OutOfLine&& other) { *this = other; }
  OutOfLine& operator=(OutOfLine&& other) {
    global_map_[this] = std::move(global_map_[&other]);
    return *this;
  }

В приведенном примере реализации OutOfLine сделан некопируемым для простоты. При необходимости операции копирования легко добавить, в них достаточно лишь создать и связать копию холодного объекта.

  OutOfLine(OutOfLine const&) = delete;
  OutOfLine& operator=(OutOfLine const&) = delete;

Теперь, чтобы это было действительно полезно, хорошо бы иметь доступ к холодным данным. При наследовании от OutOfLine класс получает константный и неконстантный методы cold():

  ColdData& cold() noexcept { return *global_map_[this]; }
  ColdData const& cold() const noexcept { return *global_map_[this]; }

Они возвращают соответствующий тип ссылки на холодные данные.

Вот почти и все. Такой вариант UnlinkingFD будет иметь размер 4 байта, предоставит дружественный по отношению к кешу доступ к полю fd и сохранит преимущества RAII. Вся работа, связанная с жизненным циклом объекта, полностью автоматизирована. Когда основной часто используемый объект перемещается, редко используемые холодные данные перемещаются вместе с ним. Когда основной объект удаляется, удаляется и соответствующий ему холодный объект.

Иногда, однако, ваши данные сговариваются, чтобы усложнить вам жизнь — и вы сталкиваетесь с ситуацией в которой основные данные должны быть созданы первыми. Например, они нужны для конструирования холодных данных. Появляется необходимость создавать объекты в обратном порядке относительного того, что предлагает OutOfLine. Для таких случаев нам пригодится "запасной ход" для контроля порядка инициализации и деинициализации.

  struct TwoPhaseInit {};
  OutOfLine(TwoPhaseInit){}
  template <class... TArgs>
  void init_cold_data(TArgs&&... args) {
    global_map_.find(this)->second = std::make_unique<ColdData>(std::forward<TArgs>(args)...);
  }
  void release_cold_data() { global_map_[this].reset(); }

Это ещё один конструктор OutOfLine, который можно использовать в дочерних классах, он принимает тег типа TwoPhaseInit. Если создать OutOfLine таким образом, то холодные данные не будут инициализированы, а объект останется наполовину сконструированным. Для завершения двухфазного конструирования нужно вызвать метод init_cold_data (передав в него аргументы необходимые для создания объекта типа ColdData). Помните, что нельзя вызывать .cold() у объекта, холодные данные которого еще не инициализированы. По аналогии, холодные данные можно удалить досрочно, до выполнения деструктора ~OutOfLine, вызвав release_cold_data.

}; // end of class OutOfLine

Вот теперь все. Итак, что эти 29 строчек кода нам дают? Они представляют собой ещё один возможный компромисс между производительностью и простотой использования. В случаях когда у вас есть объект, часть членов которого используется значительно чаще других, OutOfLine может послужить легким в эксплуатации способом оптимизации кеша, ценой значительного замедления доступа к редко используемым данным.

Мы смогли применить эту технику в нескольких местах — довольно часто возникает потребность дополнить интенсивно используемые рабочие данные дополнительными метаданными, которые необходимы при завершении работы, в редких или неожиданных ситуациях. Будь то информация о пользователях установивших соединение, торговом терминале с которого пришел заказ, или дескриптор аппаратного ускорителя, занятого обработкой биржевых данных — OutOfLine сохранит кеш чистым, когда вы находитесь в критической части вычислений (critical path).

Я подготовил тест, чтобы вы могли увидеть и оценить разницу.

Я получил примерно 10-ти кратное ускорение при использовании OutOfLine. Очевидно, что этот тест разработан для демонстрации потенциала OutOfLine, однако он также показывает насколько существенное влияние на производительность способна оказать оптимизация кеша, равно как и то, что OutOfLine позволяет эту оптимизацию получить. Поддержание кеша свободным от редко используемых данных может обеспечить сложно измеряемое комплексное улучшение показателей остального кода. Как и всегда при оптимизации, доверяйте измерениям больше чем предположениям, тем не менее надеюсь что OutOfLine окажется полезным инструментом в вашей копилке утилит.

Примечание от переводчика

Код, приведенный в статье, служит для демонcтрации идеи и нерепрезентативен по отношению к продакшн коду.