從微小而且集成度非常高的片上系統(tǒng)，到大型數(shù)據(jù)中心，多核革命已經(jīng)呈現(xiàn)出烽火燎原之勢。那么，當你在設計自己的系統(tǒng)時，怎樣才能把多核技術發(fā)揮到極致呢?另外需要注意的是，要在一個多核系統(tǒng)中把每一份計算能力都充分利用起來，并不是一件容易的事。
當今的多核處理器絕不僅僅是把多個處理器放進同一個芯片那么簡單。領先的處理器提供商在其產(chǎn)品中植入了很多有用的特殊功能。例如，散列(hashing)、高速緩存(caching)、處理器間通信、中斷管理和內(nèi)存管理等。這些功能特性如果能夠善加利用，就會讓AMP架構高效率地運行起來，這就需要在軟件上進行專門的優(yōu)化。
我們知道，多核處理架構基本上可以分為對稱多處理(SMP)和非對稱多處理(AMP)兩種。SMP架構的特征是同等地看待每一個處理器內(nèi)核，不會特別指定哪個內(nèi)核或者哪些內(nèi)核去執(zhí)行哪個特定的任務，完全由操作系統(tǒng)來平均地分配和協(xié)調(diào)內(nèi)核之間的工作。AMP架構的特征是與SMP相反，不是同等地看待每一個處理器內(nèi)核，而是把特定的任務分配給特定的內(nèi)核來運行。這樣做的好處是減少了重復性工作的相關數(shù)據(jù)切換，從而獲得較高的運行效率。
例如，你可以拿到某一款典型的多核處理器--例如Freescale T4240,它具備12個多線程的內(nèi)核，每個內(nèi)核可供2個線程來調(diào)度共享。12個內(nèi)核被分為3組，每4個內(nèi)核為一組，共享2MB的Cache。相信你已經(jīng)感覺到，這個系統(tǒng)還是挺復雜的。那么，你要讓所有的內(nèi)核都來運行單一一個OS Domain,并由它來調(diào)度所有的線程，還是把全部的計算能力劃分成多個獨立的OS Domain,各自承擔不同的任務?哪一種方案會比較好呢?實際上，這必須根據(jù)應用類型來進行取舍。這個應用在并行處理時是否足夠安全?它屬于數(shù)據(jù)密集型應用嗎?能否發(fā)揮共享Level 2 Cache所具備的優(yōu)勢，很可能是你做出判斷時應該重點考慮的一個因素。
采用內(nèi)置GPU的一組標準CPU,例如Intel Core i7,也是常用的硬件方案。這類系統(tǒng)可在4個內(nèi)核中實現(xiàn)8個超線程，并且利用GPU來實現(xiàn)復雜的通用計算。對于典型的計算密集型應用來說，盡管開發(fā)這種CPU-GPU混合異構架構會增加系統(tǒng)的復雜度，但由此帶來的性能提升仍然具有很大的吸引力，這讓我們不厭其煩地進行嘗試。
一旦理解了對應用如何進行分解，我們就有了選擇何種方法和語言來開發(fā)這個應用的依據(jù)。如果采用多操作系統(tǒng)架構，不論是SMP還是AMP,通常都必須利用共享內(nèi)存在不同OS Domain之間傳遞數(shù)據(jù)。雖然這不是僅有的方式，但卻是常用方式--把帶有一些數(shù)據(jù)的命令傳遞給某個OS Domain,然后由一個中斷程序來做出相應的處理。但是，有什么API可以使用呢?
這里有好幾種選擇。多核聯(lián)盟(Multicore Association)推出了MCAPI (Multicore Communication API)標準，如圖1所示。這是專為multi-OS環(huán)境而設計的，可以建構在相關的技術規(guī)范和MRAPI (Multicore Resource API)之上。MRAPI作為一種資源，為多OS Domain之間提供了共享內(nèi)存。
圖1:基本的多核軟件配置
對于這種架構，其他可供選擇的架構是類似的自帶專用API。無論你做出何種選擇，都希望它是便于配置和維護的，這樣才是最有利于長遠發(fā)展的最佳方案。其中一個重要的影響因素是所選接口自身的資源消耗情況。系統(tǒng)中眾多的內(nèi)核通常都是共享內(nèi)存的，其數(shù)據(jù)傳輸速度遠遠高于以太網(wǎng)。如果你把應用分割為在多個OS Domain中運行的原因之一是防止Cache Thrashing (多個線程在執(zhí)行中讀寫同一個cache line,進入競爭狀態(tài))，那么降低接口對資源的消耗占用就顯得尤為必要。[!--empirenews.page--]
對于SMP架構的編程來說，同樣有好多種選擇。在這種情況下，同一個 OS Domain內(nèi)包含了多個相同架構的CPU.選擇之一是采用操作系統(tǒng)內(nèi)部可用的線程模式。在標準線程的OS環(huán)境中，通常有多種語言可供選擇，例如：OpenMP、OpenCL和Cilk/Cilk++等。每種編程環(huán)境都有不同的語法，有些比較簡單，但提供的控制水平有所差異。相對于典型的C語言語法，有些需要擴展性的改變。有些則并不支持所有的架構，所以你需要仔細檢查所選的語言、編譯器與操作系統(tǒng)是否可以很好地相互匹配和支持。
如果你有興趣和能力將編程技藝發(fā)揮到極致，以便充分調(diào)動系統(tǒng)中的每一個“門”,可以考慮采用GPGPU (通用GPU編程，General Purpose GPU programming)。那么你需要注意到這些因素：語言、驅(qū)動程序和帶寬。GPU是專門設計用來在像素級對圖形進行操作，計算數(shù)據(jù)矢量，以及復雜的3D視圖高幀速處理。因此，它們具備針對小數(shù)據(jù)集快速進行復雜計算的能力。
驅(qū)動程序?qū)τ贕PGPU來說，絕不是無關緊要的瑣事，必須從操作系統(tǒng)方面獲得很好的支持。許多GPU提供商并不提供源代碼，因為這屬于他們知識產(chǎn)權的一部分。同時，他們通常也只是針對比較流行的操作系統(tǒng)才提供驅(qū)動程序?？赡苡行┎僮飨到y(tǒng)他們并不支持。
接下來你要考慮GPGPU語言的選擇。OpenCL出自 Khronos標準。CUDA專用于Nvidia GPU。它們都采用了類似的方法來實現(xiàn)并行編程，而性能基準測試指標則有所不同，在不同硬件環(huán)境中的表現(xiàn)有些差異。由于OpenCL是一個開放標準，所以在大多數(shù)平臺中都可以使用，它帶有編譯器，而且不需要修改代碼就可以應用于CPU與GPU混合的系統(tǒng)。這顯然是值得注意到的優(yōu)勢。
最后，遠程GPU需要處理的數(shù)據(jù)量有多大，需要經(jīng)過何種類型的總線，也會影響你的決定。越是數(shù)據(jù)密集型的應用，GPU就應該越靠近CPU。如果兩者之間必須經(jīng)過PCIe 總線，那就必須與外設分享帶寬，這很可能會使性能受到較大的影響。如果GPU與CPU比較接近，由此造成的影響會相對降低。
特別是對于消費電子產(chǎn)品來說，如可穿戴設備、移動手持設備、數(shù)字成像設備、家用網(wǎng)關以及寬帶接入等設備，面臨的一個重要挑戰(zhàn)就是以小體積、低功耗的運行環(huán)境來處理越來越大量的圖像、聲音甚至人體生理特征數(shù)據(jù)。為了針對這類運行環(huán)境在較短的時間內(nèi)開發(fā)出優(yōu)異的多核系統(tǒng)，開發(fā)平臺如何選擇就顯得尤為關鍵。
風河公司最近針對最新版的VxWorks 7實時操作系統(tǒng)推出了面向各個行業(yè)的行業(yè)領域。這些Profile針對VxWorks 7擴充了一系列非常有價值的功能，幫助客戶滿足不斷演變的市場和技術要求，從而抓住物聯(lián)網(wǎng)所帶來的新的市場發(fā)展機遇，其中就包括消費電子領域，專門針對小體積聯(lián)網(wǎng)設備，如可穿戴設備、移動手持設備、數(shù)字成像設備、家用網(wǎng)關以及寬帶接入設備等，提供快速啟動、小體積、低功耗的運行環(huán)境，還特別強調(diào)對于GPU和2D/3D圖形用戶界面的支持能力，因而可以將多核處理器的優(yōu)勢最大限度地發(fā)揮出來。
總之，在這里并不存在點石成金的魔法棒。你必須深入研究每一種架構選擇，包括硬件、軟件、語言以及編譯器，才能準確地評估每一部分對整體性能的影響，才能針對特定的算法進行最佳的優(yōu)化。一勞永逸，這在高性能計算系統(tǒng)中是不存在的，至少到目前為止是如此!
圖2:MCAPI 是一個消息傳遞應用的接口，帶有協(xié)議和語義規(guī)范，規(guī)定了其功能特性在任何應用實現(xiàn)中都必須遵循的行為規(guī)范。
下載文檔