性能分析新機(jī)器

當(dāng)我在新機(jī)器上工作時，我想了解它的局限性。 在這篇文章中，我將研究機(jī)器的抖動以及忙于等待本周末構(gòu)建的新PC的影響。 機(jī)器的規(guī)格很有趣，但不是發(fā)布目的。 永遠(yuǎn)不要少：

• i7-3970X六核，運(yùn)行頻率為4.5 GHz（打開HT）
• 32 GB的PC-1600內(nèi)存
• OCZ RevoDrive 3，PCI SSD（實際寫入帶寬為600 MB / s）
• Ubuntu 13.04

注意： OCZ RevoDrive在Linux上不受官方支持，但比其模型便宜得多。

測試抖動

我的微抖動采樣器查看正在運(yùn)行的線程的中斷。 它與jHiccup相似，但是它沒有測量線程喚醒的延遲，而是測量了線程一旦開始運(yùn)行如何延遲的時間。 令人驚訝的是，線程的運(yùn)行方式會影響喚醒后將看到的延遲類型。

該圖表有點密集。 它示出了一個CPU小時內(nèi)發(fā)生的平均（每次測試運(yùn)行多于兩個時鐘小時）有原始數(shù)據(jù)是可用的范圍內(nèi)的時間的中斷的數(shù)量該處

有趣的區(qū)別在于操作系統(tǒng)如何處理與隔離的CPU和/或繁忙的等待線程的綁定。

忙碌中

在繁忙等待的情況下，綁定到隔離的內(nèi)核確實有助于減少較高的延遲差距。

這些測試同時運(yùn)行。 唯一的區(qū)別是“綁定”線程綁定到“ isolcpus” CPU，該內(nèi)核的其他CPU也被隔離。 即整個核心都是孤立的。

相當(dāng)忙-50％

在這種情況下，線程在采樣1毫秒和休眠1毫秒之間交替

未綁定的50％繁忙線程的延遲要低得多，只有2微秒，但更長的延遲要多得多。

有點忙– 10％

在此測試中，采樣器運(yùn)行0.111毫秒，睡眠1毫秒。 即使在這種情況下，綁定到隔離的CPU也會有所不同。

綁定但不隔離– 10％

在這種情況下，未隔離綁定線程。 它被綁定到一個CPU上，在該CPU上內(nèi)核不是免費(fèi)的，并且也不是孤立的。 與該測試中的未結(jié)合相比，單獨結(jié)合似乎沒有什么區(qū)別。

比較綁定線程和隔離線程

我以前見過的東西，但我發(fā)現(xiàn)有點奇怪，就是如果您放棄CPU，則線程喚醒時性能會很差。 以前，我已將緩存降低為未預(yù)熱的時間，但是代碼對內(nèi)存的訪問很少，并且代碼非常短，因此仍然可能但不太可能。 以每小時一百萬的速度在20微秒處達(dá)到峰值可能是由于每次喚醒時都會發(fā)生延遲。 這大約是90,000個時鐘周期，對于高速緩存未命中來說似乎很多。

比較未綁定的線程

在此圖表中，它暗示即使您沒有被約束，對CPU的貪婪也確實有幫助。 繁忙的線程較少被中斷。 很難說50％的忙比10％的忙更好。 可能是這樣，但是需要更長的測試時間（我說這是在誤差范圍之內(nèi)）

結(jié)論

在不隔離CPU的情況下使用線程相似性在此系統(tǒng)上似乎無濟(jì)于事。 我懷疑其他Linux版本甚至Windows都是如此。 在親和力和隔離性有幫助的地方，繁忙的等待仍然有意義，因為調(diào)度程序似乎會減少中斷線程的次數(shù)（如果您這樣做的話）。

參考：來自Vanilla Java博客的JCG合作伙伴 Peter Lawrey的微抖動，繁忙等待和綁定CPU 。

翻譯自: https://www.javacodegeeks.com/2013/07/micro-jitter-busy-waiting-and-binding-cpus.html

總結(jié)

以上是生活随笔為你收集整理的微抖动，繁忙的等待和绑定CPU的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。