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