推 notBeing: Good 06/16 16:33
→ labbat: x86原則上是TSO，但除了寫回wb還有禁寫wp寫穿wt可以耍 06/16 17:26
→ labbat: 不過這些延遲改善沒有實時操作系統特調acpi服務的改善大 06/16 17:29
→ erspicu: 很有意思的優化調整 只是無奈一般情況下碰不太到 06/16 23:19
※ 引述《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://www.ptt.cc/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://www.ptt.cc/bbs/Soft_Job/M.1781598576.A.B69.html