本發(fā)明涉及數(shù)據(jù)傳輸技術(shù)領(lǐng)域，特別涉及一種降低數(shù)據(jù)傳輸延遲的方法及其系統(tǒng)。

背景技術(shù)：

隨著計算機體系結(jié)構(gòu)的發(fā)展，領(lǐng)域?qū)Ｓ玫挠嬎銠C體系結(jié)構(gòu)成為主要發(fā)展趨勢。在面向特定應(yīng)用時，專用型結(jié)構(gòu)利用應(yīng)用特征對結(jié)構(gòu)進行相應(yīng)的優(yōu)化，從而更好地發(fā)揮出硬件的計算性能。在高性能計算領(lǐng)域，數(shù)據(jù)流計算是領(lǐng)域?qū)Ｓ糜嬎憬Y(jié)構(gòu)的一個重要分支，數(shù)據(jù)流計算表現(xiàn)出了較好的性能和適用性。數(shù)據(jù)流指令執(zhí)行的基本原則是：所有的源操作數(shù)都準備好了，并且下游節(jié)點有空閑的數(shù)據(jù)槽可以接收數(shù)據(jù)，則該指令即可發(fā)射到執(zhí)行單元當中運算執(zhí)行。在數(shù)據(jù)流計算模式中，源指令(生產(chǎn)者，上游節(jié)點)執(zhí)行的結(jié)果不會寫入共享寄存器或共享緩存，而是直接傳遞給目的指令(消費者，下游節(jié)點)。

在傳統(tǒng)數(shù)據(jù)流架構(gòu)當中，指令之間的數(shù)據(jù)傳遞方式如圖1所示。在這個例子當中，上游節(jié)點pe3106當中的指令槽109的目的操作數(shù)字段111要傳遞給下游節(jié)點pe9101的指令槽102的源操作數(shù)字段110，并且假定上游節(jié)點pe3106的指令槽109當中的源操作數(shù)都已經(jīng)“ready”。需要經(jīng)歷的正常步驟如下：

步驟101：下游節(jié)點pe9101的指令槽102被選擇進入到發(fā)射隊列fire104當中，然后接著就可以進入執(zhí)行單元執(zhí)行；

步驟102：下游節(jié)點pe9101的指令槽102的源操作數(shù)字段110依賴于上游節(jié)點106的指令槽109的目標操作數(shù)字段111，指令槽102發(fā)射之后，通過網(wǎng)絡(luò)105通知上游節(jié)點106的指令槽109的目標操作數(shù)字段111，下游已經(jīng)“ready”，可以接收上游節(jié)點發(fā)送的源操作數(shù)數(shù)據(jù)；

步驟103：上游節(jié)點pe3106收到來自下游節(jié)點101的“ready”信息，因為指令槽109的源操作數(shù)早已經(jīng)“ready”，所以可以進入到發(fā)射隊列112當中，然后就可以進入到執(zhí)行單元116當中執(zhí)行；

步驟104：上游節(jié)點pe3106的指令槽109當中的指令在執(zhí)行單元116當中執(zhí)行結(jié)束之后，通過網(wǎng)絡(luò)117把計算結(jié)果發(fā)送給下游節(jié)點pe9101的指令槽102的源操作數(shù)字段110。

從時間軸118可以看出，最差情況下，上面描述的這些步驟是完全串行的，一環(huán)扣一環(huán)。使得節(jié)點之間傳遞操作數(shù)的延遲較大、效率較低。

技術(shù)實現(xiàn)要素：

針對傳統(tǒng)數(shù)據(jù)流結(jié)構(gòu)當中這種依賴于下游節(jié)點反饋“ready”狀態(tài)位的數(shù)據(jù)傳遞機制，本發(fā)明的目的在于提供一種優(yōu)化和降低指令之間數(shù)據(jù)傳輸延遲的方法及其系統(tǒng)。

為達上述目的，本發(fā)明采取的技術(shù)方案為：

一種優(yōu)化數(shù)據(jù)流架構(gòu)數(shù)據(jù)傳輸延遲的方法，包括以下步驟：

s1：記錄上游節(jié)點和下游中每個指令槽對應(yīng)的歷史行為，并根據(jù)所述歷史行為預(yù)測所述下游節(jié)點是否可以向所述上游節(jié)點提前發(fā)射空閑狀態(tài)信息；

