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

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

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

4. ЧИСЛЕННЫЕ РЕЗУЛЬТАТЫ

Для первой серии экспериментов мы оценивали производительность всех библиотек при изменении количества воркеров (см. 2), а также размера пакета. Эти эксперименты проводились на локальном сервере со следующими характеристиками: Intel(R) Core(TM) i9-10900K, 2 видеокарты NVIDIA GeForce RTX 3090 и жесткий диск емкостью 10 ТБ (6 ГБ/с) [5].

Мы оценили три режима: по умолчанию (один графический процессор), распределенный (два графических процессора) и фильтрационный (один графический процессор) для всех возможных комбинаций 0, 1 и 2 рабочих процессов. Для CIFAR10 и RANDOM размер пакета составлял 16, 64 или 128. Для CoCo мы использовали меньшие значения: 1, 2 и 4. Во всех этих экспериментах использовалось пороговое значение 10 и вариант, который запускает модель (вперед и пас назад).

4.1 Скорость как функция размера партии и рабочих

Первое, что мы замечаем при рассмотрении экспериментов, это то, что разница между библиотеками зависит от проблемы и используемого набора данных. На рисунке 4 показано одно такое сравнение для CIFAR10 на одном графическом процессоре, тогда как на рисунке 5 показан тот же результат для CoCo, также на одном графическом процессоре.

Этого следовало ожидать, учитывая, что в последнем случае время, затраченное на вычисление прямого и обратного прохода, доминирует над общим временем выполнения, чего нельзя сказать о изображении.

классификация. Вы также можете заметить общую разницу в скорости: от 4000 выборок в секунду до всего лишь 20.

Во-вторых, отметим, что увеличение размера пакета практически во всех случаях увеличивает скорость обработки. Однако дело обстоит не так с количеством работающих. На рисунке 6 мы можем наблюдать, что производительность FFCV снижается по мере увеличения количества рабочих процессов, в то время как Deep Lake стабилизируется на уровне 1 рабочего, а не 2. Одно из объяснений заключается в том, что библиотеки имеют свои собственные внутренние алгоритмы, которые решают, как распределять потоки и процессы по мере необходимости. Вышеупомянутый пункт актуален для пользователей этих библиотек, поскольку опыт работы с одной из них может оказаться неэффективным для другой.

4.2 Прирост скорости при использовании DDP

Желательной особенностью загрузчика данных является его способность линейно масштабироваться в зависимости от количества графических процессоров. Это не всегда возможно и зависит от внутреннего механизма загрузки каждой библиотеки. Мы исследуем, как работают эти библиотеки, сравнивая прирост скорости при использовании одного или двух графических процессоров. На рисунке 7 показаны результаты для набора данных RANDOM. Каждая полоса представляет максимальную скорость, достигнутую при всех размерах партий, количестве рабочих и повторениях. В каком-то смысле это отражает максимальную скорость, достижимую библиотекой. Мы наблюдаем, что библиотеки ускоряются примерно на 40%, что в среднем составляет менее половины линейного увеличения. Два случая особенно удивительны. С одной стороны, Torchdata на двух графических процессорах работает хуже, чем на одном. С другой стороны, FFCV добился увеличения скорости больше, чем теоретически возможно. Здесь может быть несколько артефактов, но, скорее всего, это связано с ограниченным количеством повторений, которые мы смогли выполнить (из-за ограниченности ресурсов). Также это может

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

4.3 Сравнение между пасом вперед и назад и без него

Как мы обсуждали при представлении алгоритма 1, нам нужно было решить, будем ли мы включать проходы вперед и назад в расчет скорости. Есть аргументы в пользу обоих. С одной стороны, включение прямых и обратных проходов лучше отражает фактическое время обучения алгоритма. В то же время некоторые библиотеки могут заранее оптимизировать шаги, обычно выполняемые во время прямого прохода, поэтому

остановка там может показаться, что это займет больше времени, чем сейчас.

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

Чтобы понять, было ли заметно изменение поведения, мы использовали набор данных RANDOM для сравнения разницы в средней скорости при включении двух операций модели в расчет и при отсутствии этого. Результаты представлены на рисунке 8. Мы можем наблюдать, что у большинства библиотек при исключении модели немного увеличивается скорость (кроме FFCV, производительность которой падает вдвое), а главное, относительная производительность среди библиотек остается практически такой же.

