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

※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 182.233.248.16 (臺灣) : ※ 文章網址: https://webptt.com/m.aspx?n=bbs/Soft_Job/M.1780732366.A.5C5.html : → Lipraxde: ...想表達什麼？ 06/08 11:55 : 推 aarzbrv: 真好奇作者是否對一樓有從頭講解計算機架構初步的義務… 06/08 18:50 : → wei115: 玩AI就知道，時間都花在把資料搬來搬去，還要丟到vram裡 06/08 20:48 : → wei115: 面，都是錢R 06/08 20:48 : 推 marra: 二樓壞！XD 06/09 03:10 : 推 USD5566: 這個板一堆登能vibe仔然後看到這篇就安靜不敢推文了有夠 06/09 10:04 : → USD5566: 可憐 06/09 10:04 : → oopFoo: cache是latency。現在是平行處理當道，如何有效運用 06/09 10:56 : → oopFoo: bandwidth才重要。你想想怎樣的資料結構才能平行處理。 06/09 10:57 : → oopFoo: 現在sram，frequency都無法scale了，如何平行處理，如何 06/09 11:00 : → oopFoo: 避開lock才是設計的重點。 06/09 11:00 : → firejox: 避開lock (X) 避開 false sharing (O) 06/09 18:54 : 推 oopFoo: false sharing是cache的基礎知識。如何lockless才是困難的 06/09 22:17 關鍵就是讓執行緒之間根本不要溝通，就沒有這些問題 : → labbat: 鎖存取是atomic的，要lockless就是造一個有atomic特性但不 06/10 01:48 : → labbat: 用lock的指令 06/10 01:49 : → labbat: 然而編譯器會自動幫你上lock的，即使開發者覺得是lockless 06/10 01:52 : → wulouise: lockless不一定快..他只是lockless.. 06/10 08:54 最後都會直接去玩memory model，所以如果是x86，他的TSO..像是LMAX Disruptor實際上 如果跑single producer / single consumer模式，不用去做bus locking 一般的mov就保證執行緒間安全了。傳統的boost::lockfree那組東西被我幾乎砍光光， 因為多執行緒架構選對的話有更好的選擇 : 推 shibin: 酷，之前用spdk他號稱lockless，但沒提到false sharing 06/10 10:02 : → shibin: 也許也跟使用者的用法有關 06/10 10:02 : 推 jhjhs33504: 可想而知會被刁説難以維護開發時程慢之類的問題 06/10 19:06 : → jhjhs33504: 好的編譯器應付這種場景就變得至關重要了 06/10 19:08 : 推 jhjhs33504: cache管理的細粒度有時候在相當程度上是一門藝術 06/10 19:11 跟FPGA比起來都很快 XD : 推 leftless: 工作上搞最佳化光是拆掉前人瞎雞巴亂用的design pattern 06/14 18:38 : → leftless: 就能快不少了 能探討到這個層級的狀況真的不多 06/14 18:38 -- ※ CTO, Stranity --

※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 59.126.5.109 (臺灣) ※ 文章網址: https://webptt.com/m.aspx?n=bbs/Soft_Job/M.1781598576.A.B69.html