s2：若所述下游節(jié)點可以向所述上游節(jié)點提前發(fā)射空閑狀態(tài)信息，則將節(jié)點中的指令槽數(shù)據(jù)存儲到預(yù)判發(fā)射部件中；所述指令槽數(shù)據(jù)中包含跳數(shù)延遲字段，用于表示上游節(jié)點的目標操作數(shù)到達下游節(jié)點的原操作數(shù)最快所需的跳數(shù)x；

s3：根據(jù)所述跳數(shù)延遲字段，下游節(jié)點在x個周期之后向上游節(jié)點發(fā)送存儲在所述預(yù)判發(fā)射部件中的指令槽數(shù)據(jù)。

根據(jù)本發(fā)明提出的優(yōu)化數(shù)據(jù)流架構(gòu)數(shù)據(jù)傳輸延遲的方法，所述預(yù)判發(fā)射部件的內(nèi)部設(shè)置存儲深度n，采用先進先出結(jié)構(gòu)存取數(shù)據(jù)。

根據(jù)本發(fā)明提出的優(yōu)化數(shù)據(jù)流架構(gòu)數(shù)據(jù)傳輸延遲的方法，所述跳數(shù)延遲字段是通過節(jié)點的坐標靜態(tài)計算而產(chǎn)生的。

本發(fā)明還同時提供一種優(yōu)化數(shù)據(jù)流架構(gòu)數(shù)據(jù)傳輸延遲的系統(tǒng)，包括：

預(yù)測位，分布在節(jié)點的每個指令槽數(shù)據(jù)中，用于記錄上游節(jié)點和下游中每個指令槽對應(yīng)的歷史行為，并根據(jù)所述歷史行為預(yù)測所述下游節(jié)點是否可以向所述上游節(jié)點提前發(fā)射空閑狀態(tài)信息；

跳數(shù)延遲字段，分布在節(jié)點的每個指令槽數(shù)據(jù)中，與所述預(yù)判發(fā)射部件相連，用于表示上游節(jié)點的目標操作數(shù)到達下游節(jié)點的原操作數(shù)最快所需的跳數(shù)x；

預(yù)判發(fā)射部件，與所述預(yù)測位和所述跳數(shù)延遲字段相連，用于當所述預(yù)測位預(yù)測所述下游節(jié)點可以向所述上游節(jié)點提前發(fā)射空閑狀態(tài)信息時，存儲所述指令槽數(shù)據(jù)；并在x個周期之后發(fā)射存儲在其中的指令槽數(shù)據(jù)。

根據(jù)本發(fā)明提出的優(yōu)化數(shù)據(jù)流架構(gòu)數(shù)據(jù)傳輸延遲的系統(tǒng)，所述預(yù)判發(fā)射部件的內(nèi)部設(shè)置存儲深度n，采用先進先出結(jié)構(gòu)存取數(shù)據(jù)。

根據(jù)本發(fā)明提出的優(yōu)化數(shù)據(jù)流架構(gòu)數(shù)據(jù)傳輸延遲的系統(tǒng)，所述預(yù)測位采用2bit飽和計數(shù)器。

根據(jù)本發(fā)明提出的優(yōu)化數(shù)據(jù)流架構(gòu)數(shù)據(jù)傳輸延遲的系統(tǒng)，所述跳數(shù)延遲字段是通過節(jié)點的坐標靜態(tài)計算而產(chǎn)生的。

與現(xiàn)有技術(shù)相比，本發(fā)明提出的方法及其系統(tǒng)能夠有效地加快操作數(shù)在數(shù)據(jù)流架構(gòu)陣列當中的傳遞效率，降低傳輸?shù)难舆t。

附圖說明

圖1為傳統(tǒng)數(shù)據(jù)流架構(gòu)當中指令之間的數(shù)據(jù)傳遞過程圖；

圖2為采用了本發(fā)明的提前發(fā)射方式之后指令之間的數(shù)據(jù)傳遞過程圖；

圖3為采用了本發(fā)明的提前發(fā)射方式之后指令之間傳遞數(shù)據(jù)的一具體實施例；

圖4為傳統(tǒng)方式和采用了本發(fā)明的提前發(fā)射方式的延遲對比圖。

具體實施方式

下面將結(jié)合本發(fā)明實施例中的附圖，對本發(fā)明實施例中的技術(shù)方案進行清楚、完整地描述，顯然，所描述的實施例僅僅是本發(fā)明一部分實施例，而不是全部的實施例?；诒景l(fā)明中的實施例，本領(lǐng)域普通技術(shù)人員在沒有付出創(chuàng)造性勞動前提下所獲得的所有其他實施例，都屬于本發(fā)明保護的范圍。