4.4 Компромиссы в скорости при фильтрации данных

Для наших экспериментов по фильтрации мы выбрали два класса для CIFAR10 и RANDOM: собака и грузовик, а также 0 и 13 соответственно. Для CoCO мы выбрали три класса: пицца, диван, кот.

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

Это довольно быстро для небольшого набора данных, но становится невозможным для больших наборов данных: фильтрация CoCo с помощью PyTorch была непомерно дорогой. В целом производительность при фильтрации и без нее была примерно одинаковой[6]. Аналогично рис.

7, на рисунке 9 мы можем увидеть замедление в результате фильтрации: хотя оно было значительным для Torchdata и Webdataset, мы увидели разворот результатов при работе с CoCo Dataset.

4.5 Обучение во время потоковой передачи по сети

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

Некоторые из библиотек, рассматриваемых в этой статье, позволяют указать набор данных, доступный через Интернет: особенно хороши в этом Webdataset, Hub и Deep Lake[7]. Тогда возникает вопрос: насколько велик компромисс между простотой использования и временем работы?

Чтобы пролить свет на этот вопрос, мы поставили следующий эксперимент. Мы запустили две полные эпохи набора данных RANDOM для трех библиотек: Hub, Deep Lake и Webdataset, изменяя при этом источник данных. Рассматривались три места: локальная копия на машине, на которой выполняется эксперимент, копия в корзине S3 (ближайший регион к нашей машине) и копия, хранящаяся в MinIO (эквивалент S3 с открытым исходным кодом, который можно размещенный локально), работающий на похожей машине в той же локальной сети (обе машины были подключены через Wi-Fi). Компьютер для экспериментов имел процессор Intel(R) Core(TM) i7-7700 @ 3,60 ГГц, 16 ГБ оперативной памяти, NVIDIA GeForce RTX.

2070 Rev и жесткий диск Samsung SSD 850 емкостью 256 ГБ. Что касается задержки, время прохождения туда и обратно от рабочей станции, на которой проводились эксперименты, до сервера MinIO (расположенного в той же комнате и в том же локальном Wi-Fi) заняло 59,2 ± 58,5 мс (мин. 8,8 мс), а до корзины S3 в AWS. серверам потребовалось 17,3 ± 1,3 мс (мин. 14,8 мс).

На рисунке 10 показано общее время работы для девяти экспериментов, а белые проценты обозначают замедление (увеличение времени работы) по сравнению с локальным случаем. Мы можем наблюдать, что хотя для Hub и Webdataset при переходе на AWS наблюдается значительный прирост, Deep Lake удалось сохранить почти такую же скорость с приростом всего на 13%. Из результата можно извлечь еще одну полезную информацию: настройка MinIO показывает замедление почти в два раза сильнее, чем настройка AWS, как показано на рисунке 10. Этот результат можно объяснить, прежде всего, разницей в среднем времени прохождения туда и обратно, показанной выше, подчеркивая, что локальные сети (например, внутренние сети компании[8]) могут быть не самым эффективным способом размещения наборов данных из-за их сложной конфигурации и ограничений. Кроме того, этот результат также указывает на то, что хранилище, обслуживающее наборы данных по сети, играет решающую роль в обеспечении удаленного обучения и может вызвать вопросы о передовых методах обслуживания наборов данных. А именно, данные из S3 подаются параллельно с разных серверов с балансировкой нагрузки, в то время как у нас был доступ к одному экземпляру MinIO.

Графики всех дополнительных экспериментов можно найти в Приложении А.

[5] https://www.seagate.com/www-content/productcontent/barracuda-fam/barracuda-new/enus/docs/100835983b.pdf

[6] по скорости. Сборка сэмплера для PyTorch выполняется заранее, что существенно влияет на общее время работы.

[7] Такая возможность есть у Squirrel, но нам не удалось указать адрес MinIO, поэтому мы исключили его из сравнения. У нас была аналогичная проблема с Torchdata.

[8] В данном случае университетская сеть