处理器的朴素思想

前言

计算机要解决的问题时：

• 搜索
• 调度
• 资源管理
• ？

这些问题在生活中的比喻，
衣：生产者/消费者/buffer 接口如何定义？
食：生产者与消费者之间的关系，做饭/吃饭，喊你吃饭，几种情形？
住：生产者/消费者的住宿问题，开房，退房，资源管理等
行：调度问题，先干什么，后干什么，粒度多大，依赖关系如何定义等等，层次化调用等等？

衣食住行，每个环节都涉及到搜索。
渗透在每个行为中。

从拓扑的角度看：
一个节点：构成，接口，访问时序。
两个节点：生产者消费者模型
多个节点：调度，节点之间的关系

---

生产

映射技术点

• memory consistent
  program order, execution order, perceive order
• synchronization - lock
• raw/war/waw
• cache coherency

生产者与消费者模型 — 竞争（做对）

生产与消费中的冲突

处理器的指令在遵循atomic和sequence的执行方式时，不存在冲突，但当引入流水线提高效率时，就可能有RAW冲突，RAW冲突是不可避免的，只能通过forward技术优化。

TODO WAR,WAW概述

视角对比

计算机视角	干饭视角	朴素视角
RAW，数据依赖	先做好饭，才能吃饭	生产先于消费/消费依赖生产
WAR， 资源依赖	吃完饭后，洗碗/锅之后，才能做下顿饭	生产要等消费完，腾出空间才能继续下次生产
状态信息必须晚于数据信息	你妈做好饭，再喊你吃饭	一定要先生产好数据，之后才能通知消费者
read–modify–write 原子性	多人共用厨房，查看厨房是否为空–做饭–洗锅释放厨房。 整个过程要一气呵成，不可中断	生产/消费要具有原子性

注意： 上述情况要注意，有时候同步做错了，但有一个时间差正好会掩盖同步问题，如你妈喊你吃饭，但饭还没做好，你又睡了两个小时，去了后发现饭做好了。— 虽然状态早于数据信息，但消费时机太晚，因此没有发现该问题。

对于任何一个操作，既要考虑资源依赖，又要考虑数据依赖。先看数据依赖，一个操作需要上游的供货商供货，这时候我们承担消费者角色，需要下游消费者消费，这时候我们承担生产者角色，这里要保证3点，第一在上游供货完成后，我们才能启动生产； 第二，生产完成后，才能通知下游。再看资源依赖，即我们的生产工具/资料，要保证生产工具齐全时，才能启动生产，要保证仓库没人用，我们才能将生产内容写入仓库中，即下游消费完成后我们才能回收资源启动下一次生产。

对于做饭要关注两点：

​ 做饭属于一个写操作，需要等上顿用完锅吃完饭，才能做下一顿饭（资源依赖）；

​ 下顿吃饭的人需要等当前做饭完毕后才能吃饭（数据依赖）。
对于吃饭要关注两点：
​ 吃饭属于一个读操作，需要等做饭做好后，才能吃饭（数据依赖）；

​ 需要保证吃完饭之前，不会有人做下顿饭/刷锅洗碗（资源依赖）。

赛跑与竞争

计算机视角	赛跑视角
program order	A和B听到枪声就开始起跑，起跑时间可能由如下原因造成差异： A和B听到枪声的时机不一样 A和B听到枪声后的反应时间和启动时间不一样
execution order latency不一样 碰到竞争时，优先级不一样 电子跑的速度可能不一样	跑步时间： A和B的跑道可能不一样长 A和B的跑步速度不一样快
perceive order	到达终点时间： 裁判观察有误，比如A/B是否到达终点，裁判按照轮询方式查看，会有误判，或者跑到终点的现象本身传播也需要时间

生产与消费中的流程

生产流程

1 申请生产资源，收集生产所需的原材料
2 生产
3 将生产结果放入仓库

注意，只有符合生产者流程，才能避免错误，这里罗列常见的几个错误

生产者内部流程错误：

​ 1 在输入条件不足的情况下，就启动生产；

​ 2 没有生产完，就将信息存入仓库，即将中间的半成品放进仓库；

生产者受其他竞争者影响：

​ 1 生产资源在生产过程中，被其他人占用；

​ 2 存放生产结果的仓库被其他人覆盖；

​ 3 生产未完成时，消费者就开始消费；

消费流程

1 等待生产者生产
2 消费
3 释放占用的资源

注意，只有符合消费者流程，才能避免错误，这里罗列常见的几个错误

消费者内部流程错误：

