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

楼主: erspicu (.)   2026-06-06 15:52:42
续之前side project学到
i-cache的优化策略和bitwise.swar(SIMD Within A Register).
还有branchless各种加速技巧后 (这些都比较偏向Cpu ALU效率问题)
现在的side project撞到另外一个墙 是冯诺伊曼架构 天花板之一
也就受计算受限于内存延迟,用netlist跑Switch-level简化Transistor-level计算,
https://gemini.google.com/share/8014e5049296
多数时间cost不是在于节点跟节点之间搜寻.计算.更新,
而是要处理随机分布的内存资料,产生cpu其实有点喂不饱,
cost全在捞内存资料本身,你再怎样改善,墙就是在那边,
但还是有一些优化技巧(但你再怎么优化天花板就还是在那边),
不过我真的不知道这些优化技巧除了side project或是啥3a游戏.特定算法之类的,
还能用在哪里,已经不在多数人工作需要考虑到的范围内.
原则上其实跟i-cahe优化很相似,只是这次变成减少 L-cache的存取次数.大小,
原则就两个 想办法缩减资料布局甚至透过pack压缩
(但你也得算解压缩本身的ALU cost划不划算),
尽可能让热资料放到比较快的cache层级内,
但实际上没办法决定资料会放到哪一层cache,
我们只能尽可能创造让资料尽可能放到更快cache的机率条件,
然后资料也有分冷热,分开管理也是一个技巧,还有减少存取次数,
像是用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直接物理上解决问题,
更扯底是放弃冯·诺伊曼架构架构,换别的机器跑.
作者: Lipraxde (Lipraxde)   2026-06-08 11:55:00
...想表达什么?
作者: aarzbrv (我爱钻石光! 芒! 长!~~)   2026-06-08 18:50:00
真好奇作者是否对一楼有从头讲解计算机架构初步的义务…
作者: wei115 (ㄎㄎ)   2026-06-08 20:48:00
玩AI就知道,时间都花在把资料搬来搬去,还要丢到vram里面,都是钱R
作者: marra (Marra)   2026-06-09 03:10:00
二楼坏!XD
作者: USD5566 (美金五千五百六十六)   2026-06-09 10:04:00
这个板一堆登能vibe仔然后看到这篇就安静不敢推文了有够可怜
作者: oopFoo (3d)   2026-06-09 10:56:00
cache是latency。现在是平行处理当道,如何有效运用bandwidth才重要。你想想怎样的资料结构才能平行处理。现在sram,frequency都无法scale了,如何平行处理,如何避开lock才是设计的重点。
作者: firejox (Tangent)   2026-06-09 18:54:00
避开lock (X) 避开 false sharing (O)
作者: oopFoo (3d)   2026-06-09 22:17:00
false sharing是cache的基础知识。如何lockless才是困难的
作者: labbat (labbat)   2026-06-10 01:48:00
锁存取是atomic的,要lockless就是造一个有atomic特性但不用lock的指令然而编译器会自动帮你上lock的,即使开发者觉得是lockless
作者: wulouise (在线上!=在电脑前)   2026-06-10 08:54:00
lockless不一定快..他只是lockless..
作者: shibin (喜饼)   2026-06-10 10:02:00
酷,之前用spdk他号称lockless,但没提到false sharing也许也跟使用者的用法有关
作者: jhjhs33504 ( )   2026-06-10 19:06:00
可想而知会被刁说难以维护开发时程慢之类的问题好的编译器应付这种场景就变得至关重要了cache管理的细粒度有时候在相当程度上是一门艺术
作者: leftless (两个月倒一次垃圾)   2026-06-14 18:38:00
工作上搞最佳化光是拆掉前人瞎鸡巴乱用的design pattern就能快不少了 能探讨到这个层级的状况真的不多

Links booklink

Contact Us: admin [ a t ] ucptt.com