Re: [心得] 冯·诺伊曼架构的物理墙

楼主: x000032001 (版废了该走了)   2026-06-16 16:29:32
※ 引述《erspicu (.)》之铭言:
: 标题: [心得] 冯·诺伊曼架构的物理墙
: 时间: Sat Jun 6 15:52:42 2026
:
:
: 续之前side project学到
: i-cache的优化策略和bitwise.swar(SIMD Within A Register).
: 还有branchless各种加速技巧后 (这些都比较偏向Cpu ALU效率问题)
branchless加速技巧其实本身场景有点受限,因为现代CPU分支预测器太强了
perf event有抓出bad speculation再加比较有价值
: 现在的side project撞到另外一个墙 是冯诺伊曼架构 天花板之一
: 也就受计算受限于内存延迟,用netlist跑Switch-level简化Transistor-level计算,
: https://gemini.google.com/share/8014e5049296
: 多数时间cost不是在于节点跟节点之间搜寻.计算.更新,
: 而是要处理随机分布的内存资料,产生cpu其实有点喂不饱,
: cost全在捞内存资料本身,你再怎样改善,墙就是在那边,
资料结构要重新思考一次。像Tree or Linked List是特定场景加上大N才有改善。
资料量太小是纯纯拿大砲打小鸟。可以考虑换成简单的vector<>或flat hash map<>这种
cache friendly资料结构
: 但还是有一些优化技巧(但你再怎么优化天花板就还是在那边),
: 不过我真的不知道这些优化技巧除了side project或是啥3a游戏.特定算法之类的,
: 还能用在哪里,已经不在多数人工作需要考虑到的范围内.
高频交易、游戏。不考虑吞吐量而是考虑延迟的场景。
其实看cppcon都哪些人在讲这种主题就大概知道什么公司会用到。
: 原则上其实跟i-cahe优化很相似,只是这次变成减少 L-cache的存取次数.大小,
: 原则就两个 想办法缩减资料布局甚至透过pack压缩
: (但你也得算解压缩本身的ALU cost划不划算),
资料面我个人觉得投资在思考struct of array / array of struct
以及hot data / cold data拆开存以及cache alignment这三件事就有不错进展了
顶多在struct layout太浪费的时候用struct bit field去更有效利用空间
如果还需要bitwise等级以上的算法去encode/decode,本身也是多花好几个cycle
: 尽可能让热资料放到比较快的cache层级内,
: 但实际上没办法决定资料会放到哪一层cache,
: 我们只能尽可能创造让资料尽可能放到更快cache的机率条件,
也是可以用Intel Cache Allocation Technology去多抢一些空间回来啦
但没办法硬要一块也是真的
允许的话还是把热资料控制在能全部塞进L2,尽量减少被换去L3的机会
同时减少L1 miss, L2 miss的stall latency
至于做法,就是经常去问候他,让他可以一直留着而已
实务上观察,大概问候程度抓在100microseconds比较合适,1ms是最大容忍
再大的话就经常在掉了。一旦变冷就会直接观察到延迟往上飘200-1000ns不等
不过资料量小,到最后反而是i-cache miss严重很多,要靠很多手段去手工调整
编译器产生出来的code,像是
- text hold / cold 区域分离
- likely / unlikely
- 错误处理 / logging 程式码想办法把它推到比较远的地方
- 减少没必要的inline
- 思考template过度展开的一堆复制贴上程式码
: 然后资料也有分冷热,分开管理也是一个技巧,还有减少存取次数,
: 像是用long型态一次抓多几笔资料,还有包装成64byte技巧会比较顺,
: 另外也有接触到prefetch的技巧,
: 但对我专案没有用,好奇可以看看AI整理的专案笔记,原则上工作压根用不到,
: 当你哪天需要在那边斤斤计较什么I-CAHE L-CACHE Missing的这种层级的议题,
: 应该是在啥满厉害的公司了,感觉上L-CACHE某些SERVER和数据库的优化议题可能会用到.
:
: https://erspicu.github.io/AprVisual/cache.html
: 可以看一个概念,或许哪天真的有派得上作用的地方.
:
: 最后如果想看看自己电脑效能 可以抓个benchmak跑看看
: https://erspicu.github.io/AprVisual/
: 上传排行榜pk一下
: https://baxermux.org/myemu/AprVisual/
: 也可以看看用netlist跑任天堂红白机主机跟实机的效能差异
: https://erspicu.github.io/AprVisual/calculator.html
:
: 说老半天...其实最快的解决方式是换一颗cache更大的cpu直接物理上解决问题,
: 更扯底是放弃冯·诺伊曼架构架构,换别的机器跑.
现在CPU就这样,不然就只能走ASIC / FPGA那个路线
:
:
作者: notBeing (read and be read)   2026-06-16 16:33:00
Good
作者: labbat (labbat)   2026-06-16 17:26:00
x86原则上是TSO,但除了写回wb还有禁写wp写穿wt可以耍不过这些延迟改善没有实时操作系统特调acpi服务的改善大
作者: erspicu (.)   2026-06-16 23:19:00
很有意思的优化调整 只是无奈一般情况下碰不太到
作者: chao0210 (半糖多多绿)   2026-06-18 01:39:00
我来研究一下
作者: oopFoo (3d)   2026-06-18 07:17:00
就资料结构才是重点,我80%的时间都在花时间安排datalayout。改了又改都很平常
作者: wulouise (在线上!=在电脑前)   2026-06-18 08:17:00
hft或是游戏业比较会遇到这种吧,请问你在那个产业

Links booklink

Contact Us: admin [ a t ] ucptt.com