​ 1 在生产未完成情况下，就开始生产；

​ 2 在消费未完成时，就释放了资源；

消费者受其他竞争者影响：

​ 1 消费过程中，资源被其他消费者抢走；

​ 2 消费过程中，商品被其他生产者篡改；

生产与消费中的协调

什么时候生产？ 什么时候消费？

一种时靠别人通知我们，比如你妈喊你吃饭，你再去吃饭，吃完饭你喊你妈洗锅，你妈去洗锅。除此之外，也可以依靠约定，比如学校食堂约定12点开饭，大家12点过去后，饭一定时熟了。

同步与异步

计算机视角	干饭视角	朴素视角
异步	你妈喊你吃饭->你去吃饭，靠握手保证。	依靠通知/等待
同步 同步时钟，周期性检查	约定好，12点吃饭，你妈十二点前把饭做好，你12点去吃饭，靠约定保证 需要周期性检查是否快到了12点，即便定了闹钟，也是闹钟周期性检查是否到了十二点	利用时间同步 1 时间要准，不能误差太大 2 需要不断的检查时间

注意： 同步和异步，都在解决一个时机的问题。一个有意思的现象是，同步干饭约定中，大家手表的时间一定要准，误差太大会导致早到或晚到食堂。但如何把时间校准也是个问题？

在同步电路中，所有的触发器(生产者/消费者)大家需要共用一个时钟（手表），各个时钟的采样时间误差不能太大（手表要准），如何保证这个误差也是个技术活。

生产者与消费者模型 — 效率（做快）

提高效率的方法

• buffer
  生产者与消费者之间加入缓冲，缓冲解决忙闲不均的问题。
  忙闲不均，粒度平衡
  不阻塞生产，不饿死消费
• buffer深度计算
• 流水生产，
• 并行生产，
• 批处理传输，

怎么吃饭的问题

TLM的几个典型mode

• push_mode： 食堂做好菜，送到你这里，喂到你嘴里（衣来伸手，饭来张口，服务号，但是贵）
• get_mode： 食堂做好菜，你到食堂的锅里挖几勺菜（缺点是费时间）
• fifo_mode: 食堂做好菜，放到餐线上（fifo），用户从餐线上去拿菜

push mode: 富二代，衣来伸手，饭来张口
pull mode： 穷二代，需要啥得自己去拿，自己去等

生产者消费者的版本管理

• 各个小组织的经验积累与推广 — MESI实现lock
  参与方：小组A， 小组B，小组C等
  小组A与B/C协同攻坚一个项目，当小组A发现一个新方法后，立马广播大家，让别的小组暂停使用老方法，然后小组A立马将新方法写成一个方案文档放到WIKI，其他小组使用最新的方法。

• 版本管理 — bus lock
  假如有三个人ABC共同维护一个文件，文件在档案室
  当A想修改文件时，
  1 A到档案室，如果门是关的，等一等
  2 等到门开了，进去。然后把门关住(lock)
  3 修改文件
  4 打开门，出门，同时保持门的敞开状态（unlock）

• 版本管理 — coherency 的mesi实现lock
  假如有三个人ABC共同维护一个文件，文件用了一个仅支持update/commit的版本管理系统。
  当A想修改文件时，
  1 喊一声，BC先不要修改文件，并把他们的最新修改都上库。
  2 A修改完成后，再喊一声通知BC，刷新文件，基于最新的文件修改。

• 版本管理 — 乐观锁
  假如有三个人ABC共同维护一个文件，文件用了一个仅支持update/commit的版本管理系统。
  当A想修改文件时，
  1 把最新的文件更新下来，同时存储了一份副本X。
  2 A修改完成后。
  3 查看库上的文件和副本X是否相同，若不同，则重复执行1-3。
  4 若相同，则上传。

• 版本管理 — 乐观锁
  假如有三个人ABC共同维护一个文件，文件用了一个仅支持update/commit的版本管理系统，同时每次更新
  当A想修改文件时，
  1 把最新的文件更新下来，记录一个版本号X。
  2 A修改完成后。
  3 查看库上的文件是否是版本X，若不同，则重复执行1-3。
  4 若相同，则上传。

调度

映射技术点

数据结构

• schedule graph
• Directed acyclic graph

处理器架构

• Tomasulo算法
• Scoreboarding
• Dynamic Scheduling
• Static Scheduling
• VLIW（Very Long Instruction Word）

调度示例列举

