https://dailydreamer.me/tags/%E6%8A%80%E6%9C%AF/ Recent content in 技术 on dailydreamer Hugo -- gohugo.io zh-cn Sat, 29 Feb 2020 17:31:29 +0800 https://dailydreamer.me/posts/2020-02-29-large-scale-model-training/ Sat, 29 Feb 2020 17:31:29 +0800 https://dailydreamer.me/posts/2020-02-29-large-scale-model-training/ 大规模模型训练涉及多GPU时的并行、通讯以及模型过大等问题。 并行方式 对于n个GPU 数据并行：不同的GPU输入不同的数据，运行相同的完整的模型。 模型并行：不同的GPU运行模型的不同部分，比如多层网络的不同层； 如果模型能够放进单个GPU的显存中，可以使用数据并行加速。 如果模型不能够放进单个GPU的显存中，但可以放进多个GPU显存，可以考虑模型并行。 模型并行加速：pipeline 对于模型并行，如果只是简单将模型不同部分放在不同GPU上，对GPU利用率很低。如下图所示。 此时可以采用流水线技术，将一个batch数据切分为多个mini-batch，每个GPU运行完一个mini-batch就将数据传输到下一阶段GPU，然后继续运行下一个mini-batch，可成倍提高GPU利用效率。如下图所示： GPipe提供了一种模型并行流水线的实现 https://arxiv.org/abs/1811.06965 通讯算法 对于n个GPU Parameter Server：GPU 0将数据分成n份分到各个卡上，每张卡负责自己的那一份batch的训练，得到grad后，返回给GPU 0上做累积，得到更新的权重参数后，再分发给各个卡。 Ring AllReduce：n张以环形相连，每张卡都有左手卡和右手卡，一个负责接收，一个负责发送，循环n-1次完成梯度累积，再循环n-1次做参数同步。分为Scatter Reduce和All Gather两个环节。 Parameter Server是一种更通用的通讯算法，对于很多分布式机器学习算法都适用。但是在deep learning这一通讯量巨大的特定场景中，负责汇总的parameter server容易成为通讯瓶颈。 假设有N个GPU，通信一次完整的参数所需时间为K，那么使用PS架构，其通信成本为 T=2(N−1)*K。 因此Ring AllReduce被提出来，分为Scatter Reduce和All Gather两个环节。 Scatter Reduce过程：首先，我们将参数分为N份，相邻的GPU传递不同的参数，在传递N-1次之后，可以得到每一份参数的累积（在不同的GPU上） All Gather：得到每一份参数的累积之后，再做一次传递，同步到所有的GPU上。 其通信成本仅为 T=2(N−1)/N*K 。 参考 https://fyubang.com/2019/07/08/distributed-training/ PyTorch实现 DataParallel：基于Parameter server算法，通讯消耗较大，对于master节点会有额外显存消耗，但是改动小实现简单。 DistributedDataParallel：官方推荐，基于Ring AllReduce算法，不过需要改造启动方式和dataloader。 参考 https://fyubang.com/2019/07/23/distributed-training3/ 模型过大显存不足 梯度累积：适用于模型可以放进显存，但是想增大batch 梯度检查点：适用于模型无法放进显存。前馈时只存储部分结果，反向传播时重新计算 模型并行：使用于模型无法放进单个GPU，但可分段放入多个GPU中 参考 https://zhuanlan.zhihu.com/p/48035735 https://dailydreamer.me/posts/2018-11-25-python-concurrency/ Sun, 25 Nov 2018 17:43:19 -0800 https://dailydreamer.me/posts/2018-11-25-python-concurrency/ 同步的I/O操作会白白消耗很多时钟周期，因此许多编程语言都提供了并发模型来实现异步I/O。今天简单介绍一下Python中的并发模型。 开始之前先澄清一下并发和并行的关系。并发（Concurrency）是指一次处理很多事情，而并行（Parallelism）是指同时做很多事情。并发是处理问题的一种方式，而并行则必须由硬件支持。 Multi-thread 多线程是最传统的并发模型之一，线程之间通过共享内存来通信，通过互斥锁来防止对临界区域同时读写。 曾经以为由于CPython在实现上采用了GIL（Global Interpreter Lock）来保证线程安全，导致其多线程模型基本不可用。后来了解到Python标准库里所有阻塞I/O函数都会释放GIL，自己编写的函数也可以通过C扩展来释放GIL。所以Python多线程模型在I/O密集型程序中是完全可用的。对于计算密集型程序，可以使用有类似接口的多进程模型处理。 但是多线程模型有一些缺点： 一个线程可能在任何时候被打断，需要上锁，导致很难理解 线程的存储和切换负担相对协程还是较重 为了解决这些问题，Python 3.4引入了asyncio的协程模型。 asyncio Python的asyncio使用轻量级的协程作为调度单位，因此可以达到更高并发。同时协程运行过程中天然被保护，必须显示交出控制权（yeild）给其它协程运行，否则不会被打断。 Python的asyncio非常类似于Node.js的Event loop + Async/Await。 Node.js曾尝试使用回调函数并发模型，但是最后因为回调地狱走向了Async/Await。相比于回调，Async/Await还解决了回调context丢失，不好错误处理的问题。 但是asyncio给Python带来了新的问题：生态的分裂。协程链最后会被asyncio的API驱动，比如loop.run_until_compelte()；而协程链最开始总是被异步I/O API发起，比如asyncio.sleep()或aiohttp.request()。因此要使用asyncio框架，则需要生态中的所有部分如Web框架、数据库驱动、消息队列、各种客户端等全部用协程重写。目前来看Python的asyncio生态还是不够成熟。 Go Model 当然，其它语言也有着很多不同类型的并发模型。写到这里不得不提一下Golang，作为近些年来热度不断上升的语言，它的并发模型有其独到之处。 Golang实现了CSP（communicating sequential processes) Model。它使用轻量级协程和runtime中的调度器来实现并发，即使其I/O函数是同步的。当一个goroutine阻塞时，runtime调度器会自动切换到其它goroutine，这有点类似于轻量级的多线程模型。不同于多线程模型的是goroutines之间通过channel传递信息通信，而非共享内存，这样来保证同一时间只有一个goroutine访问一个临界区域。正如Rob所说，“Do not communicate by sharing memory; instead, share memory by communicating.” 虽然Golang也存在其它问题，尤其是跟Erlang实现的Actor Model对比时，但是它的成功是显而易见的。 结语 本文回顾了Python中不同的并发模型，简略提到了Golang中的并发模型。从来没有一个最好的语言和并发模型，只有最适合的。虽然Golang的高性能和高并发很吸引人，Python的优雅、灵活、快速开发则是其长盛不衰的原因。 https://dailydreamer.me/posts/2016-06-09-inspired-by-functional-programing-language/ Thu, 09 Jun 2016 20:00:00 +0800 https://dailydreamer.me/posts/2016-06-09-inspired-by-functional-programing-language/ 最近看了一本书Seven Languages in Seven Weeks。 原来一直都在面向对象编程，对函数式语言了解并不多，看完这本书之后还是很受启发，接触了许多不同语言的新的思想。 各种编程范式 imperative programming 古老的编程范式，以冯诺以曼结构的机器思考的方式编程，如C语言。 object oriented programming 现在正当年的主力编程范式，如Java、C#、ruby、python，以及深度融合了函数式思想但本质还是OOP的scala。 它的分支Prototype-based programming，如JavaScript，是一种十分灵活的编程方式。 没有Class定义，所有的Object都以另一个Object为prototype，可以很灵活的改变原型链上的Object的数据和方法。 logic programming 面向推理逻辑的特定编程范式，是一种高等级的抽象，如prolog，声明定义和推导即可得出特定问题的答案。 functional programming 被认为是下一代的编程范式。 函数式编程范式基于lambda calculus的思想，很早就在大名鼎鼎Lisp中出现。 其核心思想是认为一切程序都可以由纯函数组成，纯函数没有副作用，输入一样则输出必然一样； 所有数据结构都是immutable的，其值不能被改变。 早年由于我们的计算机架构是冯诺以曼结构，其基本操作都是基于副作用的，因此这种函数式编程带来的性能上的极大损失使其没有像命令式编程一样成为主流语言。 现在随着计算机性能的提升以及相关理论和实现的完善，函数式编程的思想带来的好处逐渐体现，并且也积极的影响着其它现在的主流语言。 同时涌现了一批为了兼容现有平台而作出一定妥协的”过渡性语言”，如Scala（Better Java）、Clojure（JVM上的Lisp）、F#（.Net上的OCaml）。 函数式语言的积极影响 基于immutable思想的数据结构 immutable带来的好处是程序的结果更加的可以预测，变量不会在你看不见的地方被偷偷改变。 而且在多核的并行架构下Immutable能够避免复杂的状态和逻辑维护，使程序更加高效简单。 过去Lisp中主要的immutable数据结构是List,在某些情况下这种数据结构的性能非常糟糕（如查找是O(n)）。 而现在一些精巧复杂的树状的数据结构可以兼顾immutable和性能（以一定的存储空间为代价），如Ideal Hash Trees中的Hash array mapped trie(HAMT)。 这篇文章详细讲解了Clojure中的Persistent Vectors（虽然叫Vector但只是接口一样，实际这货是个树）的实现原理。 它基于HAMT，能够在保持immutable维护过去状态以供回滚的同时达到增加、更新、查找都为O(1)的性能。 知乎上的这个讨论介绍了一些其它的相关数据结构。 基于immutable的系统 Nix OS是一种使用Nix packager manager的纯函数式思想的系统。 Nix packager manager也可以在Linux和Mac OS X上使用。 它将每一个软件包都独立开来，升级软件的时候不会影响原来已经安装好的其它版本的该软件，使得软件可以轻松回滚，并且不会出现由于版本导致的各种问题，是ruby的RVM，node.js的NVM，python的virtualenv等等软件所解决问题的终极解决方案。 类型 Haskell拥有强大的类型系统。 static type是指其编译时进行类型检查，strong type是指其类型检查要求类型严格匹配。 配合type inference，Haskell的类型系统做到了你不需要时感受不到，需要清晰接口时可以显示声明。 它永远在保障着程序的正确性，不会产生JavaScript中一些被人广泛诟病的错误（这个视频我笑了好久。。。）。 Scala中也有type inference，但是由于JVM的限制功能很有限。 Haskell中的type class可以优雅的实现generics和polymorphism，并且可以避免很多OOP中因为不能把函数作为一等公民传递（高阶函数）而造成的臃肿的设计模式。 Julia中multiple dispatch更进一步，根据每个参数的类型不同调用不同的函数实现，更符合直觉，且避免了OOP中dynamic dispatch的动态查找带来的性能损失。