python - HowTo 基准测试 : Reading Data

Question

我使用的是 tensorflow 0.10，我正在对 official HowTo on reading data 中的示例进行基准测试.此 HowTo 使用相同的 MNIST 示例说明了将数据移动到 tensorflow 的不同方法。

我对结果感到惊讶，我想知道是否有人有足够的底层理解来解释正在发生的事情。

在 HowTo 中基本上有 3 种读取数据的方法:

• Feeding:在 python 中构建小批量并使用 sess.run(..., feed_dict={x: mini_batch})
传递
• 从文件中读取:使用tf 操作打开文件并创建小批量。 (绕过 python 中的数据处理。)
• 预加载数据:将所有数据加载到单个 tf 变量或常量中，并使用 tf 函数将其分解为微型批处理。变量或常量被固定到 cpu，而不是 gpu。

我用来运行基准测试的脚本可以在 tensorflow 中找到:

• 喂食:examples/tutorials/mnist/fully_connected_feed.py
• 从文件读取:examples/how_tos/reading_data/convert_to_records.py和 examples/how_tos/reading_data/fully_connected_reader.py
• 预加载数据(常量):examples/how_tos/reading_data/fully_connected_preloaded.py
• 预加载数据(变量):examples/how_tos/reading_data/fully_connected_preloaded_var.py

除了最后两个脚本，我未经修改地运行了这些脚本，因为它们会崩溃——至少对于版本 0.10——除非我添加一个额外的 sess.run(tf.initialize_local_variables())。

主要问题

在 GTX1060 上运行 100 个小批量 100 个示例的时间:

• Feeding:~0.001 s
• 从文件读取:~0.010 s
• 预加载数据(常量):~0.010 s
• 预加载数据(变量):~0.010 s

这些结果令我非常惊讶。我原以为 Feeding 是最慢的，因为它几乎完成了 python 中的所有操作，而其他方法使用较低级别的 tensorflow/C++ 来执行类似的操作。这与我的预期完全相反。有谁知道发生了什么事吗？

次要问题

我可以访问另一台具有 Titan X 和较旧的 NVidia 驱动程序的机器。相对结果大致与上述一致，除了 Preloaded data (constant) 是灾难性的慢，单个小批量需要很多秒。

这是性能会因硬件/驱动程序的不同而有很大差异的已知问题吗？

Answer 1

10 月 9 日更新 速度变慢是因为计算运行速度太快，Python 无法抢占计算线程并安排预取线程。主线程中的计算需要 2 毫秒，显然这对于​​预取线程获取 GIL 来说太短了。预取线程具有较大的延迟，因此总是可以被计算线程抢占。因此，计算线程运行所有示例，然后大部分时间都阻塞在 GIL 上，因为一些预取线程被调度并将单个示例排入队列。解决方案是增加 Python 线程数，增加队列大小以适应整个数据集，启动队列运行器，然后暂停主线程几秒钟，让队列运行器预填充队列。

老东西

这出奇的慢。

这看起来是某种特殊情况，使最后 3 个示例不必要地变慢(大部分精力用于优化 ImageNet 等大型模型，因此 MNIST 没有得到太多关注)。

您可以通过获取时间线来诊断问题，如所述here

在这里are其中 3 个示例启用了时间线收集。

这是 feed_dict 实现的时间表

需要注意的重要一点是 matmul 占用了大量时间，因此读取开销并不显着

现在这是reader实现的时间表

您可以看到 QueueDequeueMany 上的操作出现瓶颈，耗时高达 45 毫秒。

如果你放大，你会看到一堆微小的 MEMCPY 和 Cast 操作，这是一些操作只有 CPU 的标志(parse_single_example)，并且出队必须调度多个独立的CPU->GPU 传输

对于下面禁用 GPU 的 var 示例，我没有看到微小的操作，但 QueueDequeueMany 仍然需要超过 10 毫秒。时间似乎与批量大小成线性比例，因此那里存在一些根本性的缓慢。备案#4740