Обзор ландшафта загрузчика данных: экспериментальная установка

Таблица ссылок

• Аннотация и введение
• Загрузчики данных
• Экспериментальная установка
• Численные результаты
• Обсуждение
• Связанных с работой
• Заключение, благодарности и ссылки
• А. Численные результаты. Продолжение.

3. ЭКСПЕРИМЕНТАЛЬНАЯ УСТАНОВКА

Несколько библиотек и наборов данных были выбраны для сравнения их функций и производительности. Несмотря на то, что были приложены усилия, чтобы быть максимально понятными, область загрузки данных постоянно развивается, и каждый день добавляются новые библиотеки и выпуски. В связи с этим мы ожидаем, что следующий список предоставит хороший обзор текущих возможностей загрузчиков данных, не обязательно заявляя или находя лучшие в целом (которые, вероятно, изменятся со времени написания статьи до момента публикации). Мы делаем весь исходный код экспериментов доступным для общественности и ожидаем, что результаты будут полностью воспроизводимыми.

Для проведения экспериментов мы выбрали семь библиотек: PyTorch (Paszke et al., 2019), Torchdata (TorchData, 2021), Hub (Team, 2022a), FFCV (Leclerc et al., 2022), Webdatasets (Webdataset, 2013), Белка (Команда, 2022б) и Глубокое озеро (Амбарцумян и др., 2022). Мы обнаружили одну интересную вещь: не все библиотеки поддерживают одни и те же функции. Например, мы не могли запустить FFCV с набором данных, размещенным в корзине S3, для проведения удаленных экспериментов. Как мы упоминали в разделе 1, все наши эксперименты мы проводим в PyTorch. Мы рассматривали возможность воспроизведения экспериментов в других популярных средах машинного обучения, но отказались от этой идеи, поскольку вторым кандидатом мог бы быть Tensorflow, но ходят слухи, что Google отходит от него в пользу JAX. На рисунке 1 показана популярность различных платформ машинного обучения за последние 12 месяцев.

3.1 Наборы данных

Что касается наборов данных, мы изначально выбрали два классических набора данных для поддержки двух разных задач обучения: CIFAR-10 (Крижевский и др., 2009) для классификации изображений и CoCo (Лин и др., 2014) для обнаружения объектов. При проведении некоторых экспериментов мы наблюдали странное поведение (библиотеки работали лучше, чем ожидалось), которое можно объяснить

CIFAR-10 вписывается в память[2]. По этой причине мы создали третий набор данных под названием RANDOM, состоящий из случайно сгенерированных цветных изображений размером 256 на 256 пикселей и случайного класса из 20. Этот третий набор данных содержит 45 000 изображений для обучения, 5 000 для проверки и 500 для тестирования. и он значительно больше, чем CIFAR-10.

Мы использовали одни и те же преобразования для всех библиотек, чтобы сделать тесты сопоставимыми. Единственным исключением стал FFCV, который имеет собственную реализацию различных преобразований. Для классификации изображений стек преобразований состоял из следующих элементов: «Случайное горизонтальное переворот», «Нормализация», «Вырез», «Преобразование в тензор».

Для обнаружения объектов мы в основном полагались на реализацию преобразований Альбументации (Буслаев и др., 2020). Стек выглядел следующим образом: кадрирование произвольного размера, случайное горизонтальное отражение, нормализация, преобразование в тензор. Эти преобразования применимы как к изображениям, так и к ограничивающим рамкам.

3.2 Варианты эксперимента

По возможности мы размещали набор данных локально и в корзине, эквивалентной S3. Это позволило нам оценить замедление, возникающее в результате обучения по потоку данных по сети. Подробное описание условий обучения мы предоставим в разделе 4.

Учитывая, что наиболее интенсивные обучающие задания включают использование более одного графического процессора, по возможности мы также проводили те же эксперименты в среде с несколькими графическими процессорами. Поскольку на момент проведения экспериментов не все библиотеки имели полную поддержку PyTorch Lightning, мы решили реализовать мульти-GPU, используя библиотеку Distributed Data Parallel (DDP) (Li et al., 2020) от PyTorch.

