rlpyt 是BAIR(Berkeley Artificial Intelligence Research，伯克利人工智能研究所)开源的一个强化学习(RL)框架。我之前写了一篇它的简介。 本文是上一篇文章的续文，继续分析CpuSampler的源码。
本文将分析 CPU并行模式下的 ParallelSamplerBase 类的worker实现。

 worker的代码在哪
rlpyt/samplers/parallel/worker.py

 worker是做什么用的
用于采样agent与environment交互得到的数据。
文章来源：https://www.codelast.com/
 代码分析
我直接在代码里加了大量注释：

def initialize_worker(rank, seed=None, cpu=None, torch_threads=None):
    """
    初始化采样用的worker。

    :param rank: 采样进程的标识序号。
    :param seed: 种子，一个整数值。
    :param cpu: CPU序号，例如 0, 1, 2 等等。
    :param torch_threads: CPU并发执行的线程数。
    """
    log_str = f"Sampler rank {rank} initialized"
    cpu = [cpu] if isinstance(cpu, int) else cpu
    p = psutil.Process()
    try:
        if cpu is not None:
            p.cpu_affinity(cpu)  # 设置CPU亲和性(MacOS不支持)
        cpu_affin = p.cpu_affinity()
    except AttributeError:
        cpu_affin = "UNAVAILABLE MacOS"
    log_str += f", CPU affinity {cpu_affin}"
    torch_threads = (1 if torch_threads is None and cpu is not None else
        torch_threads)  # Default to 1 to avoid possible MKL hang.
    if torch_threads is not None:
        torch.set_num_threads(torch_threads)  # 设置CPU并发执行的线程数
    log_str += f", Torch threads {torch.get_num_threads()}"
    if seed is not None:
        set_seed(seed)
        time.sleep(0.3)  # (so the printing from set_seed is not intermixed)
        log_str += f", Seed {seed}"
    logger.log(log_str)


def sampling_process(common_kwargs, worker_kwargs):
    """
    Arguments fed from the Sampler class in master process.

    采样进程函数。

    :param common_kwargs: 各个worker通用的参数列表。
    :param worker_kwargs: 各个worker可能不同的参数列表。
    """
    c, w = AttrDict(**common_kwargs), AttrDict(**worker_kwargs)
    initialize_worker(w.rank, w.seed, w.cpus, c.torch_threads)
    # 初始化用于training的environment实例和collector实例
    envs = [c.EnvCls(**c.env_kwargs) for _ in range(w.n_envs)]
    collector = c.CollectorCls(
        rank=w.rank,
        envs=envs,
        samples_np=w.samples_np,
        batch_T=c.batch_T,
        TrajInfoCls=c.TrajInfoCls,
        agent=c.get("agent", None),  # Optional depending on parallel setup.
        sync=w.get("sync", None),
        step_buffer_np=w.get("step_buffer_np", None),
        global_B=c.get("global_B", 1),
        env_ranks=w.get("env_ranks", None),
    )
    agent_inputs, traj_infos = collector.start_envs(c.max_decorrelation_steps)  # 这里会做收集(采样)第一批数据的工作
    collector.start_agent()  # collector的初始化

    # 初始化用于evaluation的environment实例和collector实例
    if c.get("eval_n_envs", 0) > 0:
        eval_envs = [c.EnvCls(**c.eval_env_kwargs) for _ in range(c.eval_n_envs)]
        eval_collector = c.eval_CollectorCls(
            rank=w.rank,
            envs=eval_envs,
            TrajInfoCls=c.TrajInfoCls,
            traj_infos_queue=c.eval_traj_infos_queue,
            max_T=c.eval_max_T,
            agent=c.get("agent", None),
            sync=w.get("sync", None),
            step_buffer_np=w.get("eval_step_buffer_np", None),
        )
    else:
        eval_envs = list()

    ctrl = c.ctrl  # 用于控制多个worker进程同时运行时能正确运作的控制器
    ctrl.barrier_out.wait()  # 每个worker都有一个wait()，加上ParallelSamplerBase.initialize()中的一个wait()，刚好n_worker+1个
    while True:
        collector.reset_if_needed(agent_inputs)  # Outside barrier?
        ctrl.barrier_in.wait()
        if ctrl.quit.value:  # 在主进程中set了这个值为True时，所有worker进程会退出采样
            break
        if ctrl.do_eval.value:  # 在主进程的evaluate_agent()函数里set了这个值为True时，这里才会收集evaluation用的数据
            eval_collector.collect_evaluation(ctrl.itr.value)  # Traj_infos to queue inside.
        else:  # 不是做evaluation
            agent_inputs, traj_infos, completed_infos = collector.collect_batch(
                agent_inputs, traj_infos, ctrl.itr.value)
            for info in completed_infos:
                c.traj_infos_queue.put(info)  # 向所有worker进程共享的队列塞入当前worker的统计数据
        ctrl.barrier_out.wait()

    # 清理environment
    for env in envs + eval_envs:
        env.close()

