※ 引述《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那个路线 : : -- :

※ 发信站: 批踢踢实业坊(ptt.cc), 来自: 182.233.248.16 (台湾) : ※ 文章网址: https://webptt.com/cn.aspx?n=bbs/Soft_Job/M.1780732366.A.5C5.html : → Lipraxde: ...想表达什麽？ 06/08 11:55 : 推 aarzbrv: 真好奇作者是否对一楼有从头讲解计算机架构初步的义务… 06/08 18:50 : → wei115: 玩AI就知道，时间都花在把资料搬来搬去，还要丢到vram里 06/08 20:48 : → wei115: 面，都是钱R 06/08 20:48 : 推 marra: 二楼坏！XD 06/09 03:10 : 推 USD5566: 这个板一堆登能vibe仔然後看到这篇就安静不敢推文了有够 06/09 10:04 : → USD5566: 可怜 06/09 10:04 : → oopFoo: cache是latency。现在是平行处理当道，如何有效运用 06/09 10:56 : → oopFoo: bandwidth才重要。你想想怎样的资料结构才能平行处理。 06/09 10:57 : → oopFoo: 现在sram，frequency都无法scale了，如何平行处理，如何 06/09 11:00 : → oopFoo: 避开lock才是设计的重点。 06/09 11:00 : → firejox: 避开lock (X) 避开 false sharing (O) 06/09 18:54 : 推 oopFoo: false sharing是cache的基础知识。如何lockless才是困难的 06/09 22:17 关键就是让执行绪之间根本不要沟通，就没有这些问题 : → labbat: 锁存取是atomic的，要lockless就是造一个有atomic特性但不 06/10 01:48 : → labbat: 用lock的指令 06/10 01:49 : → labbat: 然而编译器会自动帮你上lock的，即使开发者觉得是lockless 06/10 01:52 : → wulouise: lockless不一定快..他只是lockless.. 06/10 08:54 最後都会直接去玩memory model，所以如果是x86，他的TSO..像是LMAX Disruptor实际上 如果跑single producer / single consumer模式，不用去做bus locking 一般的mov就保证执行绪间安全了。传统的boost::lockfree那组东西被我几乎砍光光， 因为多执行绪架构选对的话有更好的选择 : 推 shibin: 酷，之前用spdk他号称lockless，但没提到false sharing 06/10 10:02 : → shibin: 也许也跟使用者的用法有关 06/10 10:02 : 推 jhjhs33504: 可想而知会被刁説难以维护开发时程慢之类的问题 06/10 19:06 : → jhjhs33504: 好的编译器应付这种场景就变得至关重要了 06/10 19:08 : 推 jhjhs33504: cache管理的细粒度有时候在相当程度上是一门艺术 06/10 19:11 跟FPGA比起来都很快 XD : 推 leftless: 工作上搞最佳化光是拆掉前人瞎鸡巴乱用的design pattern 06/14 18:38 : → leftless: 就能快不少了 能探讨到这个层级的状况真的不多 06/14 18:38 -- ※ CTO, Stranity --

※ 发信站: 批踢踢实业坊(ptt.cc), 来自: 59.126.5.109 (台湾) ※ 文章网址: https://webptt.com/cn.aspx?n=bbs/Soft_Job/M.1781598576.A.B69.html