数据加载器概况：数值结果

链接表

• 摘要和简介
• 数据加载器
• 实验装置
• 数值结果
• 讨论
• 相关工作
• 结论、致谢和参考文献
• A. 数值结果续

4. 数值结果

对于第一组实验，我们评估了在更改工作器数量（见 2）以及批处理大小时所有库的性能。这些实验在具有以下规格的本地服务器上运行：Intel(R) Core(TM) i9-10900K、2 x NVIDIA GeForce RTX 3090 和具有 10TB 存储空间（6GB/s）的 HDD [5]。

我们评估了三种模式：默认（单 GPU）、分布式（双 GPU）和过滤（单 GPU），以了解 0、1 和 2 个工作器的所有可能组合。对于 CIFAR10 和 RANDOM，批处理大小为 16、64 或 128。对于 CoCo，我们使用较小的值：1、2 和 4。所有这些实验都使用了 10 的截止值和运行模型的变体（前向和后向传递）。

4.1 速度与批次大小和工人的关系

在检查实验时，我们注意到的第一件事是库之间的差异取决于问题和所使用的数据集。图 4 显示了单个 GPU 上 CIFAR10 的此类比较，而图 5 显示了 CoCo 的相同结果，也是在单个 GPU 上。

这是可以预料到的，因为在后者中，计算前向和后向传递的时间主导了整个运行时间，而图像的情况并非如此

分类。您可能还会注意到速度的总体差异：从每秒 4000 个样本到仅 20 个。

其次，我们指出，在几乎所有情况下，增加批处理大小都会提高处理速度。但是，对于工作器数量而言，情况并非如此。我们可以在图 6 中观察到，FFCV 性能随着工作器数量的增加而下降，而 Deep Lake 在 1 个工作器而不是 2 个工作器时达到稳定状态。一种解释是，库有自己的内部算法，可以根据需要决定如何跨越线程和进程。上述观点与这些库的用户相关，因为其中一个库的经验可能无法很好地转化为另一个库的经验。

4.2 使用 DDP 时的速度提升

数据加载器的一个理想特性是它能够随着 GPU 数量线性扩展。这并不总是可能的，并且取决于每个库的内部加载机制。我们通过比较使用一个或两个 GPU 时的速度增加来探索这些库的性能。图 7 显示了 RANDOM 数据集的结果。每个条形图代表所有批次大小、工作器数量和重复次数所实现的最大速度。在某种程度上，这反映了库可以实现的最大速度。我们观察到库的速度提高了约 40%，平均不到线性增长的一半。两种情况特别令人惊讶。一方面，Torchdata 使用两个 GPU 的表现比使用单个 GPU 更差。另一方面，FFCV 实现了超过理论可能的速度提升。这里可能有几个因素在起作用，但最有可能的原因是，我们能够运行的重复次数有限（由于资源有限）。此外，这可能

指示 Torchdata 中的配置错误：对于大多数库来说，在多 GPU 环境中运行实验的文档是有限的。

4.3 有无前向和后向传递的比较

正如我们在介绍算法 1 时所讨论的那样，我们必须决定是否将前向和后向传递纳入速度计算中。两种方法都有理由。一方面，包括前向和后向传递可以更好地反映算法的实际训练时间。同时，一些库可能会预先优化通常在前向传递期间完成的步骤，因此

在那里停留的时间似乎比实际要长。

另一方面，如果前向和后向传递所花费的时间比仅加载数据所花费的时间大得多，那么将该时间包括在计算中将不可避免地隐藏库之间的差异。

为了了解行为变化是否明显，我们使用 RANDOM 数据集比较在计算中包含和不包含这两个模型操作时的平均速度差异。结果如图 8 所示。我们可以观察到，大多数库在排除模型时速度略有提高（FFCV 除外，其性能下降了一半），最重要的是，库之间的相对性能几乎保持不变。

4.4 过滤数据时的速度权衡

