推 slsamg7112 : AMD的不是叫SMT嗎05/06 09:56
SMT是偏向general的名詞
也有分很多種
一般x86上跟hyperthreading大致上同義
是我自己講習慣了
推 saito2190 : 我的計算機結構學老師在哭了05/06 10:02
※ 編輯: w180112 (114.137.122.150 臺灣), 05/06/2020 10:07:31
推 kimula01 : 如果縮製程 然後狂塞快取呢? 抱歉我真的外行05/06 10:44
狂塞L1 cache會導致cache searching變久讓延遲上升
更何況這是同個cache memory內的同步問題塞cache其實是無關的
※ 編輯: w180112 (114.137.122.150 臺灣), 05/06/2020 11:06:37
推 SILee : 你搞錯了吧,SMT是要榨乾ALU的使用,怎麼還會多ALU05/06 11:25
→ SILee : 需要增加的是reg file...05/06 11:26
→ SILee : cache pollution的問題確實是SMT最大的盲點05/06 11:27
→ SILee : 現在的GPU就是SMT+SIMD用到極致的設計05/06 11:29
→ SILee : 所以搞GPU的人一直很頭痛cache的設計和取捨05/06 11:30
對 我記錯了
現代x86 ALU是共用的
抱歉太久了只記得跟寫程式有關的結論
※ 編輯: w180112 (114.137.122.150 臺灣), 05/06/2020 11:46:09
→ a000000000 : 其實當今cache增加還是ipc成長的主要來源05/06 13:13
→ a000000000 : 而且製程演進最明顯的幫助就是多塞cache05/06 13:15
→ a000000000 : 不然尼加其他的東西可是用不太到05/06 13:15
我的理解是ipc增加了才導致cache可以增大吧?
推 mayolane : 樓上很多0的男人05/06 13:33
推 sufate : 看無,幫推專業 05/06 13:50
推 Secret69 : wow彥州出現了05/06 14:11
推 YandereLove : 教主賺到退休了嗎05/06 14:41
→ AmibaGelos : 莫忘吃土雞的L1I$就是只有2-way搞得一直thrash05/06 15:28
※ 編輯: w180112 (114.137.122.150 臺灣), 05/06/2020 15:46:34
推 sdbb : cache大=本多終勝 05/06 16:45
推 hcwang1126 : 製程受惠最多就快取 暴力解 05/06 22:31
→ a000000000 : 就尼等效ipc會被cache miss卡到上不去 05/07 03:13
→ a000000000 : cache大miss率就低 統計上ipc就上來惹 05/07 03:14
推 soto2080 : cache增加ipc理所當然會變大 05/08 14:14
→ soto2080 : 但是你smt再增加cache在x86這種鎖bus的真的好搞? 05/08 14:14
→ soto2080 : 如果是新的Risc類似Arm的可能還比較有搞頭吧@@? 05/08 14:14
推 soto2080 : IBM的Power能那樣搞是因為Reservation Engine吧 05/08 14:18