系统信息
- 是否编写了自定义代码(与在TensorFlow中使用的库存示例脚本相反):否
- OS平台和发行版(例如，Linux Ubuntu 16.04):GCP VM,tf版本为nightly
- 移动设备(例如iPhone 8,Pixel 2,三星Galaxy),如果问题发生在移动设备上：N/A
- 从哪里安装的TensorFlow(源代码或二进制文件):二进制
- TensorFlow版本(请使用以下命令):nightly
- Python版本：3.7
- Bazel版本(如果从源代码编译):N/A
- GCC/编译器版本(如果从源代码编译):N/A
- CUDA/cuDNN版本：N/A
- GPU型号和内存：TPUv3-8
描述当前行为
InfeedEnqueueTuple具有可变性能和33%的减速。即使使用大量缓存，由于infeed操作符中的落后者，Infeed无法使TPUv3-8饱和。所有输入处理时间都报告在“while/body/_1/InfeedQueue/enqueue/*”中度过。
我正在附上大于45ms的infeed的性能分析器结果。请注意，每个线程在Enqueue时都有可变的时间。
描述预期行为
InfeedEnqueueTuple具有一致且快速的性能(每步不到45ms)。有时我可以观察到快速操作的周期，其中每个infeed始终为45ms(图片已附加)。然而，infeed最终回退到约60ms每步，如上所述。
重现问题的独立代码
我正在使用MLPerfv0.7 ResNet code与ResNet-18。即使将数据集cache()(例如，take(1).cache().repeat())放在prefetch()之前，问题仍然存在。
3条答案
按热度按时间vs3odd8k1#
tpu repository也存在同样的问题。
cgh8pdjw2#
你好，Michael,
感谢你的报告。当你提到"infeed最终回退到约60ms每步，如上所述。",这个60ms是否一致且从未减少？你是否尝试过在假数据上测试问题是否可重现？
5uzkadbs3#
你好，@rxsang,
问题仍然存在，60ms的延迟是正常行为。我无法始终获得45ms的延迟——这似乎出现在训练周期的开始。这可能与infeed队列有关，以及在评估时间或训练开始时(例如，初始化代码)队列可能会预取的可能性，给人们一种队列正在排空时没有瓶颈的错觉。
你可以通过降低输入尺寸的分辨率来减少infeed延迟，例如，将224x224减少到112x112(这会减少infeed体积),尽管我在新步骤时间中仍然看到抖动(由于较低的图像分辨率，整体减少了约2-3倍)。
对于伪数据：简而言之，是的，它应该容易重现。我相信你只需要使用标志
python3 resnet_main.py --tpu=$TPU_NAME --resnet_depth=18 --use_cache=False --model_dir=$MODEL_DIR运行tpu仓库。在最终预取之前，你还需要添加dataset = dataset.take(1).cache().repeat()。长答案：我尝试了两种合成Tensor的实现，它们都具有上述步骤时间问题。当我在输入管道中示例化批量大小为batch_sizex224x224x3的伪Tensor(在预取之前)时，我在MLPerf上也看到了相同的问题。同样，在TPU仓库中，我尝试使用空的数据目录，这具有相同的逻辑效果，尽管由于后续计算操作(批处理)而步长时间约为115ms。当我在这条管道上使用
dataset = dataset.take(1).cache().repeat()进行预取之前，计算就消失了，我只剩下了60-70ms的步长时间(如上所述)。我没有尝试在TPU上制作Tensor。