对于我们的过滤实验，我们为 CIFAR10 和 RANDOM 选择了两个类别：狗和卡车，以及 0 和 13。对于 CoCO，我们选择了三个类别：披萨、沙发、猫。

我们观察到，大多数库都没有良好的过滤机制，无法避免对整个数据集进行迭代。例如，我们的 PyTorch 过滤实现需要使用所需图像的索引构建自定义采样器。

对于小型数据集来说，这相当快，但对于大型数据集来说就不可行了：使用 PyTorch 过滤 CoCo 的成本过高。一般来说，过滤和不过滤时的性能非常相似[6]。与图类似

7、在图 9 中，我们可以看到由于过滤而导致的速度减慢：尽管对于 Torchdata 和 Webdataset 来说速度减慢相当大，但在使用 CoCo 数据集时，我们看到了结果的逆转。

4.5 通过网络传输数据的同时进行训练

理想情况下，我们可以将数据集存储与机器学习训练过程分离，只需将存储数据的数据库连接到所选的 ML 框架，无论两者位于何处。这涉及通过网络发送训练数据并损失相当大的速度。由于在云端租用 GPU 加速硬件的成本很高，因此这种便利似乎不值得。但事实并非如此吗？

本文讨论的一些库允许指定可通过互联网访问的数据集：Webdataset、Hub 和 Deep Lake 在这方面尤其擅长[7]。那么问题就变成了：易用性和运行时间之间的权衡有多大？

我们设置了以下实验来深入了解这个问题。我们为三个库（Hub、Deep Lake 和 Webdataset）运行了 RANDOM 数据集的两个完整时期，同时更改了数据的来源。考虑了三个位置：运行实验硬盘的机器中的本地副本、S3 存储桶中的副本（在离我们机器最近的区域）以及存储在 MinIO（可以本地托管的 S3 的开源等效物）中的副本，该副本运行在同一本地网络内的类似机器中（两台机器都通过 WiFi 连接）。实验计算机配备了 Intel(R) Core(TM) i7-7700 CPU @ 3.60GHz、16 GB RAM、NVIDIA GeForce RTX

2070 Rev，以及具有 256 GB 存储空间的三星 SSD 850 硬盘。至于延迟，从运行实验的工作站到 MinIO 服务器（位于同一房间和同一本地 WiFi 中）的往返时间为 59.2 ± 58.5 毫秒（最少 8.8 毫秒），而到 AWS 服务器中的 S3 存储桶的往返时间为 17.3 ± 1.3 毫秒（最少 14.8 毫秒）。

图 10 描述了九个实验的总运行时间，白色百分比表示与本地情况相比的减速（运行时间的增加）。我们可以观察到，尽管 Hub 和 Webdataset 在迁移到 AWS 时有显著的提升，但 Deep Lake 仍设法保持了几乎相同的速度，仅增加了 13%。从结果中可以得出另一个有用的见解：MinIO 设置显示的速度减慢几乎是 AWS 设置的两倍，如图 10 所示。此输出主要可以通过上面显示的平均往返时间差异来解释，突出显示本地网络（例如，公司内部网络 [8]）可能不是托管数据集的最有效方式，因为它们的配置和限制很复杂。此外，此结果还表明，通过网络为数据集提供服务的存储在实现远程训练方面起着至关重要的作用，并可能引发有关为数据集提供服务的最佳实践的问题。也就是说，来自 S3 的数据由具有负载平衡的不同服务器并行提供，而我们可以访问单个 MinIO 实例。

所有附加实验的图表可以在附录 A 中找到。

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

[6] 速度更快。PyTorch 的采样器构建是预先完成的，这极大地影响了总运行时间。

[7] Squirrel 具有此功能，但我们无法指定 MinIO 地址，因此我们将其排除在比较之外。我们在使用 Torchdata 时也遇到了类似的问题。

[8] 本案例中的大学网络