• 早起穿衣/刷牙/洗脸/出发，有个依赖关系
• 泡茶的过程
• 车站/机场的调度室，让谁先走，谁后走，占用多少
• 战场： 谁先攻什么，后攻什么
• 项目流程： 从项目开始到结束，各个TR阶段等
• UVM phase机制，各个component各个phase有序推进，有时候还有domain的概念。
  （像项目的TR1/2/3一样，执行）
• linux进程调度，如何往前推进
• VCS 工具仿真，各个进程/线程，如何调度往前推进

调度的本质

功能和效率

• 从功能和效率的角度讲调度
  做对：数据依赖和资源依赖要理清楚，不能错
  做快：怎么最大化的将资源利用起来，提高任务的并行度，快速达到目标。
  该并行的并行起来，该流水的流水起来，该提前发的request提前发出去。

• 从资源和数据的两个纬度讲调度
  数据依赖：做完饭，才能吃饭
  资源依赖：洗完锅，才能做饭

• 从数据结构（graph）的角度讲调度
  数据依赖和资源依赖，抽象成一张图

调度的方法

静态调度与动态调度

• 静态调度
  计算机中，静态调度是指在编译时或者启动时就已经确定指令执行的顺序和使用的资源。静态调度的主要优点是在执行期间可以避免资源冲突和依赖性问题，但是也会导致代码生成的开销增加和执行效率降低。

• 动态调度
  动态调度是指在运行时根据当前的处理器状态和指令依赖性决定指令的执行顺序和使用的资源。动态调度的主要优点是可以在运行时根据实际情况动态调整指令的执行顺序和使用的资源，从而最大化处理器的效率。

队列调度与图调度

• 队列调度
  任务队列，将任务拆成串行的队列，告诉一件事一件事的做。（优点：傻瓜式的执行）
• 图调度
  任务图，给一个大致目标，执行者去反解该目标需要什么依赖，要那些输入，然后依次执行。（优点：执行者自己去寻找解决方案，寻找可并行的任务）
  或者也可以把任务图先理清楚，然后交给执行者去做。
  优点： 执行者调度空间大，可以挖掘并行性，进而提高效率； 减少管理者和执行者之间的交流开销。

推式调度与拉式调度

推式调度，需要管理者不断的下命令推动事件，管理者需要把任务切分好，依赖理清楚，执行者是个傻瓜，接到命令，执行，反馈。
拉式调度，管理者只需要提供一个大致目标，执行者自己去切分任务，理清依赖，全部完成后，反馈回复即可。

注意：
任务队列调度，可以把详细计划直接全部列好，然后用户自己去调度。 也可以让用户干一步，然后告诉下一步怎么做？ 即任务队列放在哪里的问题。

调度的数据结构

调度图：

调度图要展示数据依赖关系和资源依赖关系。

调度图可以静态生成或动态生成，先干什么，后干什么，表示相互依赖关系，可以相互并行的关系；

合理的调度图可以避免数据冲突，资源竞争，提高性能等。

但有时候从调度成本的角度考虑，会采用粗粒度的依赖关系，没有客观的依赖关系，但等了依赖，功能没问题，性能有些折扣，只要不影响整体目标即可。

状态表：

一张表，表示每个任务的状态。
在动态调度中，

！！！感悟： 状态机能够自动完成调度图，整个执行的过程中是按照一个调度图执行的，每达到一个状态，就会跳转到后续状态。

调度示例详解

公交车/高铁/机场调度车站

• 调度图：那一趟车早开，那一趟车晚开，那一趟车在那一趟车后面开等等
• 状态表：有一张表格，记录每辆公交车运行状态

项目管理技术（过程也是一个调度问题）

• 调度图：详细计划： 展示任务粒度划分，任务依赖关系，任务调度关系等等
• 状态表： 进展表：展示目前的状态（个人的计划等等）

大学课程安排

• 调度图：大学选课，课程之间有依赖关系，需要做拓扑排序，课程与课程之间并行的前提一个是相互独立没有依赖，另一个是两个课程之间不出现资源冲突（比如两个课程之间都需要高强度消耗体力/脑力）。
• 状态表： 每个学生目前是几年级，上了哪些课，各个课程成绩怎么样？

工作调度（工作安排） —

一张详细计划表：
对于新入职同事，尽量是队列调度，任务切分好，任务顺序列清楚。
对于经验丰富的同事，尽量是图调度，给一个大体目标，由同学去拆解和执行。
一张状态图：
目前的状态执行到什么阶段，各个比例是多少

食堂打饭

