并行計算有助于應(yīng)用和資源管理的合理化,但是為此方案找到找到合適的中間件卻是很棘手的問題。Tom Nolle解釋了應(yīng)該尋找什么。
一些計算功能跟流程綁定得如此緊密,以至于如果可以(在處理器內(nèi)核之間、CPU與GPU之間甚至跨系統(tǒng)邊界)有效共享的話就可以獲得極大的好處。并發(fā)性一直都是通過多線程、同步以及鎖定技術(shù)來支持的,但現(xiàn)在有了中間件工具以后可以讓并發(fā)更容易實現(xiàn)。為了選出最好的,你需要理解你的并發(fā)編程應(yīng)用的需求,考慮應(yīng)用的來源和方向,最后還要了解一些政治的并行處理語言,即便你并不認為自己需要這樣的語言。
大多數(shù)業(yè)務(wù)流程最好是評估為一組過程或者步驟,其后者往往要取決于前面的過程或步驟的結(jié)果。這種線性的方案幾乎歸納了所有現(xiàn)代軟件開發(fā)的特點,編程語言和中間件工具已經(jīng)為此進行了優(yōu)化演進。
一些包括了復(fù)雜的流程和計算的應(yīng)用可以利用傳統(tǒng)的工具和語言開發(fā),但也可以受益于用額外系統(tǒng)、處理器或者內(nèi)核的形式分配多個并行處理資源。對這些流程的優(yōu)化支持需要為并行流程的同步提供安身之處,以確保數(shù)據(jù)在可用之前不會被使用或者流程不會在資源使用中發(fā)生沖突。鎖和信號量是并發(fā)性的固定裝置,但是很難調(diào)試,在伸縮性方面受限。
并發(fā)模型由何構(gòu)成?并行計算的挑戰(zhàn)之一是確定“并行”究竟是什么意思。一些人認為任何形式的并發(fā)性支持就是并行編程,這樣的話網(wǎng)格或集群計算以及多實例云和微服務(wù)應(yīng)用都算是。有的則認為這種模型應(yīng)該泛化到包括任何形式的跨并行資源的任務(wù)分布。考慮的出發(fā)點之一是隨著時間轉(zhuǎn)移會出現(xiàn)更多的并行選項,所以把自己限定在任何受限模型之內(nèi)也許不是明智之舉。
結(jié)果證明,使用并行編程的大多數(shù)機會都與特定算法的實現(xiàn)以及可用更高級語言聲明的算法有關(guān)。如果該語言的解釋以及結(jié)果代碼的執(zhí)行是由中間件管理的話,那它天生就是資源敏捷且并發(fā)友好的,就有可能避免一切傳統(tǒng)的并發(fā)問題。
即便是更高級的語言—所謂的“非過程性”語言—也可用為并行編程模型框定起點。因為這些語言表達的上意圖而不是過程,這些是可用語言處理器而不是靠開發(fā)者來并行化的。這說明了一條普遍事實:語言越高級,程序的并行化越容易—只要有合適中間件的話。反之,如果使用了更低級的過程性編程模型,那模型就不得不從目前的概念、包括哪些現(xiàn)在用來支持并發(fā)線程的概念進行演變,以便優(yōu)化性支持并行選項。
確定模型所有的并行編程都應(yīng)該從用什么語言開始,有半打的基本模型可以確定語言。第一種并行模型優(yōu)化了當前語言并引入了并發(fā)性的概念。最新的模型比如X10,是專門用來進行一般化的并行編程的。別的像Smalltalk和LINQ屬于非過程性的,適合于并行編程,如果使用合適的中間件的話。
集群和網(wǎng)格計算中間件工具,甚至RESTful API以及微服務(wù)也可以使用Java、C#、MPI、PALM等語言來開發(fā)“并行”應(yīng)用,Active Message中間件(全部都是開源的)在大多數(shù)支持并發(fā)開發(fā)的語言中都可以使用。還有一些是針對Java、C#、C++等特定語言的中間件工具。這些模型更容易采用,但很難讓并行性支持多核或者多選題網(wǎng)格這樣的一般事情。開發(fā)者可能還會發(fā)現(xiàn)顯式任務(wù)同步的需求很難實現(xiàn)。
微軟的LINQ和PLINQ就是從傳統(tǒng)應(yīng)用向并行計算演進的一般模型的例子。LINQ有助于定義表示計算模型而不是計算方法的算法。PLINQ是一款.NET中間件工具,這個工具可以管理這些算法的并行執(zhí)行,這樣應(yīng)用就可以開發(fā)為將算發(fā)性要素從過程部分分離出來。Java 8也有類似的能力,因為它采用了Streams和一種合適的數(shù)據(jù)庫模型。高性能Fortran (High-Performance Fortran)是一種支持并行處理的算法型語言。
這些方案還是需要開發(fā)者適應(yīng)并行性,要么通過在編程中樹立意識,要么要做算法處理中隱藏好它。由IBM發(fā)起作為開源項目開發(fā)的X10語言側(cè)采取了不同的辦法。它通過創(chuàng)建圍繞著place以及異步任務(wù)這樣的新概念開發(fā)的并行友好型過程性編程模型修改了“過程性”編程的概念。跟非過程性方案不一樣的是,X10讓開發(fā)者開發(fā)和管理并行性而不是隱藏它。
考慮你的目標并行編程路徑的數(shù)量令人眼花繚亂,很可能還會變得更加復(fù)雜。對于開發(fā)團隊而言,考慮的關(guān)鍵是應(yīng)用的來源和方向。如果你進行的是傳統(tǒng)的商業(yè)化編程,希望給特定的算法處理增加并行支持的話,那可以看看針對特定語言的并發(fā)性中間件或者PLINQ。如果你更關(guān)心并行性而不是集群(網(wǎng)格)計算或微服務(wù)的話,把前者看成是基本方案。后者用來針對一般的并行化。
作為要素,開發(fā)的方向更難考慮進并行編程規(guī)劃里面,這僅僅是因為很難知道有哪些選項。業(yè)界的一般硬件趨勢正朝著每處理器內(nèi)核數(shù)量更高、每小題處理器更多的方向發(fā)展。從更高的層面來說,這股趨勢正朝著組件化以及計算、存儲和網(wǎng)絡(luò)功能分離的方向發(fā)展。即便中間件也日益被視為“服務(wù)”,系統(tǒng)展示的只是非常輕量的操作系統(tǒng),并匯總微服務(wù)之類的平臺功能。
這一基本事實是的像X10之類的東西成為合理選擇。X10有一個基于Eclpse的開發(fā)環(huán)境,為了方便執(zhí)行框架是用Java編寫的。X10社區(qū)有著很好的文檔和向?qū)В瑢τ谌魏斡媱澥褂貌⑿芯幊棠P偷慕M織來說,花點時間學(xué)習(xí)這門語言并理解在系統(tǒng)—集群層次對并行性的適應(yīng)會影響到語言結(jié)構(gòu)和中間件工具是明智的。要想充分意識到一門看不見的技術(shù)之潛能總是很困難的,并行相關(guān)的開發(fā)最終也會證明這一點。