developing

Base64 是一种常用的二进制到文本的编码方式, 应用非常广泛. 考虑这么一种场景, 两人之间现只能发送文字信息, 但他们要发送一张 jpeg 格式的图片. 如果尝试用文本编辑软件打开 jpeg, 将会发现是一大堆乱码. 原因是 jpeg 是二进制文件, 每个字节表示的东西几乎都不是给人看的字符, 自然没法解析出来. 而如果想把这些东西强行复制出来, 那更是一种灾难. 里面会有各种各样神奇的比如换行符, 甚至是\0 (文件结束符) 这种迷惑的东西. 自然是没法很好地以文本的方式传输的. 于是就有了这么一种把任意二进制文件都转化成没有奇怪特殊字符的方法. 首先把二进制文件或者任意字符串写成一串 01. 然后把相邻的 6 位合起来, 用 A-Za-z0-9+/ 一共 (64=2^6) 个字符来表示. 最后可能省下 2 个或者 4 个空位, 则用 0 补齐, 然后放一堆等号上去. 这样就可以把任意的文件, 比如文字, 图片, 视频都转换成肉眼可见, 易于复制和通过 http 之类的协议以及 json 之类的格式来传输的数据了. 下面是一些例子 hello world => aGVsbG8gd29ybGQ= 我不知道 base64 是什么 => 5oiR5LiN55+l6YGTIGJhc2U2NCDmmK/ku4DkuYg= 宝宝在这里给宝宝藏了一张小纸条: 6KaB5LiN6KaB5Y6755yL55yL5a6d5a6d55qE572R5piT5LqR6Z+z5LmQ5q2M5Y2V6YeM5aSa5LqG5LuA5LmI6L+35oOR55qE5Lic6KW/Pw== я говорю по русский плохо => 0Y8g0LPQvtCy0L7RgNGOINC/0L4g0YDRg9GB0YHQutC40Lkg0L/Qu9C+0YXQvg==...

就在刚刚运行着本网站的阿里云 ecs 经历了一次升级, 从 ubuntu 16.04 lts 升级到了 18.04 lts. 升级过程平稳, 但升级后发现这个 php 做的网站变成了源码. 目测是 php 跪了, 于是尝试修 php. php5 仿佛已经不被支持, 于是换用 php7. 直接暴力 apt remove 再 install 就可以了, 配置会被保留. 然后发现 mysqli not found. 解决方法是在 /etc/php/7.2/apache2/php.ini 里面将 extension=mysqli 一行给 uncomment 掉. 然后就完事了.

最近因为各种神奇的移动, 在不同的3台电脑上装了 debian, 并踩了不同的坑. 开一个文章来记录一下各种神奇的坑. 0 一台 2013 年的联想 ideapad 笔记本, 配备了 AMD HD 6400M 独显. 因为突然想起了 bios 的管理密码所以激活了独显. 于是想用独显来跑 opencl 之类的. 然而老的 amd crystal 驱动好像不是很支持? 时间有点久, 忘记了踩了什么坑. 总之 apt 瞎搞最后就装上了. 1 实验室师兄的 i7 + GTX 1070 + 4k 屏. 装 nvidia 驱动并 disable nouveau 是常规操作. 然后遇到的问题是 4k 屏对 gtk 的程序好像不是很友好. chrome 的地址栏和 ibus 之类的东西会变得非常小, 瞎眼. 解决方案是用 GTK_SCALE=2 这个环境变量. 但问题是这个环境变量不应该在开窗口的时候再设, 而是要放到 profile.d 里面. 然后就解决了问题. 然后 ibus 冥顽不化地占据了我的输入法. 然后发现 apt remove 之后就能愉快地使用 fcitx 了....