• 流水线： 肉/汤/荤菜/素材，均有专门阿姨（资源切分）。
• OOO: 前面打菜的人有时候犹豫不决，有时候后悔，后面的可以超车打菜。
• ping-pong收费：收银的地方有两个刷卡机器ping-pong操作，以防阻塞。

---

竞争

缘由

资源紧缺，资源最大化复用。因此，会引入竞争问题。

仲裁

TODO

超车

为什么要超车？

速度，效率
前面的车慢了，因为依赖，因为速度，或许其他原因。导致资源闲置，后面的车就可以冲上去，这种情况就会导致超车问题。

超车引起的一致性问题

超车后，可能出现一致性问题，侵略了别人的资源，或者摘取了别人的果实，踩踏了别人的结果。
本质上，还是破坏了数据依赖和资源依赖的问题。

超车引起的死锁问题

超车后，可能出现死锁问题，最典型的问题就是狭路相逢，互不相让问题。

死锁

同步

目的

解决一个数据依赖和资源依赖的问题。
解决什么时候干什么事情的问题

方式

时间同步

约定在同一时间干什么事，大家都拿着秒表，到时间后一起开干
比如秋收起义，南昌起义，前提是每个人时间都是对的
时间上不能有大的偏差

同步电路中，时钟源到每个register的距离都要差不多，就是要保证大家时间上差不多。
否则就会出现无法同步的情况。

事件同步

三声铳子响了后，然后干大事。
这是典型的事件同步，和上面的时间同步相比，不用每个人都看时间，也不用校准时间。

烽火传递信息，击鼓传花等等，都属于事件同步的类别。

分工

映射技术点

• job creator/dispatcher
• thread creator

大包工头与小包工头

大包工头把任务分给小包工头，小包工头完成后要向大包工头反馈。
整个包工头的关系是一颗树，大包工头包给小包工头，小包工头包给小小包工头。

CPU给GPU的任务树是怎么样的，给了什么树？树的组织关系？依赖关系？
CPU给GPU的暗示指针是什么？
GPU作为大的包工头，如何将调度任务的分解成小任务，然后分发给各个小的包工头？
各个小的包工头，如何找到各个工人/加工厂完成上述的任务的？

包工头在接收到任务时，可能会做一些任务的合并/拆分。

包工头与加工厂

工人和加工厂 是共享资源，使用这些共享资源，涉及到资源申请和释放问题。
在并行执行的过程中，有一些consistent问题，
工厂接到小包工头的单后，有时候处理有一些dependency或者order的问题，需要注意。

通过上述例子： 清楚几件事，任务，资源，资源调度，任务依赖，consistent。

加工厂，加工完成后，要把磨的面送给客户，要把加工厂打扫干净。
类似于cache的工作行为，cache做完工作后要把数据flush到外面，同时，也需要把自己invalidate干净。

下一个客户来加工时，加工厂需要把上一个客户的面粉flush干净。
否则，可以弄一个编号，区分当前客户，和上一个客户的面粉。

包工头的复用

加工厂的复用

加工厂与cache flush，不能出错—初始化与扫尾

加工厂，加工完成后，要把磨的面送给客户，然后要把加工厂打扫干净。

• flush
  目的是将生产的结果flush出去，供消费者使用。侧重生产—消费之间的关系。
  类似于cache的工作行为，cache做完工作后要把数据flush到外面，供消费者使用。

下一个客户来加工时，加工厂需要把上一个客户的面粉flush干净，否则上个生产者的面粉可能就被覆盖了，造成数据丢失/污染。
当然，如果工厂多的化，不同的生产者使用不同的工厂，就不会出现这样的问题。从编码角度看，就是可以弄一个编号，区分当前客户，和上一个客户的面粉。

• invalidate
  目的是将现场打扫干净，供下一个生产者使用加工厂。侧重生产—生产之间的关系。
  下一个客户来的时候，需要清理下自己将要使用的加工厂（先用ID invalidate一下现场），将与自己编号相同的cache场地全部清理一下，保证自己用的时候不会出现数据错误，不会被残留的数据影响（错误hit等）。

分工协作（并行计算）的常见问题

任务分配均衡问题

load balance的问题

相互依赖的同步问题

consistent问题

共享资源的竞争问题

lock， coherency，atomic等

资源

• 图书馆借书还书： 资源申请和释放

映射技术点

• cache allocate->release, refcnt
• non-blocking cache in texture
• tile buffer mangement tech
• 内存管理技术

资源基本概念

资源划分粒度

申请者粒度： 住店为例，一个人，一个人。
资源方粒度：一个房间，标间。（memory为例）

