[Перевод] Библиотека Google Benchmark05.04.2017 13:33

2a0e144ad2c6449fb82b1a6585b6438d.jpg

Не так давно я писал о C++ библиотеках для микробенчмаркинга. Я рассказал о трех библиотеках: Nonius, Hayai и Celero. Но в действительности я хотел поговорить о четвертой. Мой Windows тогда не поддерживал Google Benchmark library, так что я не мог ее протестировать. К счастью, из комментариев к прошлому посту я узнал, что теперь библиотека доступна в Visual Studio!

Давайте посмотрим, как можно ее использовать.

Библиотека


→ Основной github репозиторий
→ Обсуждение

Благодаря коммиту KindDragon: Support MSVC on appveyor, мы можем собрать библиотеку в Visual Studio. Я без затруднений скачал последний код из репозитория, сгенерировал solution-файлы с помощью CMake и собрал нужную версию. Чтобы использовать библиотеку в вашем проекте, остается только подключить саму библиотеку и один заголовочный файл.

Простой пример


В исходной статье я проводил два эксперимента:
  • IntToStringConversionTest(count) — конвертирует целые числа из диапазона 0…count-1 в строки и возвращает вектор этих строк.
  • DoubleToStringConversionTest(count) — конвертирует 0.12345… count-1+0.12345 в строки и возвращает вектор строк.

Пример бенчмарков целиком: 
#include "benchmark/benchmark_api.h"
#include "../commonTest.h"

void IntToString(benchmark::State& state) {
    while (state.KeepRunning()) {
        benchmark::DoNotOptimize(
           IntToStringConversionTest(state.range_x())
        );
    }
}
BENCHMARK(IntToString)->Arg(TEST_NUM_COUNT1000);

void DoubleToString(benchmark::State& state) {
    while (state.KeepRunning()) {
        benchmark::DoNotOptimize(
           DoubleToStringConversionTest(state.range_x())
        );
    }
}
BENCHMARK(DoubleToString)->Arg(TEST_NUM_COUNT1000);

BENCHMARK_MAIN()

Красиво и просто! Макрос BENCHMARK используется для определения бенчмарка, затем можно добавить параметры вызова. В примере выше я использовал метод Arg. Параметр в этом методе передается в объект state, доступный функции бенчмарка. В нашем примере мы получаем это значение с помощью state.range_x(). Затем оно используется как размер выходного вектора строк.

Внутри функции бенчмарка в while-цикле выполняется основной код. Количество итераций библиотека выберет автоматически.

Обычно приложение выполняется в консоли и выводит следующий результат:

103bb2ef1f70412a8e876a14fb01d568.png

Вывод очень прост: название бенчмарка, время в наносекундах (можно изменить с помощью метода Unit()), время CPU, количество выполненных итераций.

Чем же так хороша эта библиотека?

  • Можно легко изменять параметры: Arg, ArgPair, Range, RangePair, Apply.
    • Значения можно получить с помощью state.get_x(), state.get_y()
    • Так что можно создавать бенчмарки для задач в одно- и двухмерном пространстве.
  • Fixture
  • Измерения в несколько потоков
  • Ручное управление временем: полезно, когда код выполняется на графическом процессоре или другом устройстве, где стандартное время CPU не применимо.
  • Форматы вывода: в виде таблицы, CSV, Json
  • Возможность добавлять свои метки с помощью state.SetLabel()
  • Метки для обработанных объектов и обработанных байтов, благодаря state.SetItemsProcessed() и state.SetBytesProcessed()

Вот так выглядит вывод бенчмарка с байтами в секунду, объектами в секунду, метками и измененными единицами времени.

dac9ec3cdffa4b1e86c1b565a3025ae7.png

Усложненный пример


В другом посте о библиотеках для микробенчмаркинга я тестировал библиотеки на немного более сложном примере. Это мой обычный бенчмарк — вектор указателей против вектора объектов. Посмотрим, сможем ли реализовать этот пример с помощью Google Benchmark.

Настройка


