单机训练优秀实践¶

2.1.1 同步数据读取¶

同步数据读取是一种简单并且直观的数据准备方式，代码示例如下：

# 读取数据
end = time.time()
for batch_id, batch in enumerate(train_reader):
    data_time = time.time() - end
    # 训练网络
    executor.run(feed=[...], fetch_list=[...])
    batch_time = time.time() - end
    end = time.time()

用户通过调用自己编写的reader函数，reader每次输出一个batch的数据，并将数据传递给执行器。因此数据准备和执行是顺序进行的，用户可通过加入Python计时函数 time.time() 来统计数据准备部分和执行部分所占用的时间。

2.1.2 异步数据读取¶

Paddle里面使用py_reader接口来实现异步数据读取，代码示例如下：

# 启动py_reader
train_py_reader.start()
batch_id = 0
try:
    end = time.time()
    while True:
        print("queue size: ", train_py_reader.queue.size())
        loss, = executor.run(fetch_list=[...])
        # ...
        batch_time = time.time() - end
        end = time.time()
        batch_id += 1
except fluid.core.EOFException:
    train_py_reader.reset()

使用异步数据读取时，Paddle的C++端会维护一个数据队列，Python端通过单独的线程向C++端的数据队列传入数据。用户可以在训练过程中输出数据队列中数据的个数，如果queue size始终不为空，表明Python端数据准备的速度比模型执行的速度快，这种情况下Python端的数据读取可能不是瓶颈。

此外，Paddle提供的一些FLAGS也能很好的帮助分析性能，比如通过设置 export FLAGS_reader_queue_speed_test_mode=True ，数据队列中的训练数据在被读取之后，不会从数据队列中弹出，这样能够保证数据队列始终不为空，这样就能够很好的评估出数据读取所占的开销。注意，FLAGS_reader_queue_speed_test_mode只能在分析的时候打开，正常训练模型时需要关闭。

执行调度器¶

为了更好的分析模型， ParallelExecutor 内部首先会将输入的 Program 转为SSA Graph，然后根据 build_strategy 中的配置，通过一系列的Pass对Graph进行优化，比如：memory optimize，operator fuse等优化。最后根据 execution_strategy 中的配置执行训练任务。

此外， ParallelExecutor 支持数据并行，即单进程多卡和多进程多卡，关于 ParallelExecutor 的具体介绍请参考 文档 。

为了统一 ParallelExecutor 接口和 Executor 接口，Paddle提供了 fluid.compiler.CompiledProgram 接口，在数据并行模式下，该接口底层调用的是 ParallelExecutor 。

BuildStrategy配置选项¶

说明：

• 关于 reduce_strategy ，在 ParallelExecutor 对于数据并行支持两种参数更新模式： AllReduce 和 Reduce 。在 AllReduce 模式下，各个节点上计算得到梯度之后，调用 AllReduce 操作，梯度在各个节点上聚合，然后各个节点分别进行参数更新。在 Reduce 模式下，参数的更新操作被均匀的分配到各个节点上，即各个节点计算得到梯度之后，将梯度在指定的节点上进行 Reduce ，然后在该节点上，最后将更新之后的参数Broadcast到其他节点。即：如果模型中有100个参数需要更新，训练时使用的是4个节点，在 AllReduce 模式下，各个节点需要分别对这100个参数进行更新；在 Reduce 模式下，各个节点需要分别对这25个参数进行更新，最后将更新的参数Broadcast到其他节点上.
• 关于 enable_backward_optimizer_op_deps ，在多卡训练时，打开该选项可能会提升训练速度。
• 关于 fuse_all_optimizer_ops ，目前只支持SGD、Adam和Momentum算法。注意：目前不支持sparse参数梯度 。
• 关于 fuse_all_reduce_ops ，多GPU训练时，可以对 AllReduce 操作进行融合，以减少 AllReduce 的调用次数。默认情况下会将同一layer中参数的梯度的 AllReduce 操作合并成一个，比如对于 fluid.layers.fc 中有Weight和Bias两个参数，打开该选项之后，原本需要两次 AllReduce 操作，现在只用一次 AllReduce 操作。此外，为支持更大粒度的参数梯度融合，Paddle提供了 FLAGS_fuse_parameter_memory_size 选项，用户可以指定融合AllReduce操作之后，每个 AllReduce 操作的梯度字节数，比如希望每次 AllReduce 调用传输64MB的梯度，export FLAGS_fuse_parameter_memory_size=64 。注意：目前不支持sparse参数梯度。
• 关于 mkldnn_enabled_op_types ，支持mkldnn库的Op有：transpose, sum, softmax, requantize, quantize, pool2d, lrn, gaussian_random, fc, dequantize, conv2d_transpose, conv2d, conv3d, concat, batch_norm, relu, tanh, sqrt, abs.

ExecutionStrategy配置选项¶

说明：

• 关于 num_iteration_per_drop_scope ，框架在运行过程中会产生一些临时变量，这些变量被放在local execution scope中。通常每经过一个batch就要清理一下local execution scope中的变量，但是由于GPU是异步设备，在清理local execution scope之前需要对所有的GPU调用一次同步操作，因此耗费的时间较长。为此我们在 execution_strategy 中添加了 num_iteration_per_drop_scope 选项。用户可以指定经过多少次迭代之后清理一次local execution scope。
• 关于 num_threads ，ParallelExecutor 根据Op之间的依赖关系确定Op的执行顺序，即：当Op的输入都已经变为ready状态之后，该Op会被放到一个队列中，等待被执行。 ParallelExecutor 内部有一个任务调度线程和一个线程池，任务调度线程从队列中取出所有Ready的Op，并将其放到线程队列中。 num_threads 表示线程池的大小。根据以往的经验，对于CPU任务，num_threads=2*dev_count 时性能较好，对于GPU任务，num_threads=4*dev_count 时性能较好。注意：线程池不是越大越好。

执行策略配置推荐¶

• 在显存足够的前提下，建议将 exec_strategy.num_iteration_per_drop_scope 设置成一个较大的值，比如设置 exec_strategy.num_iteration_per_drop_scope=100 ，这样可以避免反复地申请和释放内存。该配置对于一些模型的优化效果较为明显。
• 对于一些较小的模型，比如mnist、language_model等，多个线程乱序调度op的开销大于其收益，因此推荐设置 exec_strategy.num_threads=1 。

CPU训练设置¶

• 如果使用CPU做数据并行训练，需要指定环境变量CPU_NUM，这个环境变量指定程序运行过程中使用的 CPUPlace 的个数。
• 如果使用CPU进行数据并行训练，并且 build_strategy.reduce_strategy = fluid.BuildStrategy.ReduceStrategy.Reduce ，所有 CPUPlace 上的参数是共享的，因此对于一些使用CPU进行数据并行训练的模型，选用 Reduce 模式可能会更快一些。