如果按照以上的思路，每次申请就开一个房，资源管理方以房间为粒度。
一个人申请分配一个标间，两个人申请也是分配一个标间。
按理来说，一个人申请时候，只需要分配一个床就可以了。
但资源方提供的粒度就是一个标间。

实例： GPU中8*8与vblk/pblk，vc分配的资源，shader分配的资源等等，都有类似的例子。

资源编码

• ID与资源（每个资源都要编号）

  • ID总数代表资源总量，ID序号代表资源编号。
  • 几个ID可以并行执行？
  • ID资源如何阻挡的？ context？
  • 并行执行切换context，加工厂污染了没有？
  • 注意区分 什么是virtual, 什么是physical ？

• ID与资源
  身份证号
  学号
  工号

• 几个问题

  1. ID状态数够不够？ 能不能表征所有的资源？
  2. ID代表的是虚拟资源还是物理资源？
  3. 各个资源/ID是否都会分配到，会不会有资源偷懒（被领导私自占领，没公开给社会）
  4. 资源用到上限了，会不会阻挡，会不会出现重新分配之类的问题？
  5. ID可能与多种类型，比如人，有家庭编号（老几），身份证号，学好，工号等。

• 问题：这个编号有如果一bit，说明只支持两个客户并行。
  这个编号如果有2bit，支持4个客户并行。
  因此，加工厂需要加入阻挡功能，当当前的客户超过最大并行度时，新进来的客户就必须要被阻挡在门口。

每届有6000个学生，每个学生都有唯一的编号。 — 并行的进程
每个学生都占用了物理资源宿舍。 每个宿舍都有一个物理编号，学生号与物理宿舍编号有映射关系。 — 资源映射
本届学生与下届学生的编号要有差异，即年份不一样。
编号的宽度要有讲究，比如只有1024个状态，那么一届内的学生都无法区分。
只要编号，编号位宽总是有限的，数学/逻辑层面讲，卷绕一定会存在的，一定会冲突的，只是位宽足够宽时，两种情况不会并行起来。或者不关心该事件。

比如： 原来在计算机系统中用两个十进制表示年份，89/90, 00/01等，进入两千年后，00/01表示的是1900还是2000就是个问题，出现了卷绕问题，为了避免这个卷绕问题，加入前缀，识别是19还是20。
但002000和012000在一万年后，一定又出现冲突/卷绕，但那时候可能无需关心该卷绕。

在GPU中，002000与012000是否会冲突，取决于在012000进程进入的时候，002000是否已经出去了。如果两者不会同时存在，则不会出现冲突。

资源的管理

资源管理流程：申请->分配->使用->释放

• 公寓管理流程：
  申请（提交申请，核实资格）->
  分配（排队等待，直到分配，分配时提供一把锁）->
  入住 (入住时先要打扫卫生[初始化]，然后再把自己的东西搬进去) ->
  使用（期间为私有，只有自己才能用）->
  释放（合同期满后，或者其他原因不再使用，搬出自己的东西，交回钥匙）
• 公寓管理注意事项：
  申请：各认证科技公司同事提交申请，管理中心决定是否批准申请。
  分配：在有资源的情况下，按照申请的先后顺序/其他策略，分配资源。申请人拿到资源后，先锁住，再使用。
  入住: 把别人用过的东西扔掉，把卫生打扫干净，把自己用的东西搬进去
  使用：使用期间要保管好钥匙，不能丢，不能还
  释放：使用完后，或者协议到期后，释放资源，注意东西得搬干净，且搬完所有东西才能还钥匙，顺序要搞对。
• 一般思想
  申请：提交申请，检查申请人是否有资格
  分配：在有资源的情况下，按照申请的先后顺序/其他策略，分配资源。申请人拿到资源后，先锁住，再使用。
  使用：使用前先初始化，使用中有排他性。
  释放：使用完后，或者协议到期后，释放资源。

资源申请

• 申请房间，释放房间
• 申请的条件？
  • 入住人检查，是否已有房间，是否需要房间，是否有资格申请。
  • 检查是否还有剩余房间，若客户已经住满则需要等待
  • 一个房间不能重复分配，否则两个客户会打架
• 阻塞申请or非阻塞申请？
  • 阻塞申请： 填完申请表后，站在柜台，直到申请批准，且分配到房间。
  • 非阻塞申请 - 1：填完申请表后，柜台给了排队号(vblkid)，申请表进入排队状态，就回家等通知了。
  • 非阻塞申请 - 2：填完申请表后，别人给了一个房间号(pblkid)，但这个房间目前还是别人住，只有将来别人搬出来后自己才能住。