本發(fā)明提出一套優(yōu)化和降低指令之間數(shù)據(jù)傳輸延遲的方法及其系統(tǒng)，其核心技術(shù)在于非推測提前發(fā)射(non-speculativelookaheadfiringselection)模式。在本發(fā)明提出的模式當中，下游節(jié)點提前確認指令的發(fā)射日程，提前把“ready”信息通知到上游節(jié)點，這樣可以讓下游的等待發(fā)射節(jié)點和向上游反饋“ready”甚至包括上游向下游發(fā)送數(shù)據(jù)的路由時間部分重疊，從而提高了整個執(zhí)行過程的效率和減低了數(shù)據(jù)傳遞的延遲。

本發(fā)明的系統(tǒng)需要從硬件上增加如下的支持：預(yù)測、發(fā)射的提前確認和預(yù)譯碼機制。如圖2所示。

節(jié)點當中的每個指令槽都需要增加對應(yīng)的預(yù)測位用于記錄該指令槽對應(yīng)的歷史行為。如果指令槽當中的指令總是源操作數(shù)先準備好，需要等待目標操作數(shù)字段的“ready”的話，那么表示在這個指令槽當中，下游節(jié)點反饋的“ready”是這個指令槽能否發(fā)射執(zhí)行的瓶頸。這種情況對應(yīng)的預(yù)測位的結(jié)果為“taken”，反之如果指令槽能否發(fā)射執(zhí)行的瓶頸不是等待下游節(jié)點反饋的“ready”信息的話，預(yù)測位的結(jié)果為“non-taken”。之所以設(shè)置預(yù)測位，是需要根據(jù)該指令槽對應(yīng)的歷史行為決定它將來的需求。后面會進一步分析為什么這里雖然采用了預(yù)測位，但是卻并不屬于推測執(zhí)行，而是非推測的(non-speculative)。預(yù)測位的具體位數(shù)，取決于預(yù)測器的精度要求，一般推薦采用2bit飽和計數(shù)器，一方面硬件開銷小，另一方面預(yù)測精度也有一定的保障。

節(jié)點當中的發(fā)射選擇策略相比于傳統(tǒng)的方式需要做出改進。在傳統(tǒng)的數(shù)據(jù)流結(jié)構(gòu)當中，節(jié)點當中的指令槽，如果處于“readytofire”的狀態(tài)，也就是源操作數(shù)和目標操作數(shù)字段都已經(jīng)“ready”的狀態(tài)，那么就等待被選擇發(fā)射執(zhí)行即可。在本發(fā)明當中，需要知道一個指令槽如果處于“readytofire”的狀態(tài)，最快幾個時鐘周期之后可以被發(fā)射執(zhí)行。比如圖2所示，針對下游節(jié)點pe9201,為了實現(xiàn)這樣的功能，在原來傳統(tǒng)結(jié)構(gòu)的發(fā)射選擇部件205的前面增加了預(yù)判發(fā)射部件prefireq204。預(yù)判發(fā)射部件204內(nèi)部設(shè)置一定的深度n，采用fifo的結(jié)構(gòu)，先進先出。那些將要被發(fā)射的指令從預(yù)判發(fā)射部件204的fifo當中被順序取出。所以，發(fā)射預(yù)判部件204的深度n就決定了這個節(jié)點可以對指令的發(fā)射預(yù)判n個cycle。因為只有那些被發(fā)射放入到預(yù)判發(fā)射部件當中的指令一定會在0～m個cycle之后被發(fā)射執(zhí)行(最快是0～n，因為有些指令所需要的執(zhí)行周期不止需要1個cycle，并且還考慮到有阻塞型的計算部件，所以最好情況是進入到預(yù)判發(fā)射部件之后，1個cycle都不浪費就一步一步進入到執(zhí)行單元當中)。