Вот, что мы собираемся протестировать:
  • Класс Particle (частица) — содержит 18 атрибутов типа float: 4 для обозначения перемещения (pos), 4 для обозначения скорости (vel), 4 для ускорения (acceleration), 4 для цвета (color), 1 для времени (time), 1 для поворота (rotation). Еще у нас будет буфер, также типа float, с переменным количеством элементов в нем.
    • Стандартная частица составляет 76 байт
    • Увеличенная частица — 160 байт
  • Хотим измерить скорость работы метода Update на векторе частиц.
  • Будем использовать пять видов контейнеров:
    • vector<Particle>
    • vector<shared_ptr<Particle>> — с рандомизацией размещения в памяти
    • vector<shared_ptr<Particle>> — без рандомизации размещения в памяти
    • vector<unique_ptr<Particle>> — с рандомизацией размещения в памяти
    • vector<unique_ptr<Particle>> — без рандомизации размещения в памяти

Немного кода


Пример кода для vector<Particle>: 
template 
class ParticlesObjVectorFixture : public ::benchmark::Fixture {
public:
    void SetUp(const ::benchmark::State& st) {
        particles = std::vector(st.range_x());

        for (auto &p : particles)
            p.generate();
    }

    void TearDown(const ::benchmark::State&) {
        particles.clear();
    }

    std::vector particles;
};

А вот бенчмарк: 
using P76Fix = ParticlesObjVectorFixture;
BENCHMARK_DEFINE_F(P76Fix, Obj)(benchmark::State& state) {
    while (state.KeepRunning()) {
        UpdateParticlesObj(particles);
    }
}
BENCHMARK_REGISTER_F(P76Fix, Obj)->Apply(CustomArguments);

using P160Fix = ParticlesObjVectorFixture;
BENCHMARK_DEFINE_F(P160Fix, Obj)(benchmark::State& state) {
    while (state.KeepRunning()) {
        UpdateParticlesObj(particles);
    }
}
BENCHMARK_REGISTER_F(P160Fix, Obj)->Apply(CustomArguments);

С помощью этого кода мы протестируем два вида частиц: маленькие — 76 байт и побольше — 160 байт. Метод CustomArguments генерирует количество частиц для каждой итерации бенчмарка: 1k, 3k, 5k, 7k, 9k, 11k.

Результаты


В этом посте мы уделили основное внимание самой библиотеке, но я хотел бы ответить на вопрос, который мне задавали раньше — вопрос о различных размерах частиц. Пока я использовал только два типа: 76-байтные и 160-байтные.

Результаты для 76 байт:

53005870e41a4f5e847cf7fa5f55bd63.png

Рандомизированные указатели почти на 76% медленнее, чем векторы объектов.

Результаты для 160 байт:

739332a580794122b169fe6b38af4a8d.png

Почти прямые линии в случае больших частиц! Рандомизированные указатели медленнее только на 17%…. Ну хорошо, пускай не совсем прямые:)

Кроме того, мы протестировали и unique_ptr. Как видите, с точки зрения update (доступа к данным), скорость почти такая же, как и у shared_ptr. Таким образом, косвенное обращение — это проблема умного указателя, а не неизбежные накладные расходы.

Итог


Репозиторий с примерами кода

У меня не было трудностей с использованием Google Benchmark library. Вы сможете освоить основные принципы написания бенчмарков за несколько минут. Многопоточные бенчмарки, fixture, автоматический подбор количества итераций, вывод в формате CSV или Json — вот и все базовые функции. Лично мне больше всего нравится гибкость передачи параметров в код бенчмарка. У остальных проверенных мной библиотек имелись проблемы с тем, чтобы передать бенчмарку параметры проблемной области. Самой простой с этой точки зрения была Celero.

Не хватает, пожалуй, только расширенного отображения результатов. Библиотека показывает нам только среднее время выполнения итераций. Хотя в большинстве случаев этого достаточно.

С точки зрения эксперимента, я получил интересные результаты для частиц разного размера. Это может стать основой для будущего финального теста. Я попробую переписать мои примеры с большим разнообразием размеров объектов. Ожидаю увидеть огромную разницу в результатах для маленьких объектов и незначительную — для больших.

О, а приходите к нам работать? :)
wunderfund.io — молодой фонд, который занимается высокочастотной алготорговлей. Высокочастотная торговля — это непрерывное соревнование лучших программистов и математиков всего мира. Присоединившись к нам, вы станете частью этой увлекательной схватки.

Мы предлагаем интересные и сложные задачи по анализу данных и low latency разработке для увлеченных исследователей и программистов. Гибкий график и никакой бюрократии, решения быстро принимаются и воплощаются в жизнь.

Присоединяйтесь к нашей команде: wunderfund.io

Комментарии (0)

© Habrahabr.ru