SorryChen

SorryChen

V2EX 第 166280 号会员,加入于 2016-04-04 12:27:08 +08:00
今日活跃度排名 7605
根据 SorryChen 的设置,主题列表被隐藏
二手交易 相关的信息,包括已关闭的交易,不会被隐藏
SorryChen 最近回复了
@jingyijun 灵活性确实没有容器高,不过我还没有遇到 conda install 不好安装的常用工具,或者编译安装。其他的也可以用 module 管理。容器环境打包等对小白还是太复杂了。这东西需要根据使用的人的感觉和经验来衡量。如果你们的用户都熟悉那就不是问题。毕竟集群最终是要给同学们用的。

我的感觉容器的适合成熟产品大规模部署,多机器来源等这些情况。比如我的计算资源一些来自 A 供应商,一些来自 B 供应商。他们甚至网络都不通啥的。这种情况我之前团队的容器方案可以轻易搞定聚合。但是 slurm 就不容易。slurm 胜在简单直观。如果只是小团队,几十台机子,我认为 slurm 心智负担最小。
刚好我在两个不同的机构,分别部署过基于容器的,和基于普通 Slurm 的。一个机构刚好两种都体验了。

首先结论,对于我们组的大部分研究人员来说,全部投票 Slurm 。首先我们这大部分大学都是 Slurm ,很多人熟悉。其次容器对不熟悉 docker 的人来说,简直天书,完全不明白,为什么 container 关了我有些东西就不见了。而 Slurm 虽然上手有那么几条命令,看着挺复杂。但是一共也就那几条命令。另外就是 slurm 集群的所有操作,包括代码编写,调试,申请资源,等等基本都在登陆节点,而基于容器的通常都有个网页 UI 之类的,从那上面申请资源进行训练啥的。体验很割裂。而且基于容器的申请一个资源到正式运行代码,速度挺慢的,而 slurm 一秒就搞定了。综上,我们组当时体验了两个切换投票的时候,slurm 全票通过。

存储:我们用了 juicefs 和 seaweedfs 作为 S3 。运行挺好的。速度也很快。管理员需要研究研究 seaweedfs 的源码。文档较少。

Slurm:
1. 碎片化任务:容易解决。无非就是有的 1-2 GPUs 的调试任务,明明可以填空别的 mix 机器,却单独放到了一个 8x 节点上,导致这个 8x 节点无法进行 8 卡训练。这是因为 slurm 的最小 load 分配策略导致的,优先散布任务而不是紧凑分配任务。所以可以在命令比如 srun 外面包一层。在真正提交任务给 slurm 之前,优先寻找 slurm 里面的 mix 节点,然后分析哪个可以填空当前任务,如果找到了,附加参数 -w nodename 给这个任务即可。
2. 调试 GPU 利用率低:有的人喜欢 srun --pty bash 这样进去用交互的方式调试。极其浪费资源。因此通过 job_submit.lua 限制这类任务只能提交到特定分区,比如 dev 分区。该分区设置最大 job 时间比如 4 小时。同时还可以 sacctmgr 限制该分区每人最多用 2x 卡。另外,鼓励大家使用一次性资源申请调试任务。比如 srun -p xxx --gres=gpu:4 python train.py 这样一样可以调试任务,而且申请到的 GPU 资源会在程序停止运行后立马释放,最大化共享。
3. 碎片资源利用:管理员可以写一个 job 提交脚本,通过分析集群资源 layout ,让用户的多机多卡任务适配。比如用户进行 8 卡训练,但是集群只有两个 4x 空闲机器。理论上此时也可以开始训练。所以我这边写了个脚本,自动完成 layout 分析,提供给用户一些可用的环境变量,比如 NODE_RANK ,LOCAL_RANK ,MASTER_ADDR ,MASTER_PORT ,就可以了。用户只需要设置好这些,无论是单机 8 卡,还是双机 4 卡,都能跑起来。提交任务的时候只需一条命令 slurm-submit --num_gpus=8 python train.py ,脚本自动去寻找机器。
4. 交互式开发:同样可以做到。理论上用户并不可以直接访问 GPU 机器,因此需要在用户申请到 GPU 资源后,在 job 内启动 vscode server/jupyter server 。但是该服务在 GPU 机器上,用户无法访问,因此需要端口映射。用 frp 即可。管理员只需要基于 frp ,包一层,提供给用户一个命令,比如 forward_port 。用户运行这个命令之后,你的脚本里去调用 frpc ,然后把相应端口映射给登陆节点。用户只需访问 loginnode:port 即可访问上述服务。
5. 队列调度:slurm 的队列足够强大了,多个 qos 配置,包括资源抢占,以及 backfill 策略,都相当好用。相反我用过的两个基于容器的,包括开源的和大型公司私有的,完全比不上。
@HappyFruit zotero 当然可以匹配到正确的标题,作者,但是关于发表信息只能告诉你这个论文发在 arxiv 上。然而并不能告诉你这个论文发表在 ICLR NeurIPs ICML ECCV 等会议。

