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