• 申请的另一种特殊情况
  以公司的名义申请一个房间，然后公司的员工按顺序使用。
  实现1： 公司X申请一个房间，员工A->员工B->员工C
  实现2：公司X员工A申请->公司X员工B申请->公司X员工C申请，这些员工申请的都是同一个房间。

资源使用 — layout

什么是layout？

以一个人去旅游为例子
坐那一趟车 —

• 资源编号（每个车的物理编号）
• 申请者编号（没一车人的编号）

资源编号序列

街道的各个小区，按照一定的layout序列编号
小区中的各个楼栋，按照一定的layout序列编号
楼栋中各个家庭，按照一定的layout序列编号
家庭中的房间，按照一定的layout序列编号

申请者序列

申请者本身排队有个序列
各个公司的排队优先级不一样，会影响序列编号
公司内部申请者时间/人才认定不一样，会影响序列编号

layout的映射

申请者序列与资源编号序列的映射，也需要一个映射过程。

资源释放

• 释放的条件？
  • 客户是否已经用完了房间，该拿走的东西都拿走了？
  • 客户带走自己的东西后，才能释放
  • 房间内的所有客户都走了才能释放
  • 房间中凡是客户用过的东西都要清洗一遍（状态恢复，变量清零）
  • 进进出出，使用房间，严谨在客户中午出去吃饭时，把房间退掉。

如何提高资源利用率？

资源粒度切分

一个房间两张床，
青旅，一个房间多张床

资源合并？

虚拟资源

（酒店房间不够，酒店标间住一个人浪费，酒店隔音差）
（1 物理的不够；2 物理的浪费(holes)； 3 物理的相互干扰）

资源复用 — 空分复用

不要出现土地资源争夺的情况。

id区分？
在初始化，清楚，读取，存储的时候，都要确保操作的是id内部的，不要操作别人的空间。

资源复用 — 时分复用

• 加工厂与cache flush，不能出错—初始化与扫尾

加工厂，加工完成后，要把磨的面送给客户，要把加工厂打扫干净。

• flush的目的
  类似于cache的工作行为，cache做完工作后要把数据flush到外面，供消费者使用。
  同时，也需要把自己invalidate干净。

下一个客户来加工时，加工厂需要把上一个客户的面粉flush干净。
否则，可以弄一个编号，区分当前客户，和上一个客户的面粉。

• invalidate的目的
  下一个客户来的时候，需要先用ID invalidate一下现场，将与自己编号相同的cache场地全部清理一下，保证自己用的时候不会出现数据错误。

---

信息

映射技术点

• 数据结构技术
• 搜索
• 树
• 图

编码

存储与提取

搜索

• 图书查找(linear search, hash search, linear+hash search)
  从书架上抓对应的书籍
  从图书仓库中抓对应的书籍
• 读写存储
  是一个search的过程，寻找目标，先计算出目标所存储的地址，然后根据房间号抓到目标，最后将目标拿回来。

传输

信息容器太小： 容器太小，放不下信息。
信息缺失： 路太窄了，把信息丢掉了。（int，传给bit，损失信息）
信息扭曲： 信息传导对方了，对方解析错误。解析/编码方式没对上， 牛头不对马嘴（int传过去，float去解析）
信息走错路：信息传错路径。 阳关道，独木桥 （函数的layout传输）

• 传输？
• 效率？
• 传输： 与现实妥协

关键概念

总线传输： latency&throughput， 距离的长短与车道的宽窄
总线上的buffer： 增大服务区/休息站，解决忙闲不均的问题
总线上数据合并： 结合了批处理的思想，拼车的思想，拼在一起降低个人成本，降低整体开销

传输效率

切分

目标： 传输信息的大小；
客观：集装箱的大小，一车容量的大小；

合并

切req，切burst
一辆车：装10个集装箱（burst内并行的data）
一个订单：100个集装（切burst）
需要1000个集装箱，得下10个订单 （切req）
注意：
这样的机制涉及，主要是避免发空车的情况，或者是车内利用率不高。
有时候，只需要一个集装箱，但会拉来一车集装箱，另外10个就当垃圾扔掉了。

组warp进shader也是同样的道理，车的空载率太高的化，是对效率致命的打击。

并行（OT+OOO）

乱序发射也是提高传输效率的方法。

中转区

buffer
化零为整
不同地址零碎合并：多笔，零碎的写合并在一起后，一起写
相同地址零碎合并：各种临时写相互覆盖，获得最终值后，一起写
cache

