續之前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直接物理上解決問題,
更扯底是放棄馮·諾伊曼架構架構,換別的機器跑.
--
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 182.233.248.16 (臺灣)
※ 文章網址: https://www.ptt.cc/bbs/Soft_Job/M.1780732366.A.5C5.html