文章来源：https://www.codelast.com/
在worker的代码中，比较绕的就是，worker是怎么把采样到的数据返回放到replay buffer里的？
在上一篇文章中，我们知道 ParallelSamplerBase.initialize() 函数初始化了replay buffer：

examples = self._build_buffers(env, bootstrap_value)

以及：

def _build_buffers(self, env, bootstrap_value):
    self.samples_pyt, self.samples_np, examples = build_samples_buffer(
        self.agent, env, self.batch_spec, bootstrap_value,
        agent_shared=True, env_shared=True, subprocess=True)
    return examples

在这里，self.samples_np 对应的是replay buffer的存储对象。而 worker 的参数 workers_kwargs 初始化的时候，会把 self.samples_np 拆分成多个slice，并传入 worker：

samples_np=self.samples_np[:, slice_B],

在 worker 中，构造 collector 对象的时候，会把这个传入的 samples_np 再传给 collector 的构造函数。这样，replay buffer 就与 collector 关联起来了。
最后，在 collector.collect_batch() 的时候，会把采样得到的数据放入 samples_np 中，也就是相当于放到了 replay buffer 里。
文章来源：https://www.codelast.com/
这一节就到这，且听下回分解。
文章来源：https://www.codelast.com/
➤➤ 版权声明 ➤➤ 
转载需注明出处：codelast.com 
感谢关注我的微信公众号（微信扫一扫）：

rlpyt 是BAIR(Berkeley Artificial Intelligence Research，伯克利人工智能研究所)开源的一个强化学习(RL)框架。我之前写了一篇它的简介。 本文是上一篇文章的续文，继续分析CpuSampler的源码。
我们已经知道了CpuSampler有两个父类：BaseSampler 和 ParallelSamplerBase。其中，BaseSampler主要是定义了一堆接口，没什么好说的，因此本文接着分析另一个父类 ParallelSamplerBase。在 ParallelSamplerBase 中，初始化函数 initialize() 做了很多重要的工作，已经够写一篇长长的文章来分析了，这正是本文的主要内容。

 初始化函数 initialize() 做了哪些重要工作
一句话总结 initialize() 的重要功能：计算一些特殊参数的值，初始化agent，创建并行控制器，创建并启动多个worker进程。
这里说的“并行控制器”(parallel ctrl)是指用Python multiprocessing模块来实现并行功能的时候，需要使用一些变量来协调各个并行的进程，使它们可以正确运作。这些用于协调的变量就是“并行控制器”。

 计算特殊参数的值
在并行模式下，有些参数（比如采样用的worker的数量）不是由用户直接设置的，而是计算出来的。而且这样的参数还挺多，所以有大段大段的代码都用来干这事了。
如果下面的代码没有注释的话，肯定会让人一头雾水：

n_envs_list = self._get_n_envs_list(affinity=affinity)  # 用户设置的worker数不一定与environment数相匹配，这里会重新调整
self.n_worker = n_worker = len(n_envs_list)  # 经过调整之后的worker数
B = self.batch_spec.B  # environment实例的数量
global_B = B * world_size  # "平行宇宙"概念下的environment实例的数量
env_ranks = list(range(rank * B, (rank + 1) * B))  # 含义可参考：https://www.codelast.com/?p=10932
self.world_size = world_size
self.rank = rank

if self.eval_n_envs > 0:  # 在example_*.py中传入的参数
    self.eval_n_envs_per = max(1, self.eval_n_envs // n_worker)  # 计算每个worker至少承载几个evaluation的environment(至少1)
    self.eval_n_envs = eval_n_envs = self.eval_n_envs_per * n_worker  # 保证至少有"worker数量"个eval environment实例
    logger.log(f"Total parallel evaluation envs: {eval_n_envs}.")
    self.eval_max_T = eval_max_T = int(self.eval_max_steps // eval_n_envs)

最为“神奇”的就是 self._get_n_envs_list() 这个函数，它用来计算每个worker承载几个environment实例。这个说法是不是特别奇怪？原因是：用户可以指定environment实例的数量，也可以指定worker的数量，但这两个数量可能是不相等的，于是，要么worker数不够，要么worker数有多；在第1种情况下，一个worker需要带>1个environment实例，在第2种情况下，不需要那么多worker，所以要减少worker的数量，才能保证一个worker刚好带一个environment实例。
文章来源：https://www.codelast.com/
我给 self._get_n_envs_list() 函数加上了注释，相信足以让大家理解它的功能了：

def _get_n_envs_list(self, affinity=None, n_worker=None, B=None):
    """
    根据environment实例的数量(所谓的"B")，以及用户设定的用于采样的worker的数量(n_worker)，来计算得到一个list，这个list的元素的总数，
    就是最终的worker的数量；而这个list里的每个元素的值，分别是每个worker承载的environment实例的数量。

    :param affinity: 一个字典(dict)，包含硬件亲和性定义。
    :param n_worker: 用户设定的用于采样的worker的数量。
    :param B: environment实例的数量。
    :return 一个list，其含义如上所述。
    """
    B = self.batch_spec.B if B is None else B  # 参考BatchSpec类，可以认为B是environment实例的数量
    n_worker = len(affinity["workers_cpus"]) if n_worker is None else n_worker  # worker的数量(不超过物理CPU数否则在别处报错)
    """
    当environment实例的数量<worker的数量时，例如有8个worker(即8个物理CPU)，5个environment实例，每一个物理CPU运行一个environment，
    那么此时会有3个物理CPU多余，此时就会把worker的数量设置成和environment实例数量一样，使得每个CPU都刚好运行一个environment实例。
    """
    if B < n_worker:
        logger.log(f"WARNING: requested fewer envs ({B}) than available worker "
            f"processes ({n_worker}). Using fewer workers (but maybe better to "
            "increase sampler's `batch_B`.")
        n_worker = B
    n_envs_list = [B // n_worker] * n_worker
    """
    当environment实例的数量不是worker数量的整数倍时，每个worker被分配到的environment实例的数量是不均等的。
    """
    if not B % n_worker == 0:
        logger.log("WARNING: unequal number of envs per process, from "
            f"batch_B {self.batch_spec.B} and n_worker {n_worker} "
            "(possible suboptimal speed).")
        for b in range(B % n_worker):
            n_envs_list[b] += 1
    return n_envs_list

文章来源：https://www.codelast.com/
 初始化agent
agent对象只有一个！并不是每一个worker进程都对应到不同的agent对象！这是理解CpuSampler时需要知晓的一个重要概念。
agent通过以下代码初始化（ParallelSamplerBase.initialize() 函数）：

env = self.EnvCls(**self.env_kwargs)
self._agent_init(agent, env, global_B=global_B,
    env_ranks=env_ranks)
examples = self._build_buffers(env, bootstrap_value)
env.close()
del env

可以看到，这里初始化了environment对象，并把它作为一个参数传给了agent初始化函数 self._agent_init()，事实上，在 self._agent_init() 函数里，只用到了 env 对象的 spaces 这个属性，而没有引用整个 env 对象，因此在使用完之后，使用 env.close() 以及 del env 来清理掉env不会有问题。
self._build_buffers() 是一个非常复杂的操作，它的主要功能是创建强化学习中必备的replay buffer。直觉上，有人可能认为replay buffer这个东西，不就是创建一个list或者类似的数据结构就能搞定的吗？但实际上不是这么简单，从这个函数一级级点进去就会发现代码还不少，而且它里面甚至还用到了Python multiprocessing，所以创建replay buffer的实现就不在本文分析了。
文章来源：https://www.codelast.com/
self._agent_init() 函数的实现很简单：

def _agent_init(self, agent, env, global_B=1, env_ranks=None):
    agent.initialize(env.spaces, share_memory=True,
        global_B=global_B, env_ranks=env_ranks)
    self.agent = agent

在这里看到：agent初始化之后，赋值给了 self.agent，这就是 CpuSampler 中唯一使用的 agent 对象。
文章来源：https://www.codelast.com/
 创建并行控制器
并行控制器(parallel ctrl)用于协调多个采样用的worker进程。
在 initialize() 里，创建并行控制器的代码只有一句：

def _build_parallel_ctrl(self, n_worker):
    """
    创建用于控制并行训练过程的一些数据结构。

    multiprocessing.RawValue：不存在lock的多进程间共享值。
    multiprocessing.Barrier：一种简单的同步原语，用于固定数目的进程相互等待。当所有进程都调用wait以后，所有进程会同时开始执行。
    multiprocessing.Queue：用于多进程间数据传递的消息队列。

    :param n_worker: 真正的worker数(不一定等于用户设置的那个原始值)。
    """
    self.ctrl = AttrDict(
        quit=mp.RawValue(ctypes.c_bool, False),
        barrier_in=mp.Barrier(n_worker + 1),
        barrier_out=mp.Barrier(n_worker + 1),
        do_eval=mp.RawValue(ctypes.c_bool, False),
        itr=mp.RawValue(ctypes.c_long, 0),
    )
    self.traj_infos_queue = mp.Queue()
    self.eval_traj_infos_queue = mp.Queue()
    self.sync = AttrDict(stop_eval=mp.RawValue(ctypes.c_bool, False))

这里AttrDict是一个“扩展的”dict，mp就是Python multiprocessing模块，而Python multiprocessing是一个巨大的话题，我自己也只是初步了解，所以没办法讲透彻，这里只举两个例子，来说明这些并行控制器的作用：
 ctrl.quit 可以理解为一个bool类型的进程间共享变量。在 minibatch_rl.py 中，训练完成后，会执行 shutdown()，它会调用 sampler.shutdown()，从而会把 ctrl.quit 的值设置为True；同时，在 worker.py 中会看到，当检测到 ctrl.quit 的值为True时，会退出采样过程。所有采样的worker进程都受这个变量控制。所以这样就做到了在主进程中控制并行跑的worker进程。
 multiprocessing.Queue() 用于在多进程间传递消息。在每个采样的worker进程中，会把收集到的trajectory info放到同一个traj_infos_queue中，在主进程中会把汇总的trajectory info进一步处理成统计数据，然后记日志、打印到屏幕上，等等。
文章来源：https://www.codelast.com/
 创建并启动多个worker进程
worker进程用于采样(agent与environment交互得到的)数据。
在创建这些进程之前，需要先为它们构建所需的参数：

common_kwargs = self._assemble_common_kwargs(affinity, global_B)
workers_kwargs = self._assemble_workers_kwargs(affinity, seed, n_envs_list)

为什么需要分成 common_kwargs 以及 workers_kwargs 两个参数？这是因为：对每个worker进程来说，有些参数是通用的，有些参数是不通用的（例如，每个worker使用的CPU数量、承载的environment实例的数量等），因此，rlpyt把它们分成了两拨，分别放在两个对象里。

在准备好了参数之后，就开始创建多个worker进程，并把它们启动起来了：

# 创建一批子进程
target = sampling_process if worker_process is None else worker_process
self.workers = [mp.Process(target=target,
    kwargs=dict(common_kwargs=common_kwargs, worker_kwargs=w_kwargs))
    for w_kwargs in workers_kwargs]
# 启动子进程
for w in self.workers:
    w.start()

self.ctrl.barrier_out.wait()  # Wait for workers ready (e.g. decorrelate).

在这里，使用的是 multiprocessing.Process() 来创建的进程，target 为进程函数名，进程函数是可以自行指定的，rlpyt也提供了默认的实现，即 worker.py 中的 sampling_process() 函数。采样进程的实现代码 worker.py 虽然不长，但要完全看懂并不容易，所以留到后面的文章再分析。
在worker进程启动之后，它就进入了持续的采样过程。注意上面代码的最后一句 self.ctrl.barrier_out.wait()，这里使用了 multiprocessing的Barrier来控制各个worker进程同步。由于 barrier_out 创建的时候是这样的：

barrier_out=mp.Barrier(n_worker + 1)

所以，它需要 n_worker + 1 个 wait() 才能让所有进程同时“解锁”（即同时开始执行），在 initialize() 函数里的 self.ctrl.barrier_out.wait() 算一个，每个worker函数——即 sampling_process()——里也分别有一个 barrier_out.wait()，所有这些 wait() 加起来刚好是 n_worker + 1 个，这使得 initialize() 函数执行完，所有 worker 就会“跑起来”开始采样。
文章来源：https://www.codelast.com/
这一节就到这，且听下回分解。
文章来源：https://www.codelast.com/
➤➤ 版权声明 ➤➤ 
转载需注明出处：codelast.com 
感谢关注我的微信公众号（微信扫一扫）：

查看关于 rlpyt 的更多文章请点击这里。

rlpyt 是BAIR(Berkeley Artificial Intelligence Research，伯克利人工智能研究所)开源的一个强化学习(RL)框架。我之前写了一篇它的简介。 

在单机上支持丰富的并行(Parallelism)模式是 rlpyt 有别于很多其他强化学习框架的一个显著特征。rlpyt可以使用纯CPU，或CPU、GPU混合的方式来并行执行训练过程。

 rlpyt的sampler模块概览
rlpyt有一种叫做“Sampler”的模块，我们姑且称之为“采样器”，它用于采样/收集agent与environment交互的数据，对于不同的训练模式(串行、并行、异步)，rlpyt有不同的sampler实现：

├── async_

│   ├── action_server.py

│   ├── alternating_sampler.py

│   ├── base.py

│   ├── collectors.py

│   ├── cpu_sampler.py

│   ├── gpu_sampler.py

│   └── serial_sampler.py

├── base.py

├── buffer.py

├── collections.py

├── collectors.py

├── parallel

│   ├── base.py

│   ├── cpu

│   │   ├── collectors.py

│   │   └── sampler.py

│   ├── gpu

│   │   ├── action_server.py

│   │   ├── alternating_sampler.py

│   │   ├── collectors.py

│   │   └── sampler.py

│   └── worker.py

├── serial

│   ├── collectors.py

│   └── sampler.py

直观感受：串行(serial)模式的sampler代码最简单，并行(parallel)模式下的cpu并行实现比gpu并行实现简单一些，异步(async_)模式下的实现最复杂。
不知道会不会有人好奇：为什么异步模式的module名是带下划线的async_而不是async呢？因为async在Python 3里是一个关键字，rlpyt的作者应该是为了避开这个问题才加了一个下划线。
文章来源：https://www.codelast.com/
在前面的系列源码分析文章中，我已经分析过了串行(serial)模式下的sampler代码，本文想分析的是并行(parallel)模式下的CPU并行实现代码，也就是树形图里的这一部分：

├── cpu

│   ├── collectors.py

│   └── sampler.py

CPU sampler在采样/收集数据的时候，完全不使用GPU，因此相对于GPU sampler来说会简单得多（只是相对而言）。它只有两个代码文件。当然，由于这两个文件里的class会继承其他父类，因此最终有关联的代码文件远不止这两个。下面我们就来详细分析一下。
文章来源：https://www.codelast.com/
 CPU sampler概览
CPU sampler的实现类是 CpuSampler，一级级向上，有多个父类：

这个BaseSampler，同时也是 GpuSampler 的最顶级父类。
文章来源：https://www.codelast.com/
前面的文章已经讲过，sampler是collector外面包装的一层，真正去做数据收集工作的是collector类。对 CpuSampler 来说，它对应的collector代码实现在collectors.py中，里面包含多个collector类：CpuResetCollector，CpuWaitResetCollector，CpuEvalCollector等。
所以应该从两条线来分析sampler class，一条线是 CpuSampler→ParallelSamplerBase→BaseSampler，另一条线是collector class。为了不让篇幅过长，本文只分析第一条线，把collector class留到后面的文章。

 BaseSampler：一个主要用于定义各种接口的父类
最顶层的父类BaseSampler主要定义了各种接口，很多函数都没有实现：

def initialize(self, *args, **kwargs):
    raise NotImplementedError

def obtain_samples(self, itr):
    raise NotImplementedError  # type: Samples

def evaluate_agent(self, itr):
    raise NotImplementedError

def shutdown(self):
    pass

而__init__()函数还是像之前见识过的套路一样，使用save__init__args()来把可变参数保存到对象属性里：

save__init__args(locals())

其余就没啥好说的了。
文章来源：https://www.codelast.com/
 CpuSampler：主要充当一个入口
CpuSampler类的代码相当少，它主要充当一个入口，而不是实现主要逻辑：

class CpuSampler(ParallelSamplerBase):

    def __init__(self, *args, CollectorCls=CpuResetCollector,
            eval_CollectorCls=CpuEvalCollector, **kwargs):
        # e.g. or use CpuWaitResetCollector, etc...
        super().__init__(*args, CollectorCls=CollectorCls,
            eval_CollectorCls=eval_CollectorCls, **kwargs)

    def obtain_samples(self, itr):
        self.agent.sync_shared_memory()  # New weights in workers, if needed.
        return super().obtain_samples(itr)

    def evaluate_agent(self, itr):
        self.agent.sync_shared_memory()
        return super().evaluate_agent(itr)

其中，obtain_samples() 用于采样一批数据，evaluate_agent() 用于评估agent——或者说是评估模型，差不多的意思。
这两个函数都调用父类ParallelSamplerBase的同名函数来实现对应功能，后面会在其他文章里具体分析。
在这两个函数的开头，都有一个 self.agent.sync_shared_memory() 的操作，这是干嘛？
其功能是：在并行模式下，采样/评估之前先同步shared model。
sync_shared_memory() 函数的实现是：

def sync_shared_memory(self):
    if self.shared_model is not self.model:
        self.shared_model.load_state_dict(strip_ddp_state_dict(
            self.model.state_dict()))

这里的意思是：当 self.model 被训练过之后，可能已经和 self.shared_model 不是一个东西了，此时需要把 self.model 的参数copy到 self.shared_model 里。
strip_ddp_state_dict()函数是一个很tricky的操作，为什么从 self.model 取出来的 state_dict 不能直接用 load_state_dict() 加载到 self.shared_model 里呢？关于这一点，我觉得代码的注释里写得比较清楚，建议直接去看它。
这里就产生了两个问题：✓ 什么是shared model？ ✓ 为什么要同步shared model？
文章来源：https://www.codelast.com/
 什么是shared model
从名字上猜测，shared model就是一个“共享的模型”，之所以会有“共享”这个概念，是因为在多个进程中都需要使用模型，所以才需要“共享”。
rlpyt在并行(parallel)模式下，会产生多个“worker”跑在多个进程里，这些worker会各自在environment中采样，采样得到的数据用于优化模型。
 worker在采样的时候会选择action，此时会用模型来做action selection。
 所有worker关联到同一个agent对象(agent包含了策略网络的参数)，只有一个进程会去做优化模型(也就是反向传播之类)的工作，这一点要特别注意，是一个进程，而不是所有worker进程！
 在每个agent对象内部，会有一个类型为 torch.nn.Module 的 self.model 对象，还有一个 self.shared_model 对象，我们可以从agent的父类 BaseAgent 的__init__()函数中看到这一点：

def __init__(self, ModelCls=None, model_kwargs=None, initial_model_state_dict=None):
    save__init__args(locals())
    self.model = None  # type: torch.nn.Module
    self.shared_model = None

在agent对象初始化的时候，即在 BaseAgent.initialize() 函数中，会把 self.shared_model 初始化成和 self.model 一样：

def initialize(self, env_spaces, share_memory=False, **kwargs):
    """In this default setup, self.model is treated as the model needed
    for action selection, so it is the only one shared with workers."""
    self.env_model_kwargs = self.make_env_to_model_kwargs(env_spaces)
    self.model = self.ModelCls(**self.env_model_kwargs,
        **self.model_kwargs)
    if share_memory:
        self.model.share_memory()
        self.shared_model = self.model

上面代码中的 if share_memory 这个条件是否得到满足呢？
在并行模式下，也就是从 ParallelSamplerBase._agent_init() 函数的代码我们可以发现，agent初始化的时候 share_memory 参数被设置成了 True：

agent.initialize(env.spaces, share_memory=True,
    global_B=global_B, env_ranks=env_ranks)

所以 if share_memory 的条件是满足的。
文章来源：https://www.codelast.com/
如果使用GPU训练模型，那么rlpyt会把model挪到用户指定的设备上，而shared_model需要放在CPU上(经查，PyTorch的Tensor或模型参数也是可以放在GPU上共享的，但有一些容易出错、需要谨慎处理的细节，所以我猜由于这个原因，作者选择了把shared_model放在CPU上)，因此，这里创建出来了一个self.shared_model，用来防止之后self.model有可能被挪到GPU的情况发生——如果发生了，self.shared_model这个放在CPU上的模型才是多个进程间的共享模型。
那么这个shared_model在CpuSampler中真的有用吗？下面我们就一层层地挖下去，看看这个东西到底有没有用。
文章来源：https://www.codelast.com/
 为什么要同步shared model
先说结论：在CpuSampler里，完全不需要同步。
为了确认这个结论，我们看看在使用CPU sampler的时候，BaseAgent类里的 self.shared_model 到底用在了什么地方。通过搜索代码，发现除了 sync_shared_memory() 函数之外，只有两个地方在用：
1、上面提到的 BaseAgent.initialize() 函数。在这里，对 self.shared_model 只有赋值操作，没有使用。
2、to_device() 函数：

def to_device(self, cuda_idx=None):
    if cuda_idx is None:
        return
    if self.shared_model is not None:
        self.model = self.ModelCls(**self.env_model_kwargs,
            **self.model_kwargs)
        self.model.load_state_dict(self.shared_model.state_dict())
    self.device = torch.device("cuda", index=cuda_idx)
    self.model.to(self.device)

在这一段代码中，当使用CPU sampler时，cuda_idx 为 None，因此直接return了，self.shared_model 根本触达不到。
此外，BaseAgent的其他所有使用 self.shared_model 的地方，都是和异步(async_)模式相关的，和并行(parallel)模式无关。
因此，对CpuSampler来说，shared_model没用，不需要调用 sync_shared_memory() 来同步shared_model。
文章来源：https://www.codelast.com/
 shared model在什么情况下有意义
对CpuSampler来说，BaseAgent里的 self.model 对各个采样的worker来说都会实时更新，在action selection的时候使用的也是 self.model，而不是 self.shared_model，所以 shared_model 对CpuSampler来说其实没有意义。
但在其他模式下 shared model 还是有意义的，而且机制更复杂。
文章来源：https://www.codelast.com/
这一节就到这，且听下回分解。
文章来源：https://www.codelast.com/
➤➤ 版权声明 ➤➤ 
转载需注明出处：codelast.com 
感谢关注我的微信公众号（微信扫一扫）：

rlpyt 是BAIR(Berkeley Artificial Intelligence Research，伯克利人工智能研究所)开源的一个强化学习(RL)框架。我之前写了一篇它的简介。 

在单机上全面的并行（Parallelism）特性是 rlpyt 有别于很多其他强化学习框架的一个显著特征。在前面的简介文章中，已经介绍了 rlpyt 支持多种场景下的并行训练。而这种“武功”是怎么修炼出来的呢？它是站在了巨人的肩膀上——通过PyTorch的多进程(multiprocessing)机制来实现的。
所以你知道为什么 rlpyt 不使用TensorFlow这样的框架来作为后端了吧，因为TensorFlow根本就没有这种功能。TensorFlow只能靠类似于Ray这样的并行计算框架的帮助，才能支撑起全方位的并行特性。

 为什么说TensorFlow自身的并行能力并不适用于强化学习场景
限于我掌握的知识，我不保证下面的结论都是正确的，请专家们不吝赐教。
相信很多刚开始学写强化学习程序的人，都是从莫凡的强化学习教程开始的，莫凡的强化学习教程使用的是TensorFlow来实现的（很久以前看到是这样，后来我没有再去关注过，不知道他有没有发布在其他ML框架下的RL教程）。
看过一部分莫凡RL代码的人都会知道，里面用TensorFlow实现的静态图多进程“并行”训练逻辑有多么晦涩（而且并行其实是伪并行，说到底还是串行）。
我个人认为，如果一个初学者从这样的程序入手，其实就相当于“劝退”，也就是说：这程序这么难写，你还是别学了吧。如果有与莫凡的RL代码逻辑对等的PyTorch代码，那绝对会是另一番景象。
文章来源：https://www.codelast.com/
有人会说，明明TensorFlow就支持并行训练的啊！现在很多模型不就是通过多机多卡分布式训练的吗？
然而到了强化学习场景下，就不是这么一回事了：强化学习和监督学习很不一样。在强化学习场景下，如果要并行训练的话，会需要多个agent，与多个environment交互，对应到程序就是多个进程/线程。与environment交互的过程，可以是纯CPU计算，也可以是CPU/GPU混合计算（例如，inference得到action的过程就可以放在GPU上加速），但这个过程不能是纯GPU计算的过程。以Atari游戏模拟器为例，调用ALE接口得到Atari环境的反馈，这个过程就是CPU计算的，不能在GPU上计算。整个强化学习的流程，数据就是这样不断地在CPU/GPU之间流转，当然你可以使用纯CPU，但假设你使用了GPU的话，也只能在一小部分工作中使用GPU，其实CPU的工作也很重。反观supervised learning，当你把数据预处理好了之后，就可以一次性地喂给GPU，GPU在单机单卡训练的时候，可以把结果全部算完了再吐回给CPU；就算是Distributed TensorFlow，也不适用于强化学习，因为Distributed TensorFlow的并行功能是为了并行地使用GPU对吧？但强化学习的采样过程是使用CPU，按我的理解这部分工作不能使用Distributed TensorFlow来并行，相反PyTorch有multiprocessing可以做到；而计算梯度之类的工作用Distributed TensorFlow就可以并行了——但别的DL框架例如PyTorch也可以啊。
所以Distributed TensorFlow在RL场景下有什么优势？没看出来。
关于TensorFlow在强化学习场景下的应用，莫凡当时也在知乎向网友提问如何能在TF下较好地实现强化学习的并行功能，结论大概就是：还是用PyTorch吧！
另外，知乎上有一个讨论，提问者对GPU并行训练DRL模型的并行过程提出了疑问。第一个回答里面说“采样过程可以并行”，但作者说的并不是指Distributed TensorFlow支持这个功能。
所以我认为，TensorFlow由于缺少了类似于PyTorch multiprocessing那样的模块，它只能借助于类似于Ray的并行计算框架，也就是在外面再“包装一层”，才能把TF对“全面的并行强化学习”的缺陷给修补上。
文章来源：https://www.codelast.com/
 PyTorch的多进程处理功能
参考这段话：

由于全局解释器锁（global interpreter lock，GIL）的 Python 默认实现不允许并行线程进行并行执行，所以为了解决该问题，Python 社区已经建立了一个标准的多进程处理模块，其中包含了大量的实用程序（utility），它们可以使得用户轻易地生成子进程并能够实现基础的进程间通信原语（communication primitive）。

 

然而，原语的实现使用了与磁盘上持久性（on-disk persistence）相同格式的序列化，这在处理大规模数组时效率不高。所以，PyTorch 将Python 的 multiprocessing 模块扩展为 torch.multiprocessing，这就替代了内置包，并且自动将发送至其他进程的张量数据移动至共享内存中，而不用再通过通信渠道发送。

 

PyTorch 的这一设计极大地提升了性能，并且弱化了进程隔离（process isolation），从而产生了更类似于普通线程程序的编程模型。

看看就好，想深入了解的话请移步PyTorch文档。
文章来源：https://www.codelast.com/
 rlpyt的并行(parallelism)功能的局限
rlpyt瞄准的是单机上的RL训练效率的极致优化，它不支持多机训练。在单机硬件资源允许的范围内，rlpyt可以让RL模型训练很快，但如果你的训练数据占用的资源远远超过了单机硬件的范围，那么就只能利用支持分布式训练的框架了，例如构建在Ray之上的框架RLlib，又例如基于PaddlePaddle的PARL等。
这里值得一提的是，PARL号称它与RLlib进行了IMPALA算法下的对比测试，其数据吞吐量（同等计算资源下的数据收集速度）足以吊打RLlib，所以PARL看起来是一个有前途的框架。
文章来源：https://www.codelast.com/
➤➤ 版权声明 ➤➤ 
转载需注明出处：codelast.com 
感谢关注我的微信公众号（微信扫一扫）：