目录
- 1.Abstract
- 2.Accelerating FSS on a GPU
- 2.1 Accelerating FSS-based compute on GPU
- 2.1.1 Faster AES computation (AES)
- 2.1.2 Optimized data layout for cache locality (LAYOUT)
- 2.1.3 Optimizing memory footprint (MEM)
- 2.2 Reducing time to read FSS keys
- 2.2.1 Bypassing OS page cache
- 2.2.2 Overlapping key read with computation
- 2.2.3 New cryptographic technique to limit key size
- 3.Evaluation
1.Abstract
端到端系统ORCA：
- 加速基于 FSS 的使用 GPU 的 2PC 协议的计算。
- 新的基于 FSS 的 2PC 协议
- 提供了第一个用于随机截断的安全协议，并在此基础上提供了对具有端到端安全性的训练的首次评估。
- ORCA 在 CIFAR-10 上具有 4% 更高的准确性，98 倍更少的通信，并且速度提高了 26 倍。
- 对于安全的 ImageNet 推断，ORCA 实现了 VGG-16 和 ResNet-50 的亚秒延迟，并且比最先进技术快 8-103 倍。
2.Accelerating FSS on a GPU
2.1 Accelerating FSS-based compute on GPU
2.1.1 Faster AES computation (AES)
-
AES 加密： AES 需要反复查找预先计算的查找表（lookup table）
-
常量缓存（constant cache）： GPU 中的常量缓存用于存储只读数据，在每个流处理器（SM）中都有一份副本。访问常量缓存通常很快，适合并行计算。
-
访问模式要求： 常量缓存的性能依赖于 GPU 线程的访问模式。如果所有线程在同一时间访问同一个地址，性能非常高。如果不同线程访问不同地址，访问会被序列化，导致性能下降，甚至导致计算停滞（stall）。
问题分析：
- 在 AES 加密过程中，不同的 GPU 线程会访问查找表中的不同索引。
- 由于查找表存储在常量缓存中，当不同线程访问不同地址时，这些访问会被序列化。
- 这种序列化会导致访问延迟（stall），从而影响整体性能。
解决方案:
1.查找表复制策略：
- 每个 warp 复制查找表： 每个 SM（流处理器）中的 warp（通常为 32 个线程）都拥有一份查找表的副本。这意味着在每个 SM 中，共有 32 份查找表副本。
- 这种策略基于先前的研究【61】，目的是减少不同线程访问同一份查找表时的冲突，从而减小序列化访问带来的性能损失。
2.将查找表放置在共享内存中：
- 共享内存（scratchpad memory）： 共享内存是每个 SM 上的高速缓存，用于存储线程块内共享的数据。
- 共享内存的分块（banking）：共享内存分为多个内存银行（banks），每个银行可以独立处理一个内存请求。这样设计使得不同银行的数据可以并行访问，从而避免了访问冲突和停滞。
3.查找表副本放置在不同的内存银行中：
- 避免访问冲突： 通过将查找表副本放在共享内存的不同银行中，不同线程可以同时访问不同银行的数据，避免了因访问相同内存位置而导致的序列化访问问题。
- 提高访问效率： 由于共享内存银行可以并行访问，查找表放置在不同银行后，线程访问查找表的速度显著提高，减少了计算停滞。
2.1.2 Optimized data layout for cache locality (LAYOUT)
背景：
- DCF计算： 计算 DCF 需要评估者执行 n 个链式伪随机生成器（PRG），每个 PRG 调用两次 AES。评估者在调用第 个 PRG 之前，需要稍微修改第 个 PRG 的输出，并使用一个修正词（correction word，CWi）进行调整。
- 修正词的数量和存储： 每个 DCF 键有 n 个修正词。这些修正词在内存中的布局会影响性能。
并行化实现
1.CPU上的并行实现：
- 在 CPU 上，每个线程独立地在一个 CPU 核心上计算 DCF。将用于 DCF 计算的 n 个修正词在内存中连续布局，可以更好地利用缓存局部性，从而提高缓存命中率。
2.GPU上的并行实现：
- 在 GPU 上每个线程计算 DCF 时同步进行。Warp 中的所有线程必须在第 𝑘−1 个 PRG 计算完成后，才能继续第 𝑘 个 PRG 计算。
内存布局优化：
- 传统布局的缺点： 如果像在 CPU 实现中一样，将 n 个修正词在内存中连续布局，会导致缓存命中率低下。这是因为每个线程在不同的时间访问不同的修正词，导致缓存局部性差。
- 优化布局的策略： 为了提高 GPU 上的缓存命中率，应第 k 轮 PRG 计算的所有修正词在内存中连续放置，第 k+1 轮 PRG 计算的修正词紧接其后，以此类推。
2.1.3 Optimizing memory footprint (MEM)
背景和问题：
- FSS 协议：FSS 协议降低了通信开销，但要求较大的密钥大小。
- 存储和读取：密钥通常存储在 SSD 上，并在在线计算期间读入内存。读取大密钥会非常慢，尤其是从 SSD 读取。
- 数据传输：大密钥不仅增加了通过 PCIe 总线在 CPU 和 GPU 之间传输的数据量，还占用了有限的 GPU 内存。
解决方案：
1.减少密钥大小：
- 使用小负载的 DCF： 例如，使用 1-bit 而不是 64-bit 的负载，并尽可能使用 40-bit 而不是 64-bit 的输入进行比较。
- 优势： 减少密钥大小降低了 CPU 和 GPU 之间的数据移动量，并减小了 GPU 内存占用。
2.避免内存膨胀：
- 问题： 如果简单地将 1-bit 输出存储到标准数据类型（如字节），会导致 8 倍的内存膨胀。
- 解决方案： 在 ORCA 中，warp 中的 32 个线程以锁步方式将各自的 1-bit DCF 输出写入一个 32-bit 整数中。
3.避免使用锁：
- 问题： 在 GPU 上使用锁非常慢。
- 解决方案： 利用 CUDA 的 warp 同步原语，确保 warp 中的每个线程在写入时不会相互干扰。
结果和性能提升:
- 通过这种优化，执行一千万个 DCF 的时间减少到 523 毫秒，比简单实现提高了 27%。总体上，比原始的简单实现提高了 6.3 倍
2.2 Reducing time to read FSS keys
FSS 协议的优势：
- 主要优势是减少各方之间的通信量。
- 需要在进行在线计算时读取大量预生成的密钥。
性能瓶颈：
- 尽管通过优化策略加速了 GPU 上的计算，读取 FSS 密钥的时间（从 SSD 到 GPU 内存）成为新的瓶颈。
2.2.1 Bypassing OS page cache
背景：
- 默认情况下，操作系统将文件内容缓存到CPU的DRAM上，希望随着时间的推移，文件的数据将被反复访问。
问题：
- 页面缓存会在访问文件内容的关键路径上增加开销
原因：
- FSS密钥只能使用一次，没有再利用
- 包含FSS密钥的文件不会受益于页面缓存，但支付开销
2.2.2 Overlapping key read with computation
减少键读取时间的影响：
- 将第i次训练迭代的计算与第(i + 1)次迭代的键读取计算重叠。
- 确保整个键读取时间都不在关键路径上。
2.2.3 New cryptographic technique to limit key size
问题：
- 即使经过上述优化，对于较大的网络，从SSD读取密钥的时间也会超过GPU的计算时间
原因 ：
- 当计算在GPU上像在ORCA中那样得到很好的加速时，键读取时间才会成为瓶颈
- 其它情况并非如此
解决方案： 构建了新的FSS协议
- 减少流行的非线性(如ReLU和maxpool)中的密钥大小
- 减少在线通信
- 与量化训练中的截断相结合
3.Evaluation
