※ 引述《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那個路線
:
: