如上所述采用查詢表架構(gòu)和文檔流格式，實際的查詢和評分系統(tǒng)（圖 3）會非常直接。我們只需掃描輸入流以檢查報頭和腳注字即可。報頭字將文檔得分設(shè)為 0，而腳注字則收集并輸出文檔得分。對于文檔中的每四個配置文件詞，Bloom 過濾器首先丟棄否定詞結(jié)果，再從 SRAM 讀取四個配置文件詞。并行計算并添加（圖 4）每個詞的得分。實際上，四分之三的配置文件詞 ID 不會匹配于文檔詞 ID；只對第四個進(jìn)行實際計算。將文檔中所有詞的得分進(jìn)行累加，最后得分流在輸出到主機(jī)存儲器之前與限值進(jìn)行比較過濾。

主機(jī)—FPGA 接口將文檔流從存儲器緩沖器中傳輸至 FPGA，并將得分流返回至客戶端中。一旦從客戶端接收到配置文檔 ID 表，子進(jìn)程即從主進(jìn)程中分叉出來，以構(gòu)建實際的配置文件，將其載入 SRAM 并在 FPGA 上運(yùn)行算法。每個子進(jìn)程都會產(chǎn)生一個獨(dú)立的輸出線程，以對從 FPGA 獲得的得分進(jìn)行緩沖，并通過 TCP/IP 將這些得分傳輸?shù)娇蛻舳?，從而使用網(wǎng)絡(luò)對得分流進(jìn)行多路復(fù)用。若沒有該線程，網(wǎng)絡(luò)吞吐量的波動就會降低系統(tǒng)性能。這種主機(jī)接口架構(gòu)的主要優(yōu)勢在于，它具有很高的可擴(kuò)展性，能輕松滿足大量 FPGA 的需求。

大幅度提速

為了評估 FPGA 加速型過濾應(yīng)用的性能，我們進(jìn)行了一系列實驗，將基于 FPGA 的實施方案與采用 C++ 編寫的運(yùn)行于 Altix 之上的優(yōu)化參考實施方案進(jìn)行了比較。在比較過程中，我們使用了三個 IR 測試集合（參見表 1）：一個是文本檢索會議 (TREC) 提供的基準(zhǔn)參考集合 TREC Aquaint，還有兩個分別是美國專利與商標(biāo)署 (USPTO) 和歐洲專利署 (EPO) 提供的專利集合。我們選擇上述測試集合來評估不同文檔長度和大小對過濾時間的影響。

表 1——集合統(tǒng)計

為了仿真眾多不同的過濾器，我們通過選擇隨機(jī)文檔并用標(biāo)題作為請求，隨后再選擇請求服務(wù)器返回的固定數(shù)量的文檔作為偽相關(guān)文檔，來為每個測試集合構(gòu)建配置文件。我們接下來使用返回的文檔構(gòu)建相關(guān)性模型，該模型定義了文檔集合中每個文檔應(yīng)當(dāng)匹配（就好像從網(wǎng)絡(luò)進(jìn)行流處理一樣）的配置文件。配置文件中的文檔數(shù)量從 1 到 50 不等，可確定增加配置文件的大小（詞數(shù)和文檔數(shù)）會對性能有何影響。我們將上述進(jìn)程重復(fù) 30 次，并計算平均處理時間。

我們在表 2 和圖 5 中對有關(guān)結(jié)果進(jìn)行了總結(jié)。從表中可以清晰地看出，F(xiàn)PGA 實施方案在速度方面通常比標(biāo)準(zhǔn)實施方案快一個數(shù)量級。從圖中可以看出，配置文件大小（需要匹配的詞數(shù)）增加后，標(biāo)準(zhǔn)實施方案變得越來越慢，而 FPGA 實施方案的速度相對保持不變。這是因為 FPGA 實施方案支持配置文件評分的流分線操作，這樣無論配置文件大小如何，時延基本保持不變。

這些結(jié)果清晰表明，F(xiàn)PGA 對加速 IR 任務(wù)有著巨大的潛力。FPGA 的提速幅度已然相當(dāng)大（特別對大型配置文件而言尤其明顯），而且仍有進(jìn)一步提高的空間。通過仿真，我們確認(rèn) FPGA 算法給一個文檔詞評分需要兩個時鐘周期。制約因素為每周期 128 位的 SRAM 存取速度，這需要兩個周期才能讀取四個配置文件詞。如果時鐘速度為 100 MHz，則意味著 FPGA 能在 15 秒之內(nèi)完成整個 EPO 文檔集合的評分。當(dāng)前應(yīng)用在四個 FPGA 上需要約 8.5 秒，因此原則上我們至少可以讓性能再翻一番。