因为发现助教给炼丹任务提供了 64 张图片作为训练集, 64 张图片作为验证集, 所以果断放弃了炼丹任务. (update: 发现还是炼丹任务好做) 打算用 buildroot 从底向上 build 一个能跑起 python-gpio 的 linux. 另开一文记录一下坑们. (补充) 计划 先不管镜像大小, 用 buildroot 搞出一个能跑的系统. (好像 buildroot 部分差不多了.) 实时性补丁 进一步裁剪内核. (即使不栽应该也比 raspbian 小很多了. 毕竟老师那边 raspbian 裁剪纪录是 200M, 而 buildroot 现在才不到 150.) build 使用了默认配置 $ make raspberrypi3_defconfig 节省了很多自己摸索的时间. 配置静态 ip 的时候发现可能是由于 networking 的版本问题, 必需要在 interfaces 配置文件里把 netmask 写在 address 上面, 否则不 work. 另外选装上了 openssh 以支持 ssh 登录. 在折腾了半天之后终于能 ssh 上树莓派上的系统了. 然后发现它有一个轻量级的 dropbear 作为 sshd....

好的 scc@sc'19 终于没有拿亚军 记个流水账 Benchmarking 好像没啥特别的. 一个新的发现是 HPL 的功耗飘可能是因为 GPU 功耗上升而不是计算 pattern? 回头仔细看看..? 内核的奇怪的锅 导致 idle 状态下 ssh 上一台机器就能跳 200w 的功耗 spike. 通过更新内核版本解决了该问题. IB 卡烧掉了??? benchmark 本来早晨很早就交了而且数也还行. 然而中午玩着玩着发现 ib 卡没了. 尝试 pci hot reenable 失败之后重启并重新跑了 benchmark. 后来发现是 ib 卡在 gpu 风道里, 而我们给没插卡的节点的 gpu 风扇拔了一半的线, 另一半还是最低速运转的, 于是把 ib 给热傻了… SST 人脑挖矿 + 无脑跑 SST 第一个部分是给定 cpu 核心数, l1/l2 cache 的不同搭配之类的总共乘起来 5760 种选择, 让用 SST 搞出一种性能最好且不超过5000块钱的配置. 人脑挖矿 vs 暴力. 测算发现暴力应该能跑完所有点, 于是就暴力了一下. 听说别的队有试图人脑的…...

获得一个生日礼物 raspberry pi 已将近一年, 然而因为它只有四个核所以被嫌弃地闲置了很久. 近期因为上了嵌入式的课, 所以又开始了一轮折腾. 把一些有趣的事记录一下. 网络连接配置 老师说让我们先插上显示器配wifi, 之前我也是这么干的, 于是照做了. 然后想拿回家用, 家里没显示器, wifi 密码输入错误, 失联 ovo 后来想起直接给有线网口配个静态ip 就完事了. 和电脑直接对插就能访问 ovo. 延迟测试 发了一个示波器很好玩, 然而只有 windows 的 pc 端驱动差评. GPIO 管脚控制居然是 python, 严重怀疑效率. 实验本身倒是很简单. 接下来是给 kernel 打实时性补丁. (中断响应优先级? 时间步大小? 感觉 很有趣) 视频流 网上看到一个例子是把 raspivid 的输出用 nc 接起来到 host 上用 mplayer / vlc 播放. 非常有趣就试了一下. cvlc 转发延迟略高. 直接 mplayer 放 h264 格式的视频非常流畅. Modius NN 计算棒 去 intel 上找到了 openvino 作为 myriad 计算棒的驱动....

GridGraph 师兄的文章. 主要 idea 是把邻接矩阵切成块 (p*p) 放到磁盘上顺序读来提升 io 性能. 单机. GraphChi disk-based, parallel sliding windows, single consumer-level computer. metis 不 work (???) 解决出入边都要考虑和写的问题. 按出边分块 shard. 入边按序存放, 在每个 shard 中为连续一段. 可加载进来. 解决了一些比较麻烦的问题比如数三角形.

