【发布时间】：2016-07-31 22:05:56
【问题描述】：
此问题最初发布于Github #3320。最好从那里开始，因为该线程中有更多关于原始问题的详细信息并且体积庞大，所以我不想在 StackOverflow 上重新发布。问题的总结是使用 GPU 处理 TensorFlow Graph 时的性能比 CPU 慢。包括 CPU/GPU 时间线（调试）以进行评估。其中一个 cmets 与优化 Graph 以加快处理速度有关，并请求提供一个玩具示例进行讨论。 “原始解决方案”是我的强化学习代码，它表现出缓慢的性能，并创建了一些已发布的代码供社区讨论和评估。
我已经附上了测试脚本以及一些原始数据、跟踪文件和 TensorBoard 日志文件，以加快任何审查。 CPUvsGPU testing.zip
讨论已移至 StackOverflow，因为该主题将使所有 Tensorflow 用户受益。我希望发现的是优化已发布图形性能的方法。 GPU 与 CPU 的问题可以分开，因为它可以通过更高效的 TensorFlow Graph 来解决。
我所做的是采用我的原始解决方案并剥离“游戏环境”。我用随机数据生成替换它。在这个游戏环境中，没有创建/修改 TensorFlow Graph。该结构紧跟/利用nivwusquorum's Github Reinforcement Learning Example。
在 2016 年 7 月 15 日，我做了一个“git pull”以前往 Tensorflow。我在启用和不启用 GPU 的情况下执行了图表，并记录了时间（见附图）。出乎意料的结果是 GPU 的性能优于 CPU（这是最初没有达到的预期）。所以这个带有支持库的代码“cpuvsgpu.py”在GPU上表现得更好。因此，我将注意力转向我的原始解决方案和已发布的代码之间可能存在的差异。我还将头部更新到 2016 年 7 月 17 日。 原始解决方案上的 CPU 和 GPU 之间的总体差异比我看到 47s CPU 与 71s GPU 的一周要近得多，因此确实有所改善。快速浏览一下新的跟踪与我的初始跟踪，似乎“摘要”可能已经改变，但也可能有其他改进。
我尝试了 2 种其他组合以更好地反映 原始解决方案 的功能。那些处于繁重的 CPU 负载（~60% - 70%）下，并通过并发执行该脚本来模拟。另一个变体是增加“数据 IO”，原始解决方案使用观察列表来随机选择观察进行训练。这个列表有一个固定的上限，然后开始删除列表中的第一项，同时追加新的。我想也许其中之一是减慢数据流到 GPU 的速度。不幸的是，这些版本都没有导致 CPU 的性能优于 GPU。我还运行了一个快速的 GPUTESTER 应用程序，该应用程序执行大型矩阵乘法，以了解任务大小的时序差异，并且符合预期。
我真的很想知道如何改进此图并减少小型 OPS 的数量。似乎这就是大部分表演可能进行的地方。学习将较小的操作组合成较大的操作而不影响图的逻辑（功能）的任何技巧会很好。
【问题讨论】：
-
与 7k x 7k matmul 的 GPU 性能进行比较可能是错误的指标。 IE，我看到您最慢的操作需要
-
我使用 7K x 7K 数据集的主要目的更多是为了确保 GPU 实际工作。因此，对于大型任务，GPU 很好。这对我来说更能证明 GPU 比正确安装 GPU 和 CUDA 编译的 CPU 慢的原始问题。
-
然后网络将 200 x 189 的 Batch 运行到 5 层中，每层之间有 Dropout()。这些层是 140、120、100、80 和 3 作为输出。
标签： tensorflow reinforcement-learning