linus對於zen 2目前的看法 - 3C

Table of Contents

: 推 kira925 : 那一串後面Linus還多回了幾段XD 08/11 10:31

大致翻一下好了
基本就是真·閒聊
source同個來源


一封是說Linus自己也是很注重單核效能的
畢竟Amdhal's Law擺在那邊(*1)
但是單核效能水準zen 2也已經很不賴了,足敷他的需求
而他自己最常需要做、且吃重效能的工作是編譯kernel
儘管還是會有不能平行化的部分
需要整個重編的情況剛好都是平行化得很好的,甚至能用上幾百個核心

當然以這樣的workflow來說他弄個TR甚至專用的farm會是個更高效的選擇
但是這些偏伺服/hedt的零件建置起來麻煩
並且機器通常偏吵而佔空間
不符他的個人喜好


一封是解釋為甚麼還沒看到因為rdrand出事而造成kernel出bug的回報
並且對這次事件下些評論

Linus認為zen 2的rdrand問題應該跟以前amd也曾經出現過的rdrand問題不太一樣
而目前看來可以透過微碼更正這個問題
代表這個問題的肇因實際上應該蠻蠢的

kernel多少有用到rdrand指令沒錯
不過設計上kernel並不是完全信賴這個指令
都會對產生的值進行其它處理
並且也沒有重複call很多次(*2)
因此Linus認為AMD壞掉的rdrand應該不會對kernel造成甚麼可觀測到的影響
不過還是自嘲這句話是個大大的flag

這次事件來說
kernel因為其設計上的細心所以沒出啥漏子
但是上次那波rdrand還是影響到了openssl
而這次至少也有systemd受害
原則上來說我們不應該相信指令有問題的cpu上跑出來的結果
這次整體來說問題不大,只是令人對AMD感到失望
至少明顯可以看出AMD的測資沒有cover到rdrand這塊

如果這是zen 2唯一的問題的話
對於AMD會是件再好不過的事
不過這架構太新了,因此顯然我們目前的測資也不完善,還不能妄下定論。



按:

1. Amdahl's Law
假設一個task有27.648%不可能平行化
那麼無論再怎麼優良的設計
就算其他1-27.648%的task因為理想的平行化而需要的時間趨於0
還是需要單核去幹掉剩下那部分
因此這個case無論核心數再怎麼堆程式再怎麼平行化
加速效果不超過4倍

2.
intel的rdrand無論是需要等待的clock
還是其最高的throughput
都比amd的要好上一兩個數量級
而且intel的無論16b 32b 64b耗時相同
amd的耗時則隨一次需要的大小線性增長

--

All Comments

Kyle avatarKyle2019-08-13
推翻譯
Joe avatarJoe2019-08-15
https://tinyurl.com/y5wmparw systemd PR for AMD
這邊修的想法也是類似,就是看到怪怪的值就丟掉XD
Joe avatarJoe2019-08-16
無法理解為什麼rng一直出包 這明明是老掉牙了啊Orz
Michael avatarMichael2019-08-20
上次出過包了,這次還沒有加強驗真的很雷,難怪會說
embarrassing
Victoria avatarVictoria2019-08-24
Dorothy avatarDorothy2019-08-25
從推土機就有了 AMD完全沒把這當一回事吧
Selena avatarSelena2019-08-26
當年連主流市場都沒量,哪有餘力管這種
Quanna avatarQuanna2019-08-31
推土機只能打較高耗電文書影音機的市場...
專業或高性能需求根本不會有人考慮
Joe avatarJoe2019-09-04
我賭一份雞排加珍奶,這次Rdrand指令爆炸是因為微
碼在指令執行後才立Flag