引用:
|
作者jasonyang
你的說法比較奇怪，但也沒錯(少了個前提)，pipeline stage 越多，並不會影響分支測率，如果 "分支預測正確率" 不變的情形下，錯誤執行的指令的確會增多。
分支預測正確率是與 pipeline stage 數量(或說深度)無關的，而與分支預測的演算法有關，當執行單元發現分支預測錯誤後，錯誤執行的指令必需被清空，這代表 IPC 降低，效能不好，為了彌補 "性能" 的不足，又無法提高有效 IPC(提升錯誤分支預測的正確率，或是增加快取、TLB 等)，只好提升時脈，為了提高時脈，又必須把 pipeline stage 切得更細，變得有點惡性循環。
而 pipeline stage 越多，表示同時動作的電晶體與電容更多，再加上錯誤執行的指令，與加大的 L1 & L2 cache，就算不改 90nm 製程，功耗大增是可預期的。
另外 thread 中文翻譯是執行緒，如果這個不懂的話，要去看 OS 與系統程式和一些程式語言的書。
1 thre...
|
我所說的並不是分支預測的錯誤率 而是在通過鎖存器往流水綫當中打入任務和數據的時候所發生的錯誤。在目前的技術條件下，流水綫的增加必將導致錯誤率的上升。而目前無論是intel和AMD都採用很愚蠢的辦法 那就是從頭再來。因此。流水綫的增加又必將導致再重新填充任務的時候浪費更多的時脈。這就是intel的執行效率很低的原因所在。如果intel可以將因爲重新填充任務和數據所帶來的時脈的浪費挽救回來的話。性能必將有極大的提升。
對於分支預測，我想現在intel和AMD沒有多大的差別。因爲如果分支預測發生錯誤而導致無法在L2當中找到需要的指令或者數據的話就需要到内存當中去尋找指令或者數據。這個問題無論是在intel還是AMD當中都是實實在在存在著的。雖然這個過程必將浪費很多時脈，但這並不是intel性能平平而功耗驚人的主要原因所在。 不過目前無論是intel還是AMD 在分之預測的算法方面都有了進步。否則的話intel和AMD的產品的L2是不會輕易的提升到1MB的。大容量L2必須要有相應的算法支持 否則只能適得其反。
對於thread 實在是很抱歉，這個詞在大陸這邊是翻譯成綫程 我剛開始並沒有想到會是這個詞。我身邊的文曲星也未能給出合理的解釋 謝謝您的提醒！