借力標準程式設計模型　多核心軟體開發加速達陣

設計多核心處理器的嵌入式軟體需要一些特別的考量。設計多核心軟體的挑戰之一是在設計應用程式及演算法時，必須依序進行初步思考與實作。連續執行模型適用於以一顆中央處理器(CPU)執行的單核心系統，但應用程式的複雜程度已經遠超過單顆中央處理器效能所能承受的程度，因此多核心系統應運而生。

識別潛在的並行化(Parallelize)區域成為最重要的因素。在某些情況下，應用程式與演算法設計人員會手動識別這種並行化。CriticalBlue的Prism等商用工具(Commercial Tool)在過去幾年線上推出，可協助開發人員簡化複雜的應用程式與演算法等任務。

如何決定在不同核心上且是並行化區塊內最適合的映射(Mapping)，將成為開發人員必須克服的另一項挑戰。在並行化區塊及輸入/輸出(I/O)介面間的通訊要求，是此種情況下須考量的因素。區塊之間的通訊頻繁，而且選擇的多核心架構能夠有效支援通訊時，即可在不同的核心執行這些區塊。不過，當核心間的通訊成為瓶頸，而且無法改用其他有效的處理器架構時，開發人員必須重新使用分段(Segmentation)方法，找出可用的並行化策略。

圖1　利用反覆的設計程序，找出特定多核心平台的最佳設計。

多核心軟體開發挑戰多

在某些情況下，多核心軟體開發是遵循設計步驟，在其他情況下則是多核心軟體開發與設計兩者同時進行。在任何情況下，傳統的開發方法都面臨多核心處理器所形成的挑戰。

對於多核心處理器，開發團隊須要採用一般程式設計模型及資源使用慣例，因此，不同的元件可有效地使用處理器效能。過去幾年出現了如圖2所示的開放式多重處理(OpenMP)、開放式運算語言(OpenCL)及多核心應用程式設計介面(MCAPI)等程式設計模型。這些程式設計模型提供開發人員使用整合性多核心程式設計模型(Cohesive Multicore Programming Model)所需的解決方案，除了這些程式設計模型外，Linux和OSE等高階作業系統引進多核心/多重處理器程式設計的概念，其中使用Pthreads等明確界定的應用程式設計介面。

圖2　選擇正確的程式設計模型是主要的挑戰，不過能夠大幅縮短開發時間。

如圖2所示，當應用程式設計可以在主要執行緒中被劃分，使多個並行工作執行緒(Worker Threads)能在多核心獨立執行時，便極度適合OpenMP。OpenMP 3.0定義特定語言建構，能夠讓程式設計人員指示並行的起始及結束，程式設計人員也可以指示各個工作執行緒同時進行的邏輯點。

當應用程式有主要執行緒，而且需要以通稱為作業核心(Work Kernels)的高度並行實體(Highly Parallel Entities)運算工作量時，便相當適合OpenCL。典型的應用程式需要一般用途的處理器，以多核心處理器或圖形單元的高速連結執行主要執行緒。

OpenCL與OpenMP類似，會定義特定語言建構，使程式設計人員能夠指示所謂「核心」的運算區域和程式設計介面，以執行運算。OpenCL也能夠促使運算核心的持續編譯(On-the-go Compilation)，使用者得以運用預先寫入的核心，或寫入核心並立即進行原型設計。

MCAPI也能定義明確界定的介面，為多核心程式設計提供另一選擇。透過MCAPI，能夠在開發MCAPI節點方面界定開發程序。在執行階段能夠自動探索MCAPI節點，並且使用MCAPI通訊通道將這些節點相互連結。程式設計人員可依據應用程式需求，建構資料及執行流程。

某些應用程式可能找不到相符的標準程式設計模型能力，因此必須確保提供的軟體開發套件具有使用多核心處理架構的能力。

應用程式開發人員必須盡可能選擇對於應用程式最有效的最佳程式設計模型。在某些情況下，程式設計模型選擇與處理器架構息息相關，因為某些多核心架構較適合特定的程式設計模型。例如，OpenMP相當適合具共用記憶體支援的架構。

標準型開放式程式設計模型具有多項優點，包括啟用多個不同的順從性軟體區塊(Compliant Software Blocks)、簡化從某個處理器架構移植到另一個支援相同程式設計模型架構的過程，以及能夠建立開發團隊共同的開發準則，簡化開發過程。

在某些情況下，應用程式要求電路板必須有數個多核心處理器。例如，在電信方面，大量的電路板使用先進電信運算架構(ATCA)的尺寸規格。一個ATCA電路板可以裝載十多個八核心數位訊號處理器(DSP)。在這種情況下，即必須考量多核心處理器間的通訊。然而，在其他情況下，處理器可能以輸入和輸出序列RapidIO(sRIO)或乙太網路等進行通訊。

