[心得] 馮·諾伊曼架構的物理牆

看板Soft_Job (軟體人)作者 (.)時間2周前 (2026/06/06 15:52), 編輯推噓8(8016)
留言24則, 12人參與, 1周前最新討論串1/2 (看更多)
續之前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

06/08 11:55, 2周前 , 1F
...想表達什麼?
06/08 11:55, 1F

06/08 18:50, 2周前 , 2F
真好奇作者是否對一樓有從頭講解計算機架構初步的義務…
06/08 18:50, 2F

06/08 20:48, 2周前 , 3F
玩AI就知道,時間都花在把資料搬來搬去,還要丟到vram裡
06/08 20:48, 3F

06/08 20:48, 2周前 , 4F
面,都是錢R
06/08 20:48, 4F

06/09 03:10, 2周前 , 5F
二樓壞!XD
06/09 03:10, 5F

06/09 10:04, 2周前 , 6F
這個板一堆登能vibe仔然後看到這篇就安靜不敢推文了有夠
06/09 10:04, 6F

06/09 10:04, 2周前 , 7F
可憐
06/09 10:04, 7F

06/09 10:56, 2周前 , 8F
cache是latency。現在是平行處理當道,如何有效運用
06/09 10:56, 8F

06/09 10:57, 2周前 , 9F
bandwidth才重要。你想想怎樣的資料結構才能平行處理。
06/09 10:57, 9F

06/09 11:00, 2周前 , 10F
現在sram,frequency都無法scale了,如何平行處理,如何
06/09 11:00, 10F

06/09 11:00, 2周前 , 11F
避開lock才是設計的重點。
06/09 11:00, 11F

06/09 18:54, 2周前 , 12F
避開lock (X) 避開 false sharing (O)
06/09 18:54, 12F

06/09 22:17, 2周前 , 13F
false sharing是cache的基礎知識。如何lockless才是困難的
06/09 22:17, 13F

06/10 01:48, 2周前 , 14F
鎖存取是atomic的,要lockless就是造一個有atomic特性但不
06/10 01:48, 14F

06/10 01:49, 2周前 , 15F
用lock的指令
06/10 01:49, 15F

06/10 01:52, 2周前 , 16F
然而編譯器會自動幫你上lock的,即使開發者覺得是lockless
06/10 01:52, 16F

06/10 08:54, 2周前 , 17F
lockless不一定快..他只是lockless..
06/10 08:54, 17F

06/10 10:02, 2周前 , 18F
酷,之前用spdk他號稱lockless,但沒提到false sharing
06/10 10:02, 18F

06/10 10:02, 2周前 , 19F
也許也跟使用者的用法有關
06/10 10:02, 19F

06/10 19:06, 2周前 , 20F
可想而知會被刁説難以維護開發時程慢之類的問題
06/10 19:06, 20F

06/10 19:08, 2周前 , 21F
好的編譯器應付這種場景就變得至關重要了
06/10 19:08, 21F

06/10 19:11, 2周前 , 22F
cache管理的細粒度有時候在相當程度上是一門藝術
06/10 19:11, 22F

06/14 18:38, 1周前 , 23F
工作上搞最佳化光是拆掉前人瞎雞巴亂用的design pattern
06/14 18:38, 23F

06/14 18:38, 1周前 , 24F
就能快不少了 能探討到這個層級的狀況真的不多
06/14 18:38, 24F
文章代碼(AID): #1g8z7EN5 (Soft_Job)
文章代碼(AID): #1g8z7EN5 (Soft_Job)