Helium 技術講堂 | 數(shù)獨、寄存器和相信的力量
當人工智能 (AI) 下沉到各式各樣的應用當中,作為市場上最大量的物聯(lián)網(wǎng)設備也將被賦予智能性。Arm ? Helium? 技術正是為基于 Arm Cortex ? -M 處理器的設備帶來關鍵機器學習與數(shù)字信號處理的性能提升。
本文引用地址:http://butianyuan.cn/article/202406/460299.htm在上周的 Helium 技術講堂中,大家了解了 Helium 技術的核心“節(jié)拍式”執(zhí)行 。 今天,我們將共同探討一些復雜而又有趣的交錯加載/存儲指令。 若您想要了解如何高效利用 Helium,千萬別錯過文末視頻,通過 Arm 技術專家的實例演示,詳解 Helium 如何為端點設備引入更多智能。
作者:Arm 架構與技術部 M 系列首席架構師兼研究員 Thomas Grocutt
DSP 處理中一個重要部分就是對不同的數(shù)據(jù)格式進行高效處理,這些數(shù)據(jù)格式通常需要轉(zhuǎn)換成不同的排列方式進行計算。圖像數(shù)據(jù)就是一個很好的例子,它通常以紅、綠、藍和 alpha 像素值交錯流的形式被存儲。但是,為了將計算矢量化,就需要將所有紅色像素放在一個矢量中,綠色像素放在另一個矢量中,以此類推。在 Neon 架構中,VLD4/VST4 指令可以執(zhí)行這種轉(zhuǎn)換,如下圖所示。
VST4 將四個 128 位寄存器交錯排列,共存儲 512 位數(shù)據(jù)。Neon 架構有多種交織/去交織運算,可支持不同的格式。例如,提供的 VST2 可用于交織立體聲音頻的左右聲道。這些指令還支持從 8 到 32 位不等的元素大小。
MVE 的“節(jié)拍式”執(zhí)行的主要優(yōu)點之一,是它允許內(nèi)存和 ALU 運算重疊,即使在單發(fā)射處理器上也是如此。 如下圖所示,基于此技術要實現(xiàn)性能的翻倍,所有指令必須執(zhí)行相同的工作量。
顯而易見,重疊帶來的性能提升會因 VST4 這樣的寬存儲指令而大打折扣。 MVE 提供的解決方案是將存儲空間分割成與 ALU 運算相平衡的塊,每個塊存儲 128 位數(shù)據(jù)。 MVE 允許由 VST40、VST41、VST42 和 VST43 這四條指令構成四路交織。但到此并未結(jié)束,仍有不少問題存在:
顯而易見的拆分方法是讓四條指令分別存儲不同的數(shù)據(jù)流(例如 VST40 存儲所有紅色像素,VST41 存儲綠色像素等)。對于 8 位像素數(shù)據(jù),這意味著每條指令將存儲 16 個非連續(xù)字節(jié)。這種訪問模式對內(nèi)存子系統(tǒng)來說非常復雜,會導致大量停滯。相反,指令需要生成大塊連續(xù)請求。
要正確配合其他矢量指令,必須將寄存器文件端口設置為訪問寄存器文件的行(即整個矢量寄存器),而不是列(即四個寄存器的第一個字節(jié)),如果要將數(shù)據(jù)交織存儲到連續(xù)內(nèi)存塊中,則需要訪問列。
為了避免我在上一篇內(nèi)容中描述的時間跨越問題,我們需要將指令分成幾個“節(jié)拍”,先讀取寄存器的 [63:0] 位,然后在下一個周期讀取 [127:64] 位。
解決方案必須同時適用于兩路交織和四路交織,以及 8、16 和 32 位數(shù)據(jù)運算。
面對所有這些相互矛盾的限制,我們就像掉進了兔子洞,我不禁想起了《愛麗絲夢游仙境》中的情節(jié):
愛麗絲:這是不可能的。
瘋帽匠:只要你相信,一切皆有可能。
所以,讓我們暫且放下懷疑的態(tài)度,仔細研究一下讀取端口,看看會發(fā)生什么。
MVE 重復使用浮點寄存器文件,因此矢量寄存器(Q0 至 Q7)由每四個一組的若干組 “S” 寄存器組成。每個列多路復用器選擇相同的行,然后將數(shù)據(jù)合并以訪問整個 Q 寄存器(見上圖)。但是,如果不能從一列中的任何寄存器中選擇,而是將端口扭曲,從交替列中的寄存器中選擇,如下圖所示,會如何呢:
如果 8:1 多路復用器上的控制輸入設置為相同值,則可讀取一行數(shù)據(jù)(例如 S0 和 S1)。但是,如果使用不同的值,則可以讀取一列中的一對值(如 S0 和 S4)?,F(xiàn)在看起來似乎可行,我們能夠從列和行中讀取數(shù)據(jù)。如果我們把圖的下面放大,并將寄存器編號替換為它們所連接的多路復用器的編號,就會得到下圖結(jié)果:
這類似于一道簡單的數(shù)獨謎題,在重復矩陣的每一行和每一列中,每個數(shù)字只會出現(xiàn)一次,只不過這個矩陣是 2 x 2 的,而不是平常的 9 x 9。由于只能從一列中讀取兩個值,并且只能處理 32 位值(多路復用器的寬度),因此這種模式只能提供兩路交織的解決方案。由于我們需要一種可處理所有交錯模式和數(shù)據(jù)寬度組合的模式,因此可想象將所有組合垂直堆疊起來,得到一個多分辨率的三維數(shù)獨謎題。解決一層謎題輕而易舉,但解決整個三維謎題的過程一定令人嘆為觀止。此外,我們還需要考慮上文提到的其他限制因素,如連續(xù)內(nèi)存訪問,以及在不同周期內(nèi)拆分對寄存器上下 64 位的訪問。
經(jīng)過一番思索,我意識到可以將問題一分為二:一是確定一種可在單個統(tǒng)一的問題空間中表示全部約束的方法,二是解決這些約束的單調(diào)任務。由于該模式類似于一個非常復雜的數(shù)獨問題,而許多數(shù)獨程序都是基于 SAT 解算器的,因此我產(chǎn)生了使用 SAT 解算器來完成單調(diào)約束求解任務的想法。經(jīng)過努力,我想出了一種能表示所有約束的方法,一番調(diào)試后,第一個可行的解決方案誕生了。雖然它不完善,而且會導致多路復用器的控制邏輯難以實施,但至少勝利在望了。由于不想對解決方案進行手動清理,我們添加了一些額外的約束條件,引入了一些對稱性,并產(chǎn)出了最終的解決方案,它竟然是一對雙嵌套四重螺旋結(jié)構:
為了讓大家看到嵌套的螺旋線,我在下圖中標注了單個多路復用器的路徑。如圖所示,路徑每行交替通過 32 位 “S” 寄存器(如左圖所示),每兩行交換通過 “S” 寄存器上下兩半 16 位區(qū)域(如右圖所示)。
直覺告訴我,這種扭曲的方法對于三路交織來說是行不通的,經(jīng)證實我是對的,SAT 解算器正式證明無解。
這種扭曲方法意味著可以同時訪問寄存器文件行和列中的數(shù)據(jù)。但問題在于,讀取端口返回的字節(jié)可能順序有誤,而順序取決于訪問的寄存器。要糾正此情況,就需要使用一個交叉多路復用器,將一切交換回正確的位置。由于如 VREV 等其他指令和復數(shù)原生操作指令會用到交叉多路復用器,所以我們正好能免費使用它。這正印證了那句話:“如果你必須使用一個硬件,請物盡其用?!?/p>
下圖顯示了由讀取端口扭曲模式衍生出的一些指令訪問模式。第一種情況 (VST2n.S32) 顯示從矢量寄存器 Q0 和 Q1 讀取 32 位 (S32),并將其兩路交織(如左右音頻通道)。圖中顏色代表兩條指令分別讀取的寄存器部分(即 VST20 讀取橙色部分),元素中的文字表示內(nèi)存中存儲的字節(jié)偏移。
可以發(fā)現(xiàn),上述 S8 和 S16 模式都將相同的數(shù)據(jù)放在寄存器的相同顏色區(qū)域內(nèi);唯一不同的是每節(jié)中字節(jié)的排列方式。這意味著, 只需在交叉多路復用器中使用不同的配置,16 位模式也能支持 8 位。 這些模式也適用于加載指令所使用的寫入端口。除了可以建立寄存器文件端口外, 這些模式還意味著內(nèi)存訪問始終是一對 64 位的連續(xù)塊,這樣可以提高內(nèi)存訪問的效率。 另外,這些數(shù)據(jù)塊地址的第 [3] 位總是不同的, 因此可以在擁有兩組交織 64 位內(nèi)存的系統(tǒng)上并行發(fā)送。
研究團隊從這些指令中積累了兩條重要的經(jīng)驗。 首先,要想在 gate 數(shù)量和效率方面取得突破式進展,就必須在設計架構的同時對微架構的細節(jié)同步思考設計。其次,要保持信念,相信一切皆有可能。
我們將在下一篇 Helium 文章中繼續(xù)探討以內(nèi)存訪問為主題的相關內(nèi)容,并介紹一些實現(xiàn)循環(huán)緩沖的技術知識。持續(xù)關注 Helium 技術講堂,我們下期再見!
評論