多核心軟體開發套件提供的軟體層必須確保應用程式能夠有效使用這些多核心處理器通訊介面。標準型程式設計模型已經開始注意到這些需求。

MCAPI有一個工作團隊負責擴充MCAPI，目的是使用sRIO做為實體介面，以進行數個多核心處理器間的連結及通訊。

依據定義，OpenCL不提供實體介面需求，而是依賴主機或主要處理器分配不同的核心進行運算。只要運用適當數量的處理及執行能力，即可能使得具有多個不同多核心晶片的單一主要處理器或主機成為加速器。

除了程式設計模型外，另一個重要的設計和開發挑戰，在於系統測試階段中的產品除錯和調整能力。在大多數情況下，除錯及調整都是事後才依據需求進行的工作。

目前和未來的多核心處理器都運用八個以上的核心，其具有各種高效能輸入和輸出周邊。互動的複雜性會隨著核心及共用周邊的數目而增加。

在某些多核心裝置中，如Chip Tools 4 (CTools 4)的除錯架構可用來內建(On-chip)擷取和儲存除錯，以及追蹤資訊。開發人員須要確定軟體開發套件提供適當的程式設計介面，以實現除錯及追蹤緩衝，並使用它們取得重要的除錯和效能資訊。

著手多核心軟體除錯

多核心裝置(圖3)也有自身獨特的除錯和效能挑戰，例如資源衝突與同步，這些都是單核心系統少見的挑戰。

圖3　多核心除錯特性的總體配置圖

在最基本的層面，多核心裝置仍然需要與單核心系統相同的基本除錯能力，這包括執行、停止和調整核心的能力。不過，對於多核心系統，同步載入、執行和調整所有核心的能力極度重要。

多核心系統也可能有多個功耗區域，其中包含核心和周邊的整個子系統均關閉。除錯系統必須能夠承受這些電源轉換，甚至能夠讓使用者從除錯器控制這些轉換，以便更容易測試電源相關的功能。

由於多核心系統的處理愈來愈先進，在核心間進行軟體執行緒的同步等問題，變成挑戰。藉由OpenMP和OpenCL等標準，這些軟體執行緒可以在類似或不同的核心類型上運作。這些執行緒可能使用共用資源，而會導致競用狀態及效能降低(Race Conditions and Performance Degradations)。對於會發生的同步和資源衝突加以除錯時，可提供軟體作業的多核心、時間關聯檢視的除錯子系統相當重要。

系統追蹤(System Trace)能力運用MIPI系統追蹤通訊協定(MIPI System Trace Protocol)，提供軟體開發人員硬體加速的多核心「printf」能力，這是多核心裝置除錯相當重要的工具。系統追蹤用於多核心系統時，來自各個核心的訊息會由內建系統追蹤硬體加以識別，並且全面加上時間戳記(Globally Time Stamped)，因此獲得各個核心軟體執行的裝置層級(Device Level)、時間關聯(Time-correlated)檢視。

多核心系統一般也有多層級(Multi-layered)的記憶體架構。對於除錯和優化而言，多層級記憶體架構是相當獨特的挑戰。若要優化多層級記憶體架構，除錯系統須提供開發人員必要的資料，以適度優化程式及資料配置。

例如，哪一行出現快速緩衝儲存遺失而強制記憶體子系統存取外部記憶體等資訊，有助於減少開發人員優化記憶體作業的時間。在系統層級方面，除錯子系統應該能夠提供外部記憶體介面等共用記憶體或共用介面的效能資訊。

多核心系統的整體效能可由系統介面控制，而且透過這些介面所獲取的效能資訊即可看出系統瓶頸，尤其是在這些效能資訊與軟體執行緒作業呈現時間關聯的情況下。

除了衡量效能外，了解特定核心何時存取與其他核心相關的共用資源，有助於進行資源衝突的除錯。介面效能之類的硬體事件加入系統追蹤時，開發人員即可看出時間關聯的軟體執行緒執行及硬體效能，使得軟體開發人員能夠快速找出效率不彰的問題並加以解決。

進行多核心軟體部署

開發人員的最後一個挑戰是思考產品部署，能夠確保在部署的情況下監控產品以了解產品的問題，一直是最佳的想法。透過多核心處理器，必須能夠收集追蹤而不影響正常的產品作業。在某些情況下，可以下載具有特殊儀器的軟體了解問題。

圖4顯示開發人員可以考慮選擇多核心處理器，讓軟體能夠透過網路收集和傳遞追蹤。在某些矽晶片平台中，系統追蹤監視器之類提供相關軟體開發套件的專屬矽區塊(Silicon Block)，能夠讓客戶開發可立即部署的軟體。如今，多核心處理器逐漸部署於各種應用中，這正是為何軟體開發人員必須了解多核心裝置軟體設計、開發、除錯及部署等挑戰的原因。

圖4　在部署的情況下進行遠端監控的範例

(本文作者任職於德州儀器)