續之前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直接物理上解決問題,
更扯底是放棄馮·諾伊曼架構架構,換別的機器跑.

...想表達什麼？

真好奇作者是否對一樓有從頭講解計算機架構初步的義務…

玩AI就知道，時間都花在把資料搬來搬去，還要丟到vram裡面，都是錢R

二樓壞！XD

這個板一堆登能vibe仔然後看到這篇就安靜不敢推文了有夠可憐

cache是latency。現在是平行處理當道，如何有效運用bandwidth才重要。你想想怎樣的資料結構才能平行處理。現在sram，frequency都無法scale了，如何平行處理，如何避開lock才是設計的重點。

避開lock (X) 避開 false sharing (O)

false sharing是cache的基礎知識。如何lockless才是困難的

鎖存取是atomic的，要lockless就是造一個有atomic特性但不用lock的指令然而編譯器會自動幫你上lock的，即使開發者覺得是lockless

lockless不一定快..他只是lockless..

酷，之前用spdk他號稱lockless，但沒提到false sharing也許也跟使用者的用法有關

可想而知會被刁説難以維護開發時程慢之類的問題好的編譯器應付這種場景就變得至關重要了cache管理的細粒度有時候在相當程度上是一門藝術

工作上搞最佳化光是拆掉前人瞎雞巴亂用的design pattern就能快不少了 能探討到這個層級的狀況真的不多