Авторы:  (1) Ясон Офейдис, факультет электротехники и Йельский институт сетевых наук, Йельский университет, Нью-Хейвен {равный вклад};  (2) Диего Кидански, факультет электротехники и Йельский институт сетевых наук, Йельский университет, Нью-Хейвен {равный вклад};  (3) Леандрос Тассиулас Левон Гукасян, Activeloop, Маунтин-Вью, Калифорния, США, факультет электротехники и Йельский институт сетевых наук, Йельский университет, Нью-Хейвен.  Таблица ссылок   Аннотация и введение   Загрузчики данных   Экспериментальная установка   Численные результаты   Обсуждение   Связанных с работой   Заключение, благодарности и ссылки   А. Численные результаты. Продолжение.  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.  Графики всех дополнительных экспериментов можно найти в Приложении А.  Этот документ   под лицензией CC 4.0. доступен на arxiv  [5] https://www.seagate.com/www-content/productcontent/barracuda-fam/barracuda-new/enus/docs/100835983b.pdf  [6] по скорости. Сборка сэмплера для PyTorch выполняется заранее, что существенно влияет на общее время работы.  [7] Такая возможность есть у Squirrel, но нам не удалось указать адрес MinIO, поэтому мы исключили его из сравнения. У нас была аналогичная проблема с Torchdata.  [8] В данном случае университетская сеть

Part of HackerNoon's growing list of open-source research papers, promoting free access to academic material.

Read My Stories

We cover the most cutting edge academic research and expert blog posts on serialization. Also big fans of the Serial pod

Serialization's blog

Этот звук создан на языке оригинала истории!

Слишком долго; Читать

Make resilience your competitive advantage

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

About Author

КОММЕНТАРИИ

БИРКИ

ЭТА СТАТЬЯ БЫЛА ПРЕДСТАВЛЕНА В

Related Stories

Рост криптовалют: создание эффективных образов пользователей

Telegram: мост Крипто-острова на материк

Раскрытие силы ИИ. Систематический обзор передовых методов: Краткое содержание и введение

Создание криптопродуктов, ориентированных на пользователя: важность отзывов клиентов

Рост криптовалют: создание эффективных образов пользователей

Telegram: мост Крипто-острова на материк

Раскрытие силы ИИ. Систематический обзор передовых методов: Краткое содержание и введение

Создание криптопродуктов, ориентированных на пользователя: важность отзывов клиентов

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps