生命不息，折腾不止 https://peterjc123.github.io/ TL;DR 对于某个 job 使用”重启带SSH的任务”。 提取 CircleCI 中给出的 SSH 命令 ssh -p 54782 35.237.241.189 -- cmd.exe 确定本地以及远程用于端口转发的端口，并添加用于端口转发的参数（注意避免常用端口） ssh -p 54782 35.237.241.189 -L [远程端口]:localhost:[本地端口] -- cmd.exe 敲入上述命令，建立远程连接 在上述窗口中，继续敲入如下命令 # 2020/10/3 更新 # 重新设置RDP服务的监听端口 reg add "HKLM\System\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp" /v PortNumber /t REG_DWORD /d [远程端口2] /f # 重启远程桌面服务 powershell -Command Restart-Service TermService -Force #... Fri, 24 Apr 2020 00:00:00 +0800 https://peterjc123.github.io/2020-04-24-circleci-remote-desktop-support/ https://peterjc123.github.io/2020-04-24-circleci-remote-desktop-support/ 问题背景与相关知识 在深度学习流行的当下，深度学习的框架大多是基于Python的实现，抑或是提供了Python的接口。而为了保证性能，底层计算通常是使用C/C++实现的。对于C/C++项目，其链接方式主要可以分为以下两种： 静态链接方式 （Static linking） 静态链接即在链接时即确定程序会包含哪些模块。由于在链接时已经确定了所有包含的模块，那么会直接将这些模块打包，生成一个新的可执行文件或者静态链接库文件。 因而这种方法具有如下特点： 分发简单。因为其不存在运行时才能解决的依赖。 由于无法事先知道用户会使用其中的哪些模块以及哪些函数，因而产生的静态链接库会比较大。 动态链接方式 （Dynamic linking） 动态链接方式即在链接时仅确定包含模块的名称、以及其中所用到的函数，生成一个可执行程序或是动态链接库（DLL）。而在运行时，根据这些信息来寻找相应的模块进行加载。 这种方法的特点有： 由于在运行时才加载对应的模块，因而可以将模块进行替换。 由于所依赖的模块没有被包含进来，因此生成的动态链接库不会太大。 由于动态的加载，因而会受用户环境的影响，因而在分发时有可能产生问题。 在目前 Windows 的大多数深度框架下，大多采用动态链接方式。其原因在于 深度学习框架中需要包含许多 OP 的实现，这些实现需要覆盖多种指令集、多个 CUDA 架构，因而生成的目标文件会比较大。而64位 Windows 下对于单个模块要求大小不能超过4GB。 某些模块不提供静态链接库，比如 cuDNN 等。 在动态链接方式的第三个特点中，我们说到了分发时可能会产生问题。这类问题通常被称为”DLL Hell”。可以考虑下面一个场景： 程序 P1 依赖于 库 L 的一个版本 L1。用户为了能使用 P1，将 L1 放在系统目录中。而某一天，用户又需要使用程序 P2，而 P2 则依赖于 库 L 的另一个版本 L2。假设 L1... Tue, 21 Apr 2020 00:00:00 +0800 https://peterjc123.github.io/2020-04-21-python-dll-load-failure-windows/ https://peterjc123.github.io/2020-04-21-python-dll-load-failure-windows/ Hello，朋友们。大家好久不见，之前的一年较为忙碌，忙着应付实习、面试、毕业开题、论文撰写等一系列麻烦事。实在是没有时间空闲下来写作。虽然其中可能有那么一些时间有写作的灵感，但是随即就被手上的消息或者电话浇灭了。 随着这些麻烦事情被一一解决，我的时间又稍稍多了一些出来。因而会投入一些时间进行相关经验的分享。分享的内容主要还是服务器后端的技术为主，当然也会介绍一些PyTorch Windows相关的工作。其他如果有啥exciting的玩意也可以体验一下。 下面是一些大家可能会问的问题： Q：为啥不在知乎写作了呢？ A：因为知乎的编辑器的用户体验不太好，而且拷贝出来格式就得重新设置。在这里可以写Markdown，可以离线写好再上传，很舒服。 Q：之前的文章还在嘛？ A：还在，不会删除，而且已经迁移过来了。 Q：怎么老的文章下面加了打赏链接？ A：“人要恰饭的嘛。可不可能不恰饭嘛？” Q：Github Pages 有点慢啊 A: 之后会考虑弄一台亚太的服务器上反向代理。其实我觉得如果有访问或者参与Github项目的习惯的话，这个并不是什么问题。 Q: 如何订阅？ A：有两种方式，一种是传统的RSS订阅。可以通过在RSS阅读器中添加 https://peterjc123.github.io/feed.xml 来完成订阅。另一种，可以直接watch网站对应的repo。 Sat, 18 Apr 2020 00:00:00 +0800 https://peterjc123.github.io/2020-04-18-new-start/ https://peterjc123.github.io/2020-04-18-new-start/ 说到Python中最复杂、最核心的内容，非多线程（进程）莫属了。初学者很可能会将多线程和多进程混起来，而其实Python中两者适合处理的任务不同。另外由于多进程的实现具有很强的系统相关性，很多使用了多进程的代码可能换个系统就不能正常跑了。今天我们就要搞清楚究竟两者有什么区别，到底是什么原因造成了多进程代码的在不同系统上的差异性，以及在各种情况下应该采取的解决方案。上篇主要会解释理论部分，也就是前面的两点，最后的解决方案会在下篇中介绍。 简介：多线程与多进程 看到多线程和多进程，不熟悉的人可能会认为两者是同一个东西，其实两者大有不同。其实看他们原本的英语表达就知道了，多线程是multi threading，而多进程是 multi processing。线程与进程的区别我们在操作系统中已经学习过了，简而言之，进程可以包含多个线程，而线程是进程的一个实体。开线程的代价比开进程的代价小，而且便于通信，但是多进程更稳定一些，毕竟一个线程crash了，整个进程都会挂，而多进程之间通常是独立的。有人看到这可能有疑问，如果我处理好线程安全性的问题，那直接用多线程不就好了。 事情远没有这么简单，由于Python的内存操作并不是线程安全的[1]，Python（此处指大家广泛使用的Python发行版CPython）的设计者对于多线程的操作加了一把锁。这把锁被称为GIL（Global Interpreter Lock）。当然对于不涉及到线程安全的一些操作来说不受影响，主要是那些IO密集型的操作，以及Numpy中的一些运算。也就是说，如果你需要在Python中用并行来加速计算密集型任务的执行的话，那么至少在GIL没有被取消掉的当下，用多线程是走不通的。另外根据官方文档的介绍[1]，会发生一件很有趣的事情，由于系统调度的原因，在多核处理器下执行多线程的计算，会比不使用多线程还要慢。 由于GIL的存在，如果我们需要使用多核来对计算密集型任务进行加速的话，那么我们不能使用多线程，而不得不去使用多进程。但是Python的设计在这里很有迷惑性，他把线程和进程的接口设计的几乎一模一样，除了进程还可以强制终结和一些特有的属性之外，没有任何差别。这给人造成一种错觉，好像是多进程和多线程之间可以无缝替换，当然这可能是设计者的愿景，而其实两者之间的区别是巨大的。前面已经介绍过了，举个具体的例子，比如说数据的流动，在线程中只要指定好就可以了，但是进程间的数据流动一般来说没有那边简单，一般都需要采用一些外部的方式来解决，如Socket，Pipe，共享内存等。另外，由于Unix/Windows可使用的多进程实现方式不同，也导致了多进程的代码具有很强的系统依赖性。 多进程在不同系统下的实现方式 首先先来介绍下Python多进程的实现方式[2]。Unix系统下默认的实现方式是fork，而fork可以将进程复制一份，子进程可以执行与主程序不同的函数，此外，这种方式生成的进程继承了父进程的数据，所以数据可以方便的从父进程流动到子进程。而在Windows上不支持fork，而是要使用spawn。spawn其实也是将进程复制一份，但是进程会重新执行一遍主函数里面的代码，就像父进程一样，然后再去执行相应的函数。所以这就会导致一个问题就是如果我们不加任何判断的话，这个进程会不断的复制自身，形成新的进程。Python的设计者当然考虑到了这一点，所以如果你在spawn进程的初始阶段还尝试创建新进程的话，会报错退出。怎么区别主进程和父进程呢？一般会采用__name__属性来区分。 我们用一段代码来验证一下之前讲的这些结论： import multiprocessing as mp import os # Run phase def v(): print('Run', os.getpid()) print(__name__, os.getpid()) # Initialization phase print('Initialize', os.getpid()) print(__name__, os.getpid()) if __name__ == '__main__': # start a new Process to execute function `v` and wait... Thu, 12 Jul 2018 00:00:00 +0800 https://peterjc123.github.io/2018-07-12-python-multiprocess-I/ https://peterjc123.github.io/2018-07-12-python-multiprocess-I/ 让大家久等了，这次 Windows 的 PyTorch 终于正式发布了。欢迎大家去官网下载安装并体验使用，在此我补充一些官方没有的关于 Windows 的发布说明和常见问题。 0.4.0 发布说明 错误修复： 修复多进程下的内存泄漏问题 PR #5585 使用多线程版本 MKL 替代顺序版 MKL ，在 CPU 上带来10%的速度提升 PR #6416 重新添加 Compute Capability 5.0 显卡的支持 新功能： 在编译中加入 MAGMA 添加 CUDA 9.1 build 提供 Wheels 包 支持新的cpp拓展 PR #5548 已知问题： 使用CPU来跑模型比Linux/Mac要慢很多，具体视模型复杂度和CPU核心数而定。原因是MSVC对新版本OpenMP的支持很差，因此我们会在下一个版本对一些组件进行替换，从而解决这个问题。使用GPU速度不受影响，与 Linux/Mac 没有区别。 包括分布式, NCCL等在内的一些组件在Windows下不受支持，详细可见：Issue #4092 常见问题 安装 Conda... Wed, 25 Apr 2018 00:00:00 +0800 https://peterjc123.github.io/2018-04-25-pytorch-windows-v0.4/ https://peterjc123.github.io/2018-04-25-pytorch-windows-v0.4/ 更新：Conda的编译问题已经解决，请访问此处安装新版本。 另外，再把相应的发布日志一同搬过来吧。 Windows版本的改动: 错误修复 backward中的错误会导致死锁 DataLoader多线程时的内存泄漏 torch.cuda中的缩进bug 新功能 添加对 CUDA 和 cuDNN 新版本的支持 添加对 Ninja 和 clcache 编译器的支持 已知问题 有些测试不能通过 不能支持 torch.distributed（分布式）、NCCL（多卡）和 Magma 不支持 3.5 及以下的版本 num_worker设置为0以上的值会导致内存泄漏。另外代码入口得用以下的if语句包裹。这里稍微解释下为什么要这样，因为Windows不支持fork，多进程只能采用spawn，而如果你不用这个条件包裹，那么代码就会被再次执行一遍，这样如果不加限制，那么就会有无限多的进程了。 if __name__ == '__main__': 另外这两天还有个好消息是，Windows的CI已经正式在搭建中了，估计下周就能完工。以后大家可以更加方便的使用master分支进行编译了。我写的一些脚本可以帮助你们方便的进行编译。 Wed, 06 Dec 2017 00:00:00 +0800 https://peterjc123.github.io/2017-12-06-pytorch-windows-v0.3/ https://peterjc123.github.io/2017-12-06-pytorch-windows-v0.3/ 前两天给大家分享了PyTorch master分支在Windows下的编译过程，当然这个编译过程比较繁琐，如果能有直接能安装使用的包就能方便不少。现在比较流行的方式是使用CI（循环构建）来完成这个任务。 可能大家对CI不太了解，我稍微介绍一下。在Github浏览项目时，大家很可能会碰到一些徽章，比如像下面这张。它说明上一次在主分支下的构建过程成功了。这类徽章清楚的显示了CI在后台执行的结果。其实对于那些需要快速迭代的大型项目，用CI可以在对每次代码的改动之后检验代码的有效性，大大改善项目开发的速度。CI为我们进行编译、测试、打包或者分发都提供了相当的便利。提供Linux环境的CI中最著名的就是Travis CI了，而在Windows下的CI我觉得首推AppVeyor。AppVeyor的功能基本是比较全的，你可以自由的对环境进行一些配置，当然他也内置了不少工具，可用于使用各种编程语言，软件框架的编译。此外，AppVeyor的机器还包括Nvidia的显卡（貌似独此一家），也就是说可以用于PyTorch CUDA版本的编译，甚至也可以跑一些小模型。（算力并不强）当然，免费的午餐也是有条件的，每次build不能超过1个小时，CPU核心只有2个，不能并行跑多个项目等等。所以有钱的朋友们可以自己买VPS来跑CI。 CI 徽章 用CI来完成编译、测试、打包和发布这个过程是非常容易的，为什么这么说呢？可以看到下面那张AppVeyor的设置图，直接就对应了每个过程有相应的配置，再每个配置项中你可以自行设定相应的脚本。什么意思呢？就是当你提交代码之后，他会遵循编译、测试、打包和发布这个流程，轮流的执行你设定的代码。有个很酷的功能是它可以打印build时的该主机的地址和端口，然后你可以用远程桌面直接去访问该主机。我没有尝试过，各位有兴趣的话可以自己试试看。 CI 的设置项 关于具体的搭建过程就不再赘述了，下面说正题，首先是使用CPU和GPU版本的运行要求。 CPU版本： Windows 64位系统 64位 Python 3.5 或者 3.6 MKL、Numpy、PyYAML VC++ 2017 Redist GPU版本还需要： CUDA 8 cuDNN 6 NVTX（在 CUDA 中为VS的插件，若安装失败，可以解压CUDA安装包，在CUDAVisualStudioIntegration中找到，可以通过检验环境变量NVTOOLSEXT_PATH是否存在来判断其是否已经安装） 如果同时安装了CUDA 8和9的可以通过在使用前临时修改环境变量的方式使用。 set PATH=%CUDA_PATH_V8_0%\bin;%PATH% 如果是包含多个版本cuDNN的，就需要把cuDNN 6的动态链接库拷贝至torch包的lib目录下。 当然你也可以把CUDA 8和cuDNN 6的动态链接库全部拷进torch包的lib目录下使用，主要依赖项包括CUDA8.0\bin目录下的各种dll和nvToolsExt64_1.dll。 如果你觉得这些方法都不能接受，那还请遵循上次的教程自己进行编译。 关于搭建好的PyTorch的Windows CI。首先是CPU版本的，主页面在此。在主页面会有分别对应Python 3.5和3.6的build，选定相应的版本，然后会跳转至相应build的主页面，那怎么下载build好的whl包呢？在页面中部，会有一个菜单，如下图所示： 点击Artifacts，就可以发现下面出现了生成好的whl包，点击即可下载。 而GPU版本的就复杂的多，因为AppVeyor的1小时build时间限制，我们不得不将使用不同架构的显卡的build拆开来，所以大家先去了解下自己的显卡架构。我们主要对三种架构的显卡做了编译，Pascal、Kepler和Maxwell。GPU版本的CI主页面在这里。进去可以发现，总共包含了12种build。主要是以下三个环境变量的区别：APPVEYOR_BUILD_WORKER_IMAGE、PYTHON_VERSION和TORCH_CUDA_ARCH_LIST。 APPVEYOR_BUILD_WORKER_IMAGE 主要分为 VS 2017... Mon, 13 Nov 2017 00:00:00 +0800 https://peterjc123.github.io/2017-11-13-pytorch-windows-custom-ci/ https://peterjc123.github.io/2017-11-13-pytorch-windows-custom-ci/ 经过几个月的努力，随着11月8号PR 2941并入PyTorch之后，我们终于将关于Windows支持的相关PR全部并入了PyTorch的master分支，现在你可以直接对master分支进行编译了。编译需要的组件有： CPU版本： Visual Studio 2017 C++ Build Tools CMake 3.0 及以上 64位Windows系统 64位Anaconda/Miniconda 或者 Python 3.5及以上 GPU版本： CUDA 8.0 及以上 NVTX (在 CUDA 中为VS的插件，若安装失败，可以解压CUDA安装包，在CUDAVisualStudioIntegration中找到） 对于CUDA 8 的编译还需要Visual Studio 2015 with Update 2 及以上 可选项： cuDNN 6.0 及以上 BLAS 运算库 （主要是OpenBLAS和MKL） 更新：已添加一个repo用于一键进行编译安装，欢迎体验使用。 编译步骤如下： clone 官方 repo，并执行一些预备处理 git clone --recursive https://github.com/pytorch/pytorch... Sun, 12 Nov 2017 00:00:00 +0800 https://peterjc123.github.io/2017-11-12-pytorch-windows-into-master/ https://peterjc123.github.io/2017-11-12-pytorch-windows-into-master/ 伴随着人工智能和深度学习的火热发展，Python也成为了一门非常热门的语言。我们可以看到热门的深度学习框架都提供Python的接口，有些甚至只有Python的接口，这一定程度上推动了Python的普及。当然，在我们完成模型的训练之后，我们总是要搭建一个演示的平台，要么开放给用户使用，要么是内部进行测试。 虽然说Python是著名的胶水语言，可以和很多语言和框架进行互操作，但是要是能直接使用Python编写的框架进行服务器的部署的话，则可以简化程序的编写过程。Python下最著名的网站框架就是Django了，因此今天就介绍下新版本Django的部署方法，主要以Windows和Linux为例。那为何要写这篇呢？因为Django这几年也变化了很多，然而网上有很多陈旧的部署教程，会对我们的部署过程进行干扰，所以我觉得有这个必要好给你们传授下一些部署的经验。当然，部署前请用python manage.py runserver检查一下服务器是否正常工作。 我们先看看Windows下怎么进行Django的部署，我借助的是Azure中的Django模板中所使用wfastcgi库以及微软自己的服务器平台IIS。过程如下： 安装IIS（实测需要6或者7.5及以上，安装包在此），请务必勾选服务器技术中的CGI。 安装wfastcgi pip install wfastcgi 执行指令，获得FastCGI的Handler参数。 wfastcgi-enable 会获得一串类似c:\anaconda2\python.exe|c:\anaconda2\lib\site-packages\wfastcgi.pyc的字符串，其实就是python的路径和handler的路径用|进行连接而成的字符串，记录下来，后面会用到。 在网站根目录下新建一个web.config,填入以下内容 <configuration> <system.webServer> <handlers> <add name="Python FastCGI" path="*" verb="*" modules="FastCgiModule" scriptProcessor="C:\Python36\python.exe|C:\Python36\Lib\site-packages\wfastcgi.py" resourceType="Unspecified" requireAccess="Script" /> </handlers> </system.webServer> <appSettings> <!-- Required settings --> <add key="WSGI_HANDLER" value="django.core.wsgi.get_wsgi_application()" /> <add key="PYTHONPATH" value="C:\MyApp" /> <!-- Optional settings --> <add key="WSGI_LOG" value="C:\Logs\my_app.log" />... Tue, 04 Jul 2017 00:00:00 +0800 https://peterjc123.github.io/2017-07-04-django-deploy/ https://peterjc123.github.io/2017-07-04-django-deploy/ 昨天发了一篇PyTorch在64位Windows下的编译过程的文章，有朋友觉得能不能发个包，这样就不用折腾了。于是，这个包就诞生了。感谢 知乎用户@Jeremy Zhou为conda包的安装做了测试。 更新：从0.4.0版本开始，请通过官方通道进行PyTorch的安装，原通道将停止更新。 先别急着激动。如果要直接使用的话，你需要满足以下条件： Anaconda3 x64 (with Python 3.5/3.6) Windows 64位系统（Windows 7 或 Windows Server 2008 及以上） GPU版本还需要任意版本的 CUDA （包内置了CUDA 8 / 9 的部分主要二进制文件） 这几个条件个人感觉还算比较OK，如果不想放弃Anaconda2也可以创建虚拟环境来使用。 要安装的话，如果你不嫌弃anaconda cloud的网速的话，只需根据自己的系统键入下面的一条命令即可：（注：仅 0.3.1，以后不再更新） # for CPU only packages conda install -c peterjc123 pytorch-cpu # for CUDA 8, Windows 10 or Windows Server 2016 conda... Fri, 12 May 2017 00:00:00 +0800 https://peterjc123.github.io/2017-05-12-pytorch-package/ https://peterjc123.github.io/2017-05-12-pytorch-package/ 各位，爱折腾的我又来啦！这次我准备搞点不一样的，在Windows搞定PyTorch的编译。 文章中的方法已失效，仅用作记录用途。 首先，我先简要介绍一下PyTorch吧。PyTorch是Facebook开发维护的一个符号运算库，可用于搭建动态的神经网络。它的代码简洁，优美，也具有很强的性能。举个例子，如果我们要在Theano或者TensorFlow下进行向量的运算，我们会先定义一个tensor，再对tensor做计算，然后定义一个function，最后调用函数并传入参数，获得输出。样例代码： import theano import theano.tensor as T x = T.dmatrix('x') s = 1 / (1 + T.exp(-x)) logistic = function([x], s) logistic([[0, 1], [-1, -2]]) 如果我们使用PyTorch呢，我们这样写 import torch x = torch.FloatTensor([[0, 1], [-1, -2]]) s = 1 / (1 + torch.exp(-x)) 只需要定义变量，即可进行运算。是不是更加符合我们的思维呢？ 最后我再引用一句话来宣传一波： Matlab is so 2012. Caffe... Thu, 11 May 2017 00:00:00 +0800 https://peterjc123.github.io/2017-05-11-pytorch-compile/ https://peterjc123.github.io/2017-05-11-pytorch-compile/ 说起来，theano也用了很长时间了，对安装这一套理应感觉非常熟练，不过好像这个新的GpuBackend的安装花费了我大量的时间，因此特意写下这篇教程，为各位铺路。 让我们回到3月初的某一天，升级了theano的0.9某一版本。起初感觉并没什么特别的，不过导入时的一个警告引起了我的注意。 The old CUDA backend will be deprecated soon, in favor of the new libgpuarray backend. 大概意思是：老的Gpu后端要过期啦，请尽快升级！ 这用的好好的，干嘛升级呢，不管他。不过，过了两天，我使用的翻译工具包nematus的官网上出现了下面一段对比： GPU, CuDNN 5.1, theano 0.9.0dev5.dev-d5520e: THEANO_FLAGS=mode=FAST_RUN,floatX=float32,device=gpu ./test_train.sh 173.15 sentences/s GPU, CuDNN 5.1, theano 0.9.0dev5.dev-d5520e, new GPU backend: THEANO_FLAGS=mode=FAST_RUN,floatX=float32,device=cuda ./test_train.sh 209.21 sentences/s 这个速度提升还不小，那赶紧行动吧，点击warning里的网址，你会看到这样一段介绍： Using the GPU in Theano is as simple as... Thu, 20 Apr 2017 00:00:00 +0800 https://peterjc123.github.io/2017-04-20-theano-gpu-backend/ https://peterjc123.github.io/2017-04-20-theano-gpu-backend/