差異的原因在于 I/O 流 (streaming I/O)：通過主機(jī)操作系統(tǒng)設(shè)備驅(qū)動器可將文檔流從用戶存儲器空間傳輸至 NUMAlink，這需要直接存儲器存取 (DMA) 傳輸。驅(qū)動器可傳輸流的緩存模塊。目前，對所傳輸模塊的大小來說，這一傳輸并不是以最優(yōu)的方式實施的，進(jìn)而導(dǎo)致無法達(dá)到最高吞吐量。此外，用獨(dú)立的線程進(jìn)行傳輸排序也能避免傳輸時延。

遇到的問題和吸取的經(jīng)驗

這一項目的意義不僅在于它展示了 FPGA 作為信息檢索任務(wù)加速器的優(yōu)勢，而且還為我們提供了 FPGA 加速系統(tǒng)軟硬件要求的重要信息。

至主機(jī)系統(tǒng)的 I/O 是確保性能的關(guān)鍵：NUMA 存儲器與 FPGA 之間的 DMA 機(jī)制必須獲得 Mitrionics SDK 和 SGI RASClib 的支持。在此前的項目中，我們必須先將數(shù)據(jù)傳輸?shù)诫娐钒迳系?SRAM 中才能進(jìn)行處理，但這會嚴(yán)重影響性能，因為數(shù)據(jù)的載入和結(jié)果的卸載會造成非常大的開銷。此外，我們也清晰地認(rèn)識到，IR 任務(wù)尤其需要大量的片上和板上存儲器，才能實現(xiàn)效率最大化。

此外，為了充分使用 FPGA，未來的平臺必須具備兩個重要特性，一是必需能在 FPGA 之間直接傳輸數(shù)據(jù)，二是必需能夠關(guān)閉主機(jī)處理器（或用一個主機(jī)處理器控制多個 FPGA）。關(guān)閉主機(jī)處理器的功能尤其重要：在 Altix 平臺上，即便 Itanium 處理器完全處于空閑狀態(tài)也不能關(guān)閉。但是，空閑的 Itanium 處理器的功耗也高達(dá)工作狀態(tài)下所需功耗的 90%。因此，盡管 FPGA 加速的節(jié)能效果明顯，但我們目前的系統(tǒng)即便在加速器運(yùn)行過程中主機(jī)存儲器空閑狀態(tài)下，其總體節(jié)能作用仍然有限。

開發(fā) FPGA 加速型系統(tǒng)的另一重要領(lǐng)域就是軟件。我們的經(jīng)驗明確反映出，主要的復(fù)雜問題在于FPGA 和主機(jī)系統(tǒng)之間的接口連接：Mitrion-C 中的實際 FPGA 應(yīng)用開發(fā)效率非常高；采用 Lemur 工具套件構(gòu)建查詢和服務(wù)文檔的框架也相對容易開發(fā)。但是，采用 RASClib 開發(fā)連接主機(jī)應(yīng)用和FPGA 接口的代碼非常復(fù)雜，而且由于并發(fā)性問題，還非常難以調(diào)試。因而，接口代碼的開發(fā)占據(jù)了絕大部分的開發(fā)時間。

表 2 —— 性能統(tǒng)計數(shù)據(jù)

圖 5 —— 時間（秒）和配置文件中文檔數(shù)量的對比圖

FPGA 高級編程的最后一個問題是編譯速度。習(xí)慣于 C++ 或 Java 等語言的開發(fā)人員認(rèn)為即便應(yīng)用非常復(fù)雜，構(gòu)建時間也應(yīng)該比較短。除了最基本的設(shè)計之外，當(dāng)前的 FPGA 工具執(zhí)行綜合以及放置路由工作幾乎都需要一整天的時間。非常長的構(gòu)建時間會嚴(yán)重影響工作效率，因而時間應(yīng)當(dāng)縮短到一般性軟件構(gòu)建時間，這樣才能使 FPGA 加速更具吸引力。

定制硬件平臺

我們用這個項目探討了 FPGA 加速的可能性，并展示了 FPGA 作為數(shù)據(jù)中心綠色環(huán)保技術(shù)的巨大潛力。我們希望進(jìn)一步擴(kuò)展這項研究，調(diào)查文檔處理所需的全系列工作任務(wù)，如語法分析、詞干、索引、搜索以及過濾等。我們清楚地認(rèn)識到，現(xiàn)有系統(tǒng)在節(jié)能潛力方面很有限，我們希望研究能以業(yè)界最高效率專門執(zhí)行信息檢索任務(wù)的可定制硬件平臺。這樣，我們就能顯著加速算法的執(zhí)行，同時大幅度降低能耗，從而開發(fā)出更加環(huán)保、速度更快的數(shù)據(jù)中心。