DataLoader论文

MinIO：对于单机，直接缓存整个 dataset，肯定会很快，但是内存消耗很大。

Multi IO：对于多机，一个机器每次分到的 dataset 分片不一样，直接采用 MinIO 将每个机器都缓存整个 dataset 资源消耗太大了，肯定不推荐。CoorDL 会把每个机器收到的第一个分片缓存，然后记录其他分片在哪些机器缓存（按索引记录），之后的工作需要其他分片时只需去对应的 cache 机器上找就行了。

HP model 针对性优化：min batch，不同的 job 之间相互共通 prep res，但是不同的 epoch 是隔离的。

CoorDL

和 调度 一体化。

和 CoorDL 对所有 job 采用同一 cache 策略不同，SiloD 的 cache 策略会根据不同的 job 进行动态调控，具体看下面的调度算法。

SiloD

CacheW

论文观察到：数据的重用距离较长。第 i 个迭代时缓存的数据可能在第 j 个迭代中被本机的某个 GPU 使用，80% 的 j - i 跨度超过 1k 次迭代。Lobster 的 cache 就是依据重用距离来做的。

Lobster 可以确定每次预取的顺序（例如，固定每个节点的伪随机数生成器种子，就可以知道 shuffle 后的顺序了）。这样一来，就可以在训练的任意时刻确定两点：1. 每一条数据在整个训练过程中（应该指所有 epoch 结束）一共被重用了多少次（reuse count）。2. 每一条数据的任意重用距离（reuse distance）。这两项指标会以表格的形式记录。

两个 cache 策略：1. 按照 reuse count 驱逐：当一条数据的访问次数达到其 reuse count 时，直接驱逐。2. 按照 reuse distance 驱逐：当一条数据的下一个 reuse distance 超过阈值，直接驱逐。

Lobster

Quiver

数据缓存

只负责data load 和 prep，不负责 train。

每个 job 会按照 dataset 分片，分片被分配到不同的 worker，即一个 job 可能对应多个 worker。当然一个 worker 也能跑不同 job 的分片。

以 batch_time 和 result_queue_size 为指标，及预处理速度。

当 batch_time 升高时，说明预处理变慢，则新增一个 worker。

如何判断达到极致性能？当 batch_time 不随着 woker 的增多而降低时，说明可能预处理的速度比 GPU 消费的速度要慢，这可以通过 result_queue_size 判断，如果 result_queue_size 的值过高，说明上产的速度高于消费的速度，超过了极致性能，就可以删除一个 worker 了。

data load，perp 和 train 均负责。

和 CacheW 不一样，SiloD 的一个 job 只在一个 worker 上跑。一个 worker 可以跑多个 job。这个调度指一个 worker 上的多个 job 是如何分配这个 worker 的计算资源和 IO 资源的。

同时检测计算性能（prep + train）和IO性能（data load），取二者的最小值作为调度依据。

最理想的 IO cache 是在 计算性能 = IO性能时，即 IO 刚跳出瓶颈。通过这个等式，可以算出理论上的最优缓存效率（论文中公式 5）。

SiloD的调度是针对多个不同的 jobs 进行资源分配，旨在尽可能平衡每个 job 的性能与资源消耗。

定义了 三个 调度算法（实际上是在已有的调度算法上进行变种）。对性能强感知的： 1. SJF（最短作业优先），score 为所有资源类型的需求的加权乘以 job 持续时间和数据大小，即优先考虑持续时间最短和数据量最少的 job。2.  Gavel，基于 Gavel 的 max-min fairness 模型进行变种，该模型用于按不同 job 的资源需求来分配资源而不是平等分配资源，比如一个 GPU 资源非常多但是存在 IO 瓶颈的 job，其计算资源就是浪费的，该模型会将其视为 unfair，并将其计算资源分配给。

对性能若感知的。贪心算法（？）：所谓弱感知，个人理解就是不容易检测到 IO 性能。对于这种情况，SiloD 直接使用公式5来对每个 job 分配 cache，从而尽可能减少 IO，只是尽可能。

调度

论文观察到三点：1. 多 GPU 并行训练时，由于data load/prep 开销不均衡，导致整体速度会被落后者拖慢。2. data load 的开销在迭代过程中频繁变化，有时是瓶颈，有时不时。3. data prep 的性能并不是随着线程数增多而一直增多的，它有个峰值。

Lobster 针对多线程优化的核心思想就是让服务每个 GPU 的 data load/prep 线程数位于一个最佳的数量。

工作大体分为两步：1. 先预测一个最佳的 prep 线程数。2. 如果 prep 不再是瓶颈，那就分出一定的线程去服务 data load。

为了确定最佳的线程数，首先要预测 prep 的性能。Lobster 为不同的大小的样本集设计了不同的性能模型，每个样本均采用离其大小最近的样本所对应的性能模型。

多线程优化

DataLoader相关优化