2012-03-09 43 views
9

假設我只有4個內核,測量程序加速的最佳方法是什麼?很明顯,我可以測量到4,但如果知道8,16等等,這將是很好的。如何測量我的多線程代碼如何縮放(加速)?

理想我想知道每個線程的數量增速的量,類似於該圖:

Amdahl's law diagram

有沒有什麼辦法可以做到這一點?也許一種模擬多核的方法?

+4

+1對於視覺效果。簡而言之,你無法做出有根據的猜測。 – Mysticial 2012-03-09 22:51:07

+0

@Mysticial,但你不應該用英特爾的VTune之類的工具來衡量嗎? – 2012-03-10 02:30:13

+0

@ConradFrix不是當你試圖猜測你沒有的16核上的性能時。另一方面,您可以使用VTune來分析4個內核的性能,並根據這些數字嘗試推斷爲16個內核。那或多或少是一種「受過教育的猜測」。 – Mysticial 2012-03-10 02:32:31

回答

2

我不認爲有一個真正的方法來做到這一點,但我想到的一件事是,你可以使用虛擬機來模擬更多的核心。例如,在VirtualBox中,您最多可以從標準菜單中選擇16個核心,但我確信存在一些黑客攻擊,可以使更多虛擬機和VMware等其他虛擬機甚至可以支持更多的開箱即用功能。

enter image description here

+0

virtualbox如何模擬更多內核? – CMCDragonkai 2015-03-04 08:17:46

+0

@CMCDragonkai嗯,這是虛擬化。它可以告訴客戶操作系統,無論它想要什麼。 – inf 2015-03-04 08:23:11

+0

然後它是否將這些模擬內核穿入真實的物理內核?所以,如果我有4個內核,那麼我可以使用VirtualBox創建100個模擬內核?我沒有這樣的能力! – CMCDragonkai 2015-03-04 08:26:28

1

我不相信這是可能的,因爲有太多的變量,能夠準確地推斷服務表現。即使假設你是100%平行的。還有其他因素,例如公交車速度和緩存未命中可能會限制您的表現,更不用說表演的表現了。所有這些因素如何影響您的代碼只能通過在您的特定硬件平臺上進行測量來完成。

2

bamboon和多倫和是正確的,很多變量在起作用,但如果你有一個可調輸入大小n,你可以計算出強縮放弱縮放你的代碼

強擴展指的是修復問題大小(例如n = 1M)並改變可用於計算的線程數。弱縮放指的是修復每個線程(n = 10k/thread)的問題大小並改變可用於計算的線程的數量。

確實在任何程序中都有很多變量在工作 - 但是如果你有一些基本的輸入大小n,就有可能得到一些縮放比例。在幾年前我開發的一個n體模擬器上,我改變了固定大小的線程和每個線程的輸入大小,並能夠合理地計算出多線程代碼縮放程度的粗略度量。

由於您只有4個內核,因此只能切實計算最多4個線程的擴展。這嚴重限制了您查看擴展到大量線程負載的能力。但是,如果您的應用程序僅用於核心數量較少的機器上,則這可能不是問題。

你真的需要問自己這個問題:這是要在10,20,40多個線程上使用嗎?如果是這樣,準確確定這些制度的縮放比例的唯一方法就是在具有可用硬件的平臺上進行實際基準測試。


邊注:根據您的應用程序,它可能並不重要,你只擁有4個核心。如果許多線程花費時間「等待」發生某些事情(例如Web服務器),則某些工作負載會隨着線程的增加而擴展,而不管可用內核的實際數量是多少。如果你正在做純計算,情況並非如此

+0

我認爲[Amdahl's law](http://en.wikipedia。org/wiki/Amdahl's_law)僅適用於消耗CPU時間的任務。 – 2012-03-10 02:24:13

3

對不起,但在我看來,唯一可靠的測量是實際獲得一個8,16或更多的核心機器和測試那。內存帶寬飽和,CPU功能單元數量和其他硬件瓶頸可能會對可伸縮性產生巨大影響。我從個人經驗中知道,如果一個程序在2個內核和4個內核上擴展,在8個內核上運行時可能會顯着減慢,僅僅因爲8個內核無法擴展到8個內核是不夠的。

你可以嘗試預測會發生什麼,但也有很多需要考慮到的因素:

  1. 緩存 - 尺寸,層數,共享/非共享
  2. 內存帶寬
  3. 核心數量與處理器數量即它是8核心機器還是雙核心機器
  4. 核心之間的互連 - 較少數量的核心(2,4)仍可以合理工作還有一條總線,但是對於8個或更多內核來說,這是一個更復雜的互連離子是需要的。
  5. 內存訪問 - 再次,較少數量的內核與SMP(對稱多處理器)模型很好地工作,而較大數量的內核需要NUMA(非統一內存訪問)模型。
1

我認爲你是在問測量,所以我不會解決預測對較高數量內核的影響問題。

可以用另一種方式來看待這個問題:您可以保持每個線程的繁忙程度,以及它們總計達到什麼程度?因此,對於六個線程,每個線程使用50%的利用率,意味着您有3個相同的處理器正在運行。除以4個處理器,意味着您的方法實現了75%的利用率。將實際利用率與實際加速時鐘相比較,可以告訴您利用率有多少是新的開銷,以及實際加速的數量。這不是你真正感興趣的嗎?

處理器利用率可以通過幾種不同的方式實時計算。線程可以獨立地詢問系統的線程時間,計算比率並保持全局總計。如果您可以完全控制阻塞狀態,則您甚至不需要系統調用,因爲您可以跟蹤阻塞機器週期與非阻塞機器週期的比率,以計算利用率。我開發的實時多線程工具包使用這種方法,並且它們運行良好。更新的cpus中的cpu時鐘計數器在20個機器週期內讀取。