Background Honor PC Manager—essentially the Honor-flavored sibling of Huawei PC Manager—is far heavier than it needs to be. For my use case, the features I actually care about are basically: 1. Battery charge limit 2. Touchpad force sensitivity 3. Automatic driver updates The third one is tolerable because
若忽略 Cache 的存在： * 从 Guest 的视角来看，Guest 负责发出 Request（Load/Store 指令），Memory Controller 则在数据 Ready 时通知 Guest。 - Request 通常不会立即得到响应。Memory Controller 会先对请求进行合并，再统一处理。 - Memory Controller 会向物理内存发起 ACTIVATE / READ / WRITE 等操作。每次硬件数据传输都对应某个 Bank 中的 Row。Memory Controller 需要先执行 ACTIVATE，才能进行 READ / WRITE，而 ACTIVATE 通常非常耗时。 * 硬件的单次 READ / WRITE
Transformer（Attention Is All You Need）最初作为翻译模型出现，并极大地影响了后续深度学习（DL）领域的研究热点。 相比传统的 RNN，Transformer 具有以下特点： 1. 消除了时间维度上的顺序计算依赖：在训练阶段及推理的 Prefill 阶段，不需要沿时间维度依次处理输入中的每个时间点。一方面避免了计算的顺序依赖，另一方面减少了动态控制流，从而极大地提升了计算效率。 1. 计算结构简单：Transformer 使用的基本计算单元非常简单，几乎只有 GEMM、+ - * / 和 Softmax，单个Block内没有复杂的计算流程，整体架构是对基础Block的不断重复,因此，原论文的作者将其称为一个“简单”的模型。 本文不关注训练、推理等 LLM 相关业务，而是重点介绍 Transformer 中典型的基本计算单元，包括它们的逻辑功能与计算方法。 为了简化内容，本文仅关注现代 LLM（2023
从一般概念上说, 协程是特殊的函数调用: 被调用的函数可以在可控的位置被中断，然后在下一次调用时，继续从上次中断的位置继续执行。 本文主要通过Python的协程来介绍协程, 这是我唯一熟悉的一种协程实现. Classic Coroutine 下面的python代码很好的说明了协程的核心功能 def co_routine(): recv0 = yield 996 # hangs here after first coro.send assert recv0 == "Second" yield 711 # hangs here after second coro.send return def main(): coro = co_routine() # Create a new coroutine object value = coro.send(None)
这篇文章的主要应用场景是调试Python的C/C++ Extension 1. 同时使用pdb / gdb 进行调试. 通俗点说, 既可以break在 .py 文件中,也可以break在 .cc 文件中 2. 在gdb中不但可以获得常规的调试信息, 还可以获得python VM 的调试信息, 例如获得python的调用栈, 访问Python局部变量等. 这将会在调试exception时(如Segmentfalut)非常有用, 这种场景下, 定位 Python VM 正运行到哪一行代码往往可以提供一些直观的重要信息. 第一步: 编译源码以获得一些辅助数据. 我们并不真的需要使用从源码编译的Python, 但是一些调试相关的辅助文件需要从源码中获得, 包括 python-gdb.py及debug symbol等. 在 https://www.python.org/ftp/python/ 或 https://github.com/python/cpython
这是一篇2019年左右的记录, 内容可能过时, 也不太全面 杂谈 Bazel是Google为Monorepo服务而开发的构建工具. 首先是巨大,当问题的规模变大,事情总是会变得更复杂. 而Google面对的"巨大Monorepo",应该是世间罕有的. 然后是Monorepo,这极大的影响了代码的组织风格.例如,你要写一个操作系统内核ProjectOS,还要写一个游戏ProjectGame.在传统的开发习惯中,这两个项目会组织到两个不同的Repo里,PorjectOS和ProjectGame之间无法直接相互引用,例如,你在ProjectOS里写了一个高级的数据结构,想要在Game里也使用,要么直接复制粘贴,要么是创建一个新的CommonRepo,把可公用的代码都放在Common里,然后两个项目各自引入Common作为依赖. 使用MonoRepo则不存在这个问题,Game可以直接依赖OS内的组件,按照Bazel的语法描述,就是在Game中可以直接使用@ProjectOS//path/to/package:AdvancedStruct.当然,你仍然可以选择重构一
这是一篇2017年左右的记录, 仅用作分享 杂 * 在shell内能干的事,我们都可以比较简单地通过系统调用实现. * `称为反引号,^称为脱字符,常用来表示CTRL * windows的系统调用是不开放的,windows下只能直接使用windows.h里的windows API. * /dev目录下的设备是供用于程序直接使用的,主要由block,char,pipe,socket类型 * 并不是所有设备都能映射为这种形式 * /sys/device/目录称为sysfs,他下面存放了所有设备的信息.(不能直接从/dev获得任何设备信息) * udevadm info --query=all --name="/dev/sda1"可以用于查询/dev下某个设备对应的sysfs路径 权限系统 * 权限系统由两部分组成 * 文件属性:用于标注文件owner,所属组,以及权限的设定(默认只有owner和root可以修改权限设置) *
* 编译,链接,静态库与动态库 * 预备知识 * 编译: * Relocation * 静态链接 * 动态链接 * 细节问题 * 动态链接器如何确定可执行文件的所有依赖? * 文件定位的规则 * 动态relocation细节 * dlopen * fPIC * 控制DSO的dynsym符号导出 * Versioning (Version script) * Interpose * Good Practice 正确而高效的使用动态库是一个很复杂的话题,这需要开发者编译和链接有相当深入的理解. 本文主要关注"正确使用",这已经足够复杂. 这里主要是描述linux/gnu体系下编译器/链接器的行为(可能不适合其他系统,甚至不适合老版本的linux工具链), 这些行为的设计一般都有历史因素及兼容性的考量,所以某些部分可能看起来不够优美. 编译,链接,静态库与动态库 预备知识 编译: * 将单个编译
综述 TorchDynamo 的核心目标是：尽可能提高 JIT 对动态 Python 程序的覆盖率，使更多 PyTorch 程序能够在不修改原始代码的情况下获得编译加速。 对于一个待执行的 Python 函数，TorchDynamo 的基本思路是： 1. 尽可能捕获可编译的计算片段。 即使无法将整个函数编译成一个 FX Graph，也可以尝试从中提取部分可编译的计算。 1. 尽可能生成少量、较大的 FX Graph。 Dynamo 会贪婪地尝试捕获连续的计算操作。当遇到无法处理的逻辑时，通过 Graph Break 将当前计算图截断，并尽可能从后续位置继续捕获。 1. 通过原生 Python 执行逻辑将这些计算图串联起来。 最终，程序由编译后的 FX Graph 和无法捕获的 Python 代码共同组成，从而兼顾编译加速和 Python 的灵活性。 例如：
A Note for CMake CMake可以说是目前C++项目的标准构建系统, 尽管它有很多不足, 但是它已经成功的替换掉了autoconf这一代的构建工具. 除非有足够的理由, 在选择构建系统时, CMake总是应当第一优先考虑. 我熟悉的构建系统只有CMake和Bazel, 事实上, 如果能满足若干客观条件的话, 我更愿意使用Bazel, 不过这篇主要记录的是CMake, 所以还是以CMake为主. 在我看来, CMake主要的优缺点如下: Pros: 1. Imperative: 可以把CMake当做一个脚本语言来阅读, 这更符合大家的编程习惯. 2. Widely-used: 你只要大致会使用CMake, 那么世界上的大部分项目都可以被你使用了. 3. Easy-at-beginning: 上手成本很低, 简单的binary和library都很容易被描述出来, 对新手友好. Cons: 1. Too many traps: 你必须要非常熟悉CMake, 才能写出稳定可靠的CMake脚本, 否则, 处处都有坑你的陷阱. reddit上曾有一个评
Mixin Mixin是一种设计思想, 主要内容是: Mix some MixinClass into a CoreClass, so the CoreClass can get some new feature, or get enhanced. 与其他设计模式相比, Mixin的主要特点是它没有固定的编程pattern, 只是一种指导思想, 所以可能会有各种各样的具体设计自称为"Mixin", 因此, 当你看到一个"Mixin"设计时, 常常会想"我用XX不也可以实现这样的效果吗?", 这是非常正常的. 一般而言, 当设计实现了Mixin时, 常常会有以下特点: 1. 使用多继承或链式继承, 因为我们常常需要把多个MixinClass混合到CoreClass中,使用多继承或链式继承是非常直观的方法. 2. 尽管使用了继承, 但是一般不进行"覆写&