Re: [閒聊] linus對於zen 2目前的看法

[a58524andy (a58524andy)]

: 推 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的耗時則隨一次需要的大小線性增長

--
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 140.112.244.224 (臺灣)
※ 文章網址: https://www.ptt.cc/bbs/PC_Shopping/M.1565534435.A.88F.html
推 kuninaka    : 推翻譯
推 soem        : https://tinyurl.com/y5wmparw systemd PR for AMD
→ soem        : 這邊修的想法也是類似，就是看到怪怪的值就丟掉XD
→ AmibaGelos  : 無法理解為什麼rng一直出包 這明明是老掉牙了啊Orz
推 brianhsu    : 上次出過包了，這次還沒有加強驗真的很雷，難怪會說
→ brianhsu    :  embarrassing
推 felaray     : 推
→ friedpig    : 從推土機就有了 AMD完全沒把這當一回事吧
→ kuma660224  : 當年連主流市場都沒量，哪有餘力管這種
→ kuma660224  : 推土機只能打較高耗電文書影音機的市場...
→ kuma660224  : 專業或高性能需求根本不會有人考慮
→ skycat2216  : 我賭一份雞排加珍奶，這次Rdrand指令爆炸是因為微
→ skycat2216  : 碼在指令執行後才立Flag