zotero 的 PDF 阅读是用的 PDF.js ,性能一定很差。

Paperlib 也支持 webdav 。

如果你并不需要读大量会议论文,不用 latex 写作( paperlib 有非常方便的 bibtex 导出窗口,兼容任何编辑器),zotero 也不错。

当然 paperlib 还有许多比 zotero 体验好的地方,只能自己体会了。这也是大家使用 paperlib 的原因。
@jaylong 啊那个我很久之前就不用了,我不知道他能导出为啥呢
@jaylong 你说的是 papers3 ?
@yuanmomo = = 问题是你的意见,不也是幸存者偏差的一种么
我还是比较支持体验体验再决定在哪生活的。

想不想留在一个地方只有体验了才有发言权。网络信息尤为片面。

还有国家公派留学建议不需要去了解和考虑了。

我就是英国公派攻博。每年公派项目大头是博士。硕士了了无几,几乎拿不到的。英国申请 CSC 博的流程你需要先考过语言,拿到学校的 unconitional offer, 然后意向导师给你向学校提名,学校组织评选,拿到学校的 CSC 提名之后,你才有资格向国家留学基金委申请。然后国家留学基金委再评选,筛出来最后的资助名额。有的学校会超额发 CSC 提名,因此即便你通过了学校 CSC 提名,也有可能败在最后的评选。另外最近欧陆很多学校,老师,都不再招收 CSC 学生了。

我在这四年了,只能说有好有坏。同学们有的人留下,有的人回去,啥都有,适合自己生活节奏的才好。

另:朋友老师跟我说,亚洲男性,在我这找工作,鄙视链排最低,在印度人之下 = =,女生还有一个企业性别比例的优势 = =
@v2taylor @xhawk

不知道你是不是 Electron 的 APP 。提供点 Electron 项目的实现思路细节。在学习了 VSCode 之后,我在我的项目 https://github.com/Future-Scholars/paperlib 实现了插件系统:

1. 首先所有的插件都运行在单独的 process 里,可以使用 Electron 的 utilityProcess 。这可以保证你插件崩了,软件不会崩。

2. 因为插件和软件主体,在不同的 process 里,你需要设计实现一个好用的 RPC 。比如我从插件所在的 utility process 想要访问软件主体的一些 services ,你几乎不想每次都单独通过 Electron 自己的通信 ipcMain message port 之类的来分别一一实现。理想的思路是通过基于 ipc ,message port 封装,来在 process 间暴露想要的 API 。

我的实现是,ipc 只负责初始的沟通建立部分,类似于握手吧,交换一个 message port pair 。然后后续的所有通信都通过 message port 。这样写起来比较简单头脑清楚一点。message port 之间,传递的包括,calling 的类别,服务名,函数名,参数等。然后对应 process 处理好得到结果之后,再通过 message port 回复回去结果。请求和回复有一个唯一的 id 进行匹配。细节还是得去看代码。这样就可以实现,你任意跨 process 调用函数,甚至跨 process 的事件监听。

process 间 API 的这个暴露过程本质上就是在创建一个图,图的节点是 process ,边就是是否已经暴露了 API 。因此你可以基于此,写一些代码,在新 process 创立时,请求所有已存在的 process ,向自己暴露 API 。比如你创立插件所在的 utility process 后,首先运行的代码是向 renderer 和 main process 请求向自己暴露 API 。一旦暴露了,这个图里就是三个节点了,也多了两条边。之后,你就可以在插件 process ,使用 const results = await MainAPI.XXX.YYY(...) 类似这样的方式,来和软件主体进行交互了。

建立好这一套机制之后,你就可以给让插件调用你所暴露的 API 了。而且即便插件崩了,也不会影响你的软件主体。

3. 关于插件的加载。插件全都加载到 node vm 里。至于下载和安装卸载等,你可以参考 https://www.npmjs.com/package/live-plugin-manager 。自己实现也不是很麻烦。

4. 你需要设计一个规范,来让插件开发者遵守它开发插件,比如插件的 initialize 过程需要做什么,插件在卸载的时候必须要有对应的 dipose 函数来清理一些不必要的东西。
关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   2712 人在线   最高记录 6679   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.5 · 11ms · UTC 07:23 · PVG 15:23 · LAX 23:23 · JFK 02:23
Developed with CodeLauncher
♥ Do have faith in what you're doing.