續之前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://webptt.com/m.aspx?n=bbs/Soft_Job/M.1780732366.A.5C5.html