众所周知, laekov 在办公室有一台 nuc 装了 linux 主要用于工作, 另有一台笔记本用于其它工作. 作为一个锁屏强迫症, 每次 laekov 站起来去干啥的时候都会把两台电脑锁屏, 回来之后再分别解锁. 笔记本可以用指纹或者 iwndows hello, 而 nuc 就只能敲密码了. 不巧的是它还直接暴露在公网上, 于是密码设得比较长. 所以 laekov 希望用 windows 上的指纹来解 kde 的锁屏. 然后发现直接使用命令 loginctl (un)lock-session <id> 就可以实现(解)锁 kde. 配合 ssh 和 autohotkey 就可以实现一键开关锁. 但是这还是需要再额外按一次键. 然后发现 windows 有一个叫 task scheduler 的东西, 可以在锁屏和解锁的时候触发一些命令, 于是愉快地接入了 ssh 之后就可以方便地一次性解锁两台电脑辣!
2023 EVStore: Storage and Caching Capabilities for Scaling Embedding Tables in Deep Recommendation Systems ASPLOS'23 GRACE: A Scalable Graph-Based Approach To Accelerating Recommendation Model Inference ASPLOS'23 AdaEmbed: Adaptive Embedding for Large-Scale Recommendation Models OSDI'23 FlexShard: Flexible Sharding for Industry-Scale Sequence Recommendation Models arxiv 2022 RecD: Deduplication for End-to-End Deep Learning Recommendation Model Training Infrastructure arxiv Ekko: A Large-Scale Deep Learning Recommender System with Low-Latency Model Update OSDI'22 PICASSO: Unleashing the Potential of GPU-centric Training for Wide-and-deep Recommender Systems arxiv HET: Scaling out Huge Embedding Model Training via Cache-enabled Distributed Framework VLDB'22 HET-GMP: a graph-based system approach to scaling large embedding model training SIGMOD'22 Fleche: an efficient GPU embedding cache for personalized recommendations EuroSys'22 RecShard: statistical feature-based memory optimization for industry-scale neural recommendation ASPLOS'22 BagPipe: Accelerating Deep Recommendation Model Training arxiv 2021 Accelerating recommendation system training by leveraging popular choices VLDB'21 SPACE: Locality-Aware Processing in Heterogeneous Memory for Personalized Recommendations ISCA'21 Software-Hardware Co-design for Fast and Scalable Training of Deep Learning Recommendation Models arxiv ISCA'22 RecPipe: Co-designing Models and Hardware to Jointly Optimize Recommendation Quality and Performance MICRO'21 2020 Kraken: Memory-Efficient Continual Learning for Large-Scale Real-Time Recommendations SC'20 Distributed Hierarchical GPU Parameter Server for Massive Scale Deep Learning Ads Systems MLSys'20 DeepRecSys: A System for Optimizing End-To-End At-Scale Neural Recommendation Inference ISCA'20
laekov 搞了一个在 overleaf 里写 pandoc 的东西叫 panleaf, 并用它做一些愉快的 beamer slides. 但是 laekov 在做一个作者有七个人的 slides 的时候发现如果把七个人塞在正文的每页的底下, 就会巨长无比, overflow. latex 提供了 short author 功能, 在 beamer 里面正文的页脚只显示 short, 而 titlepage 显示全文. 但左右看了一圈发现 pandoc 的 author 字段并没有这样的支持. 而且即使不填 author 字段, 生成的 tex 文件里面还是会蹦出一个 \author{}, 且在自定义 latex template 的后面, 所以无法在 template 里面插 author 来解决. laekov 于是找来了 pandoc 的 beamer writer (default.beamer, 也可能是 default.latex), 在里面找 author, 果然找到这么一段. \author{$for(author)$ $author$ $sep$ \and $endfor$} 这么暴力怎么行, 于是加上一个 if 变成酱紫....
laekov 最近在玩 assetto corsa 并试图学习循迹刹车, 因此需要一个加速度轨迹显示插件. 在 GitHub 上发现了一个上古仓库 竟然还能用, 但是卖家秀是 而 laekov 这里是 为啥参考线只剩小半个了？？？ 由于 assetto corsa 的插件都是 python, 于是 laekov 愉快地看起了代码, 并发现了如下一段. def drawCircumference(self, radius, center): ac.glBegin(1) nlines = max(4, int(100.*radius)) for i in range(nlines+1): x, y = self.gPlotter.plotG(center['x'] + (sin(2*pi*i/nlines)*radius), center['z'] + (cos(2*pi*i/nlines)*radius)) ac.glVertex2f(x, y) ac.glEnd() 大胆猜想是 python 或者 ac.gl 性能不足以支撑在一个渲染周期内画完整个圆. 于是想找一个 native 的 circle 的 api. 然而翻阅了一下上古的 python plugin document (竟然还是 google docs) 发现 ac 的 gl 只支持画点和多边形 (挠头)....
版权声明: 如需转载请先与 laekov 联系, 侵权必究. 序 Jiaao He 在 24 岁生日那一天收到邮件, 他在 ppopp 投稿的这篇文章被接收了. 这是他以一作身份投的第一篇 A 类会文章. laekov 当时脑子一热, 开了一个坑, 决定把这篇文章的主要内容用中文写出来, somehow 地促进中文学术. (虽然多半并没有什么帮助) 在过去的小半年里他又经历了 artifact evaluation, camera ready, 制作 presentation slides 和录制视频 (很遗憾因为疫情没法去韩国开会了) 等等一系列事情, 对这个项目也有了更多的理解. 在 4 月的第一天终于把写文章时候的 prototype 变成了看起来还不错的代码, 并准备合并进 FastMoE. 正好写完这篇文章, 也当作是在 FastMoE 里使用 FasterMoE 的中文版文档了. 这篇文章的 pdf 正文在 ACM DL 上可以找到. (有 open access, 在任何地方都可以下载, 并用于非商业目的) 开会的时候用的 slides 和视频链接 在这里. 背景和简介 我假设看这篇文章的人已经知道什么是 MoE 模型了, 大规模的 MoE 模型现在有多重要 (也可能并不)....
花了一晚上修的一个 bug. 记录一下. 先讲结论再讲故事. slurmdbd 在更新 account 配置的时候, 有可能出现更新成功了, dump 出来是对的, 但跑程序失败 (requested resources not available) 的情况. 其中一个可能原因是 mysql 并没有成功写入, 于是认证失败. 解决方案是修改 slurmdbd 的配置文件, 使得其以 root 用户身份执行. 故事是实验室有同学要赶 PLDI, 需要独占某一些节点, 并防止懵懂的小朋友和他们抢占节点后不释放. laekov 给出的解决方案是在 slurm 中单独划分一个队列, 并仅对指定 account 开放. 这个操作 laekov 在另一个集群上已经熟练使用了. 但是 laekov 在用 sacctmgr 配置好 account 和 user 之后, 尝试 srun 任务, 发现提示 resources not available. 之前遇到过这种情况, 通过重启 slurmdbd 解决了问题. 但是这次重启任何 slurm 组件都没有解决问题. laekov 查看了 /var/log/slurm-llnl/slurmctld, 发现提示 part_policy_valid_acct: job's account not known, so it can't use this partition....
laekov 在 3月1号下午 3点1分 开源了 FastMoE 系统的代码。合作者是 KEG 实验室 的 xptree 和 sengxian。 简单讲，MoE 模型就是把神经网络里的一层复制若干份，称它们为专家（experts）。在计算时，引入一个额外的门（gate）网络来对于每个输入决定它被哪个专家所计算。 举个例子，一个 nlp 模型里的动词和名词可能会被不同的 expert 处理。这样可能会得到更精准的模型。模型部分 laekov 不太懂，不做更多讨论。 FastMoE 这个名字是 laekov 起的，包含了 laekov 关注的两层问题： 训练这样的模型怎么训得快（fast training）。 如何使得这个系统像吃快餐一样（fastfood-like）开箱即用。 训练性能 通常，expert 网络是一个 MLP，即多层全连接，即矩阵乘。一个值得注意的问题是，gate 会使得一个 batch 被打散。若简单地用 pytorch 来实现，则会导致 GeMM 运算降级为 GeMV 运算，这对 GPU 这样的现代并行计算设备来说是十分不友好的。测试发现朴素的实现在 V100 上仅能达到 500GFLOPs, 即峰值性能的 3% 左右。 注意到 expert 的数量不会太多，故 batch size / expert，即平均每个 expert 处理的 batch 中的元素依然是一个较大的值。因此考虑对 batch 中的 samples 按照 expert 进行重排，每个 expert 依然以 batch 形式处理输入。这样会更充分地利用硬件资源。...
由于众所不知的原因 laekov 在一处办公环境使用自己的 chromebook 进行办公. 之前的博客提到 laekov 的 chromebook 具有一块 3200x1800 的高分(瞎眼)屏. 而 laekov 在办公室开心地借来了一块和实验室那块看起来一样的 34 寸的带鱼屏, 然而插上之后才发现它的分辨率竟然是 2560x1080, 完全被 13 寸的笔记本屏幕给包含了. 本着屏幕 dpi 不重要, 面积才是王道的思路, laekov 十分容易地 disable 了笔记本的屏幕, 单独使用一整块 34 寸屏幕来进行工作. laekov 在经历了 chromeos 的 ro rootfs 各种无语之后, 终于决心使用 crouton 的 xfce 环境作为自己的主力工作环境, 并配上了 i3lock 锁屏和熟悉的 urxvt. 然后问题来了: laekov 要抱着 chromebook 去开会! 当 laekov 拔掉 type-c dock, 看向 13 寸小屏幕的时候, 多年前在 laekov 的 (已经死掉的) mbp 上装 kde 之后出现的神奇一幕又出现了! 所有东西变得奇小无比, 需要配合放大镜才能分辨出屏幕上的字是 1 还是 l....
这个事情的 motivation 是被 harry 拉去上了一门叫 “高等计算机网络“ 的课, 而 harry 和 gyc 是本科生网络原理课的助教, 于是大作业的内容就是抱着 harry 的大腿给小朋友们做的硬件实验做一个测试平台. (harry: 你的老本行, 造 oj) 因为 laekov 的硬件水平四舍五入等于没有 (gg) 所以负责写前端. VUE + ChartJS = gg laekov 多年没写过前端了, 没想到 angular 都已经 gg 了. 在 “尽量轻量化, 以后烧进 flash” 的指导思想 (还有 harry 的 push) 下选择了 vue. 功能里有一个重要的需求是画一张同学们的路由器带宽-帧大小的曲线. 要是有 matplotlib 就好了, 然而既然是在写 web 就只能搞 js 的轮子了. 然而 chartjs 需要给它一个生的 canvas DOM object. 但是 vue 的制造者似乎就是非常不喜欢开发者拿生的 DOM, 甚至把 document 对象都给屏蔽了. (?...
最近在某个公用集群上手工编译了 htop 给小伙伴们用. 然后发现大家的用户名都是学号, htop 并不能把用户名显示全, 于是追责麻烦. 然而 htop 似乎并不支持改列宽, 于是就自己去看代码改列宽了. 以下基于 htop 的 2.2.0 release 版本. 表项的宽度在 Process.c 里的 474 行. 这玩意是 hard coded 的 sprintf 的位宽. 表头在 linux/LinuxProcess.c 里的 205 行, 修改方法是在 title="USER " 后面再加几个空格. (hard coding 真是让人崩溃啊) 然后可能会编译的时候说 struct Process has no member isKernelThread. 修的方法是在这个 c 文件的 146 行加括号. 注意不能改 .h 文件, 因为 .h 是在 make 的时候从 c 代码里抽取出来生成的 (什么鬼玩意)