传输方式-并行/串行

并行：多人多足。 并行第一个问题在于人和人之间难以同步，无法同一时刻统一执行命令，你慢他快，你快他慢。第二个问题在于人与人之间存在干扰，你拽他，他拖你，存在不可避免的内耗。
串行：大家排成一个队。串行的问题是在于单兵作战，需要给该单兵配备最好的武器，方天画戟，赤兔马，貂蝉等，单兵太强，很不容易听话，所以在发号命令，述职工作时，都得小心谨慎。

信息管理

信息树

树可以表示隶属关系，
树可以表示资源复用/私有情况，如使用cache（仓库），使用bus（路）的情况。
//仓库树，交通树。
命令树/包工树 — 按照组织关系将任务/命令拆解下来，层层拆解并执行，执行完后，由底向上反馈执行状态。

子树和子树之间的communication关系 （cluster内部的交流多）
子树和子树之间的contention关系 （cluster内部的共享资源，存在竞争）
子树和子树之间的dependency关系 （各个节点之间的依赖关系）

信息树生产

• 信息树的生产过程： 自上而下，自下而上
• 分类尽量均衡

信息树寻找

缩小可能性空间，搜索范围的增益尽量大
信息的消费过程，自上而下

信息树剪枝

找代表的思想

信息树层次

loop次序不一样，本质也是一个查找优先级

信息图

指令的寻址过程，输出一个图，— 链表图。
中断服务程序的过程，输出一张图，— 中断跳转图。
破案的过程，由各种线索，加上中间的推论，成功破案.。 — 线索&分析图。
生产蓝图：先申请资源，拿到所有的input，然后再干活，干完活释放资源。
调度： DAG图，有向无环图

项目任务调度图

死锁与次贷危机

效率

映射技术点

• 处理器性能提升技术
• 代码优化性性能提升技术

没必要做的事不做

• 重复无效的循环
• 生成的产品，没有客户消费
  有客户用的时候，再生产产品，避免生产的东西被浪费。
  （前面热火朝天的计算，到最后发现不用了）
  如果生产的东西与库存的东西一模一样，就无需再生成/存储。[cleanTileWriteEnable]
  （前面热火朝天的计算，搞出来后发现别人早都做好了，可以直接用，而且还更好）
  如果生产的东西被后续生产的东西覆盖，前面的生产就无需覆盖。[readback + draw_id 优化]
  （前面热火朝天的计算，中间发现方案有问题，后面只能推倒重来）
• 干事情，先干起来，不用多等
  不用等到全部的条件都满足才开工，很多事情都可以根据当前的条件开展。

重复做的事不做

日复一日的重复，重复的事情可以第一天就算好，存储到一个变量中，后面直接使用便可。

公共的事情公共做

社区医院，学校，体育馆
公共组件

static变量
全局变量

相似的事情找代表

人民代表大会
texture压缩代表
树的剪枝

可以请别人做的事不做

协处理器
编码层面： 调用底层的系统函数，调用API等

不能你让机器(资源)闲下来

流水线

• 医院
  医院有挂号&付费窗口，抓药窗口，看病窗口，三个窗口相互独立。流水线上的不同环节。
  流水线中，每个环节，都可以认为是一个进程
  资源复用

能做的事情先做起来/不用等就别等

提高效率的机制：

1. （资源）每一个工厂/每一个制造环节用到机制（如：流水线）
2. （数据/bubble）每一个产品制造依赖最小化，今天能制造的不要拖到明天。

OOO：乱序返回
OT :

手头上多做几件事，这件阻塞干那件

能一起做的事情就顺手做了

批处理
批处理命令
总线传输：批处理传输（burst）
GPU： warp

有什么事情可以提前做

prefetch技术
预测
调度

抓大放小，先粗后细

像剥洋葱一样，一层一层的剥

---

服务

映射技术点

• 调用思想
• 设计模式思想
• 指令接口设计思想

中介

司机/Driver

司机，开车，无需关注是什么车，怎么加油，怎么刹车，什么时候拐弯。
对上提供统一的服务，对下屏蔽所有的细节。

学校/医院/邮局

共享中心

班车

warp拼车

秘书部

每个HR/秘书都服务一个部门，属于一个部门的其中一员。
但HR/秘书，有一个专用部门。

算法

生活中的算法

计算机中的算法

1 存储器访问：线性查找，哈希查找
2 cache访问：搜索问题
3 MMU：搜索问题（traverse）
4 树的数据结构：总线，cache ，mmu，mem
5 生产者消费者模型：coherency，consistency，指令调度，raw
6 指令编码的算法？
7 数据运算的算法?
8 生产蓝图：先申请资源，再干活，干完活释放资源。
9 指令调度： DAG图，有向无环图。（拓扑排序）。
10 寻址：寻的本质就是搜索，搜索地址。

待归档

ping-pong buffer

cache与书架

压缩树 的结构

描述一个人的成绩：

• 平铺直叙法

什么是warp？ 什么是pblk？

warp的本质是分类，像做班车，攒够一班车就发车。
每一个分类都有一个编号，就warp_seq_id，但实际来的班车编号是那个不确定，是warp_id。·

什么是warp?

各个单位要派人到清华大学进修，各个单位抽调的人组成一个班级。这个班级就是warp。

为什么有warp_seq_id/ warp_id/ seq_id？ 各个之间的关系又是什么？

memory coherency？

吃饭，几个人点菜
用系统

总线传输的几个思想：

fence

气泡，乱序，加bubble
气泡球

传输

MMU multistage walk

sparse memory为什么能节省页表
类似与剪枝

总线传输OOO/OT

OT： 核心是几路并行？
OOO：返回后乱序，乱序就需要编号

通信的过程

打标记

传输标签信息

我叫什么名字（标签）
从哪里来（src 标签）
到哪里去（dst）

芯片硬件

setup hold
recover removal
可以抽象为 生产者-消费者模型，消费前，要等生产稳定，生产前要等消费干净。都要预留点儿margin。

consistent问题例子

来自 lock_free_programming

土豪拿了一个装满钱的 Hermes 黑色钱包去酒吧喝酒，将钱包放到吧台上后，转头和旁边的朋友聊天，小偷趁土豪转头之际拿起钱包，将钱包里的钱取出来并放入餐巾纸保持钱包厚度，然后放回原处，小偷很有职业道德，只偷钱不偷身份证，土豪转过头后发现钱包还在，并且还是他熟悉的 Hermes 黑色钱包，厚度也没什么变化，所以土豪认为什么都没发生，继续和朋友聊天，直到结账时发现钱包中的钱已经被调包成餐巾纸。

所以，我觉得 ABA 问题还可以被俗称为 “调包问题”。那么怎么解决 “调包问题” 呢？土豪开始想办法了。

土豪想的第一个办法是，找根绳子将钱包绑在手臂上，要打开钱包就得先把绳子割断，割绳子就会被发现。这种做法实际上就是 Load-Link/Store-Conditional (LL/SC) 架构中所做的工作。

土豪想的另一个办法是，在钱包上安个显示屏，每次打开钱包显示屏上的数字都会 +1，这样当土豪在转头之前可以先记录下显示屏上的数字，在转过头后可以确认数字是否有变化，也就知道钱包是否被打开过。这种做法实际上就是 x86/64 架构中 Double-Word CAS Tagging 所做的工作。

土豪还担心小偷下次会不会买一个一模一样的钱包，直接调包整个钱包，这样连银行卡和身份证都丢了怎么办，土豪决定买一个宇宙独一无二的钱包，除非把它给烧了，否则就不会再有相同的钱包出现。这种做法实际上就是 Garbage Collection (GC) 所做的工作。

TileBuffer
开房和退房
开房：你们公司有没有名额(vblk)？有没有房间（pblk）? 房间别人有没有用完？
退房：消费者有没有用完？（refcnt=0表示消费者A用完了房间）（WB完成表示消费者B用完了房间）

##几个时间概念

给均爷的理论补充一个例子，假如hit了，一分钟内就拿回数据，如果miss了，从ddr抓数据回来需要3年，用了单口，在写入cache的时候和读端口竞争了，竞争等待了5分钟。由于单口引入了5分钟的delay和三年相比，很短暂了。

算法与生活

攻击者，受害者

latch的功能/ 信号完整性的
latch工作时，有新势力和老势力，新老较劲，相互pk

---

设计模式与生活

邮局邮寄：uvm_config_db 去耦合
uvm_phase 生活实例，
盖楼，修路，做生意；
项目TR1->2->3;
函数发生仪器&示波器连接： 如何

UVM phase：

---

清鹏好友:给均爷的理论补充一个例子，假如hit了，一分钟内就拿回数据，如果miss了，从ddr抓数据回来需要3年，用了单口，在写入cache的时候和读端口竞争了，竞争等待了5分钟。由于单口引入了5分钟的delay和三年相比，很短暂了。”

---

嗯 很同意