節(jié)點當中的每個指令槽都需要增加“hopdelay”字段，指令槽的每個源操作數(shù)對應(yīng)具有各自的“hopdelay”字段。該字段的含義表示源操作數(shù)字段所在的pe和它所依賴的上游節(jié)點之間的距離，即上游節(jié)點的目標操作數(shù)最快需要經(jīng)過多少跳數(shù)到達下游節(jié)點的源操作數(shù)字段。該字段可以通過節(jié)點的坐標靜態(tài)計算產(chǎn)生，為了不影響節(jié)點內(nèi)流水線的效率和延遲，在指令被寫入到節(jié)點之前，增加一個預(yù)譯碼部件226，用于靜態(tài)計算每條指令的源操作數(shù)字段對應(yīng)的“hopdelay”字段，存儲該字段所需要的位數(shù)和數(shù)值取決于數(shù)據(jù)流計算陣列當中的節(jié)點分布、節(jié)點數(shù)和路由方式。如圖3當中所示的結(jié)構(gòu)，該數(shù)據(jù)流結(jié)構(gòu)當中包括16個節(jié)點301-316，采用4行4列的結(jié)構(gòu)(圖中的pe是processingelement的縮寫，表示數(shù)據(jù)流結(jié)構(gòu)當中的處理和計算核心)。路由假定采用最簡單的xy路由。那么如果節(jié)點313當中有某一條指令有兩個源操作數(shù)字段，分別來自節(jié)點301和節(jié)點303當中的指令槽的目標操作數(shù)字段，分別如圖中的實線箭頭和虛線箭頭所示，數(shù)據(jù)從節(jié)點303傳遞到節(jié)點313的話，最快需要5跳到達；數(shù)據(jù)從節(jié)點301傳遞到節(jié)點313的話，最快需要3跳到達。所以，這條指令的兩個源操作數(shù)對應(yīng)的“hopdelay”字段的數(shù)值分別是3和5。因為在數(shù)據(jù)流架構(gòu)當中，指令當中的操作數(shù)字段都包含了靜態(tài)映射的坐標信息，所以在指令真正執(zhí)行之前，就可以在預(yù)譯碼的階段計算出每個源操作數(shù)的“hopdelay”信息。

以圖3為例，假定在數(shù)據(jù)流結(jié)構(gòu)每個節(jié)點當中的預(yù)判發(fā)射部件prefireq的深度是5，如317和318所示，每個節(jié)點都有自己的預(yù)判發(fā)射部件prefireq，每個prefireq有5項，每一項的索引分別是1～5。設(shè)置隊尾指針，指向下一個要進入預(yù)判發(fā)射部件prefireq的請求寫入的位置。每次一條指令要發(fā)射的時候，都是從第1項被發(fā)射。每次有一條指令被發(fā)射出去之后，整個預(yù)判發(fā)射部件prefireq進行移位操作，向索引為1的位置移動，如圖3中所示就是向下移動。圖3當中338表示了在節(jié)點313當中一條指令進入到預(yù)判發(fā)射部件prefireq的處理過程。

在本實施例當中，假定節(jié)點313當中的一個指令槽具有2個源操作數(shù)字段和1個目標操作數(shù)字段。節(jié)點313的兩個源操作數(shù)分別來自節(jié)點301和節(jié)點303，根據(jù)前面的解釋，來自節(jié)點303的源操作數(shù)的”hopdelay“是5,來自節(jié)點301的源操作數(shù)的“hopdelay“是3。

那么在節(jié)點313當中，指令的處理過程如下面的步驟所示：

步驟301：節(jié)點313當中的這條指令已經(jīng)處于“ready“狀態(tài)，即本次計算所得的源操作數(shù)已經(jīng)準備好，并且目標操作數(shù)也收到了來自下游節(jié)點的”ready“狀態(tài)；那么該條指令進入到節(jié)點313的prefireq當中索引等于5的位置，如預(yù)判發(fā)射部件的指令槽322所示。(注：本實施例假定預(yù)判發(fā)射部件prefireq的前4項已經(jīng)被占滿，如果前面為空，那么該指令進入的位置不是322)。

步驟302：如圖中預(yù)判發(fā)射部件prefireq的322所示，需要保存的內(nèi)容為：指令對應(yīng)在該節(jié)點當中的instructionindex，本例子當中是27；每個源操作數(shù)對應(yīng)的”hopdelay“，在本實施例當中分別是3和5。

步驟303：因為指令進入到預(yù)判發(fā)射部件prefireq的第5項，表明這條指令將在5個cycle之后被發(fā)射到節(jié)點313的發(fā)射部件和執(zhí)行單元。此時源操作數(shù)1的“hopdelay“等于指令在預(yù)判發(fā)射部件prefireq當中所處的位置5，所以，從節(jié)點313向節(jié)點303反饋該源操作數(shù)字段的”ready“信息。表明，5個cycle之后，源操作數(shù)1字段322將會空閑出來，同時節(jié)點303收到了“ready“信息，可以在5個cycle之后就向節(jié)點303發(fā)送下一次的數(shù)據(jù)。這樣做可以讓節(jié)點303比傳統(tǒng)的方式提前50％的時間收到來自下游節(jié)點的“ready”信息，從而減少了操作數(shù)的傳輸延遲。