ISC'19. 一场大概是退役失败的超算比赛. 我负责的 part 是 AI, 还有万年大锅 HPL, 以及神秘应用. 还有就是订保险订酒店联系赞助商blabla. 本来想帮忙搞 HPCC 的但是没有精力搞不动 ovo AI AI 题是去年的 GB 论文 + 精调模型. 在解决了组委会提供的脚本里的一些性能上的 bug 之后顺利地训了起来. 而且按照原文里在上千个节点上并行训还能收敛来讲, 是可以在现有机器条件下随便数据并行的. (事实证明直接把整个训练集切成 10 个batch 也没有问题) 因为最终要求是精度, 所以请教了一些人, 得到的思路是 数据增强, ensemble. 数据增强不太写得动, 于是改脚本做了 ensemble 的 inference, 效果还不错. 比原文高了几个点. 但也没有特别闪亮的突破性进展. 唯一发现是 bn 用的是 training mode. (原因应该是 tf 的 bn 一直自带 bug, 如果用推理模式精度就是会炸掉) 于是推理的时候也应该 bs 越大越好. 于是就有了 dummy sample inference + unique 的一个脚本. 然后因为没有处理好 “//” 于是组委会还怀疑了半天为什么我的脚本有锅. 哭. 然后就是现场出了一个锅: unseen dataset 发下来一看居然是事前给出的 test set....

前段时间遇到 mac 微信出了一个锅. 部分微信群和联系人在电脑上收不到消息, 可以发消息, 但发出去一直显示转圈圈 (其实对方已经收到了), 切换窗口再切回来就连之前自己发的消息都不见了ovo 然而因为不太影响使用(可以在手机上看消息, 电脑盲回) 所以没太管. 但是作为一个强迫症还是不太能忍, 于是过了好久还是决定动手修一下. mac下微信的本地数据文件在 /Users/laekov/Library/Containers/com.tencent.xinWeChat/Data/Library/Application Support/com.tencent.xinWeChat/2.0b4.0.9. 初步估计是本地文件出锅了, 于是对它动手. 首先在mac端不上线的情况下手机拉了一个不影响别人的群, 然后用mac登录, 果然这个群属于bug群. 把 Message 目录移动为 Message_bak, 重新登录, 失去了所有聊天记录. 再次尝试使用上面那个群, 发现可以正常使用. 定位到问题文件在 Message 目录里. 发现 Message 目录下有 msg_[0-9]十种前缀的文件, 估计是对聊天记录进行了分桶. 大胆猜测是某个桶坏了. 于是等了一分钟后在群里发了一条消息, 发现只有 msg_6 开头文件被更新了. 大胆猜想是 msg_6 这个桶炸了. 另有有一个 MessageTemp 目录较大, 目测是数据文件. (比如消息, 图片, 视频) 猜想这里放的是元数据. 于是把旧的 MessageTemp 先拷回来. 然后恢复了 msg_1 开头的几个文件, 发现果然聊天记录回来了一部分. 挨个恢复除了 msg_6 以外的所有 msg_x 文件, 于是除了之前炸掉的记录以外, 聊天记录都回来了. 坏掉的文件就确实没法修了. 鬼知道.data格式是啥玩意. 完结撒花....

API角度 Python 功能没有 pytorch 完善. 参数收集等都需要手写. CPP API 同 Python. 设计理念 类名为 Expression: 表达式 -> 明确定义 未执行. Graph @xl nodes, parameter_nodes inplace: forward_inplace_state { NOPE } 完全没支持inplace. immediate_compute 立即执行. 提供backward方法, 但传入了loss的index. Tensor 暴力绑定内存. (直接就是一个裸指针) Expression (Variable) value() 方法真正执行expression并获取值. 调用ee(ExecutionEngine). Autobatching 在执行cg的时候做. 具体代码在 exec.cc 里一个叫 incremental_forward_no_update的函数里. 使用 signiture 机制. 不同功能的function对应不同的signiture. 相同signiture的 合并. Optimize 没有做. 只有一个找关键路径的简单算法. Node(Functions) Spec推断 DimForward 专门维护 shape 信息. forward 和 backward 放在一个子类里. 所有控制都由 Graph 接管. 包括所有 Variable 和 Nodes (Function)...