Для некоторых проектов машинного обучения нам может потребоваться доступ только к подмножеству более крупного набора данных. В этих случаях возможность быстро фильтровать необходимые точки данных без необходимости перебирать весь набор данных может значительно сократить общее время обучения. Некоторые библиотеки позволяют фильтровать по определенным признакам, например по классу (для задач классификации изображений). Мы исследовали выигрыш (или потерю) в скорости при использовании метода фильтрации, предоставляемого библиотекой (если она его предлагает), по сравнению с отсутствием фильтрации вообще. Всякий раз, когда библиотека не предлагала методы фильтрации, мы реализовывали их наивно, т. е. сканировали весь набор данных и сохраняли только те элементы, которые соответствуют заданному условию. Быструю фильтрацию не обязательно легко реализовать, поскольку она требует поддержки дополнительной структуры, подобной индексу, чтобы избежать перебора всех выборок.

Наконец, в таблице 1 указана совместимость различных библиотек с различными экспериментами и наборами данных, которые мы исследовали в этой статье.

3.3 Метрики

Нашим главным приоритетом при построении экспериментов было найти объективную метрику, которая позволила бы нам сравнивать все различные библиотеки корректным способом.

Идеальным показателем было бы общее время выполнения задания по обучению, поскольку это то, чего нам приходится ждать и за что платить. К сожалению, это сильно ограничило бы количество экспериментов, которые мы могли бы провести. После тщательного рассмотрения мы выбрали количество обрабатываемых точек данных (изображений) в секунду, и этот результат подтвержден нашими численными экспериментами. Мы рассматриваем два варианта этой метрики: один, в котором мы используем модель ML для обучения и выполняем обратное распространение ошибки, и другой, в котором мы не используем модель ML, а только перебираем образцы, копируя их в графический процессор. Разницу между двумя метриками можно оценить из псевдокода цикла обучения в алгоритме 1, где m обозначает переменную скорости. Мы также собрали общее время работы[3] и время, необходимое для инициализации загрузчиков данных. Последнее было мотивировано тем фактом, что некоторые библиотеки могут заранее выполнять дорогостоящие вычисления, чтобы увеличить их скорость во время обучения. Еще мы закончили тем, что выполнили разминку для расчета скорости. Подробнее это обсуждается в подразделе 3.5.

3.4 Корреляция между скоростью и временем работы

3.5 Более пристальный взгляд на время работы

Чтобы лучше понять внутренние механизмы каждой библиотеки, мы решили за один прогон проверить, сколько времени потребовалось для выполнения каждого пакета, а также для инициализации загрузчика данных. На рисунке 3 для одной комбинации параметров [4] показано время, затраченное каждой библиотекой на этапах, описанных алгоритмом 1. Все эти эксперименты включали отсечку после 10 партий.

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

Размер полос от 1 до 9 дает лучшее представление о том, насколько хорошо масштабируется каждая библиотека с учетом времени, затраченного на

большой набор данных растет линейно с этой шириной. Мы можем заметить, что большинство библиотек имеют одинаковую ширину, причем Deep Lake является самой короткой (самой быстрой). С другой стороны, единственная библиотека, которая показывает неоднородную ширину, — это FFCV, где полосы с 1 по 3 настолько тонкие, что их невозможно увидеть на изображении.

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

Опираясь на этот показатель, мы решили провести разминку при расчете скорости. Это означает игнорирование времени, затраченного на первую партию, во всех расчетах скорости.

[2] Это часто является чем-то желательным и ожидаемым в некоторых обзорах, но мы обнаружили, что это не так в некоторых практических приложениях с участием небольших групп и внутренних рабочих станций.

[3] Это время от начала моделирования до завершения, которое на практике часто составляло всего 10 партий.

[4] СЛУЧАЙНЫЙ набор данных, один графический процессор, 0 рабочих процессов, размер пакета 64