步驟304：對于節(jié)點313當中的instructionindex＝27的這條指令的另外一個源操作數(shù)字段，也是同樣的道理，隨著預(yù)判發(fā)射部件prefireq當中的指令被發(fā)射出去，該指令將在2個cycle之后進入到prefireq的第3項329當中，此時源操作數(shù)字段0的“hopdelay”等于3，那么節(jié)點313向節(jié)點301發(fā)送來自下游的”ready“信息。同樣，節(jié)點301收到下游節(jié)點的“ready“信息的延遲將比原來快50％的時間。

圖4表示了傳統(tǒng)方式和“non-speculativelookahead”方式的對比。圖中左邊401表示了采用傳統(tǒng)方式的延遲，圖中右邊402表示了采用“non-speculativelookahead”方式的延遲。圖中表示的步驟沒有考慮網(wǎng)絡(luò)發(fā)生擁堵的情況，示意的是在一般理想情況下的傳輸情況，如果發(fā)生了網(wǎng)絡(luò)擁堵，實際情況下會比圖中表示的延遲更大，取決于擁堵造成的延遲cycle數(shù)的多少。

如圖4，在傳統(tǒng)方式中，如419所示，pe(3,0)(即圖3的313)在cyclen+11的時候才能收到來自節(jié)點pe(0,2)(即圖3的303)和pe(0,0)(即圖3的301)的2個源操作數(shù)，才能開始啟動下一次的發(fā)射。但是如果采用“non-speculativelookahead”方式的話，如432所示，pe(3，0)(即圖3的313)在cyclen+7的時候，就可以收到來自節(jié)點pe(0,2)(即圖3的303)和pe(0,0)(即圖3的301)的2個源操作數(shù)，就可以開始啟動下一次的發(fā)射。圖4當中兩邊的n都是相等的情況下。

可以看出本發(fā)明提出的方法和機制有效地加快了操作數(shù)在數(shù)據(jù)流架構(gòu)陣列當中的傳遞效率，降低了傳輸?shù)难舆t。

本實施例當中給出的例子給每個節(jié)點的預(yù)判發(fā)射部件prefireq只設(shè)置了5項，如果在硬件資源的允許的條件下，預(yù)判發(fā)射部件prefireq的項數(shù)可以增加的話，那么可以掩蓋更多的數(shù)據(jù)傳輸延遲。如圖3的例子所示，如果預(yù)判發(fā)射部件prefireq的項數(shù)等于10的話，指令instructionindex＝27在進入到prefireq的第10項的時候，就可以向節(jié)點303發(fā)出來自下游節(jié)點的“ready”信息。表示在10個cycle之后，節(jié)點313的這條指令發(fā)射，同時來自上游節(jié)點303的源操作數(shù)也就位，就可以開啟下一輪的發(fā)射等待和計算。具體的實現(xiàn)方式取決于硬件和性能之間的平衡。

之所以把本發(fā)明提出的機制成為“non-speculative”，是因為上游節(jié)點仍然需要確認收到來自下游的“ready”信息才能將數(shù)據(jù)送出，不存在speculative的情況發(fā)生。之所以增加了預(yù)測位，是為了篩選出那些需要被優(yōu)化的指令進行，針對那些本來下游“ready”就不是瓶頸的指令來說，不需要采用這種優(yōu)化方式，不會浪費預(yù)判發(fā)射部件當中資源。

本領(lǐng)域普通技術(shù)人員可以理解：附圖只是一個實施例的示意圖，附圖中的模塊或流程并不一定是實施本發(fā)明所必須的。

本領(lǐng)域普通技術(shù)人員可以理解：實施例中的裝置中的模塊可以按照實施例描述分布于實施例的裝置中，也可以進行相應(yīng)變化位于不同于本實施例的一個或多個裝置中。上述實施例的模塊可以合并為一個模塊，也可以進一步拆分成多個子模塊。

最后應(yīng)說明的是：以上實施例僅用以說明本發(fā)明的技術(shù)方案，而非對其限制；盡管參照前述實施例對本發(fā)明進行了詳細的說明，本領(lǐng)域的普通技術(shù)人員應(yīng)當理解：其依然可以對前述實施例所記載的技術(shù)方案進行修改，或者對其中部分技術(shù)特征進行等同替換；而這些修改或者替換，并不使相應(yīng)技術(shù)方案的本質(zhì)脫離本發(fā)明實施例技術(shù)方案的精神和范圍。