簡體   English   中英

您可以使用程序集直接訪問緩存嗎?

[英]Can you directly access the cache using assembly?

緩存是提高效率的核心。

我知道緩存通常會自動發生。

但是,我想自己控制緩存的使用,因為我認為我可以比一些不知道確切程序的啟發式方法做得更好。

因此,我需要匯編指令來直接移入或移出緩存 memory 單元。

喜歡:

movL1 address content

我知道有一些指令會給出“緩存系統”提示,但我不確定這是否足夠,因為這些提示可能會被忽略,或者它們可能不足以表達通過這種進出緩存的移動可以表達的任何內容命令。

是否有任何允許完全緩存控制的匯編程序?

旁注:為什么我想改進緩存:

考慮一個具有 1 個寄存器和一個包含 2 個單元的高速緩存的假設 CPU。

考慮以下兩個程序:

(其中 x,y,z,a 是 memory 細胞)

"START"
"move 1 to x"
"move 2 to y"
"move 3 to z"
"move 4 to a"
"move z to x"
"move y to x"
"END"

"START"
"move 1 to x"
"move 2 to y"
"move 3 to z"
"move 4 to a"
"move a to x"
"move y to x"
"END"

在第一種情況下,您將對 x,y,z 使用寄存器和緩存(a 只寫入一次) 在第二種情況下,您將使用寄存器和緩存對 a,x,y (z只寫入一次)

如果 CPU 進行緩存,它根本無法提前決定它所面臨的上述兩種情況中的哪一種。

它必須為每個 memory 單元 x、y、z 決定其內容是否應該在它知道程序是否執行之前被緩存,是否。 1 或沒有。 2,因為兩個程序的開始是一樣的。

另一方面,程序員提前知道哪些 memory 單元被重用,以及它們何時被重用。

彼得·科德斯寫道:

在大多數 ISA 的大多數微架構上,不,您不能在緩存中固定一行以阻止它被驅逐。 使用緩存的唯一方法是作為您加載/存儲的透明緩存。

這是正確的,但例外情況很有趣......

在 DSP(“數字信號處理”)芯片中,在“高速緩存”和“暫存器”功能之間提供有限的 SRAM 分區能力是很常見的。 關於這個主題有很多白皮書和參考指南——一個例子是http://www.ti.com/lit/ug/sprug82a/sprug82a.pdf 在這個芯片中,有三個 SRAM 塊——一個小的“Level-1 指令”SRAM、一個小的“Level-1 數據”SRAM 和一個更大的“Level-2”SRAM。 這三個中的每一個都可以在Cache和直接尋址的memory之間進行分區,具體取決於具體芯片。 例如,一個芯片可能不允許緩存,1/4 SRAM 作為緩存,1/2 SRAM 作為緩存,或者所有 SRAM 作為緩存。 (比率是有限的,因此可以有效地索引允許的緩存大小。)

IBM“Cell”處理器(用於 2006 年發布的索尼 PlayStation 3)是一種多核芯片,具有一個普通通用內核和八個協處理器內核。 協處理器內核的指令集有限,加載和存儲指令只能訪問其私有的 128KiB“暫存器”memory。 為了訪問主 memory,協處理器必須對 DMA 引擎進行編程,以將主 memory 塊復制到本地暫存器 memory(反之亦然)。 這種方法提供(並且需要)對數據移動的完美控制,從而產生(非常少量)非常高性能的軟件。

一些 GPU 還具有小型片上 SRAM,可配置為 L1 緩存或明確控制的本地 memory。

所有這些都被認為“非常難”(或更糟)使用,但如果產品需要非常低的成本、完全可預測的性能或非常低的功耗,這可能是正確的方法。

在大多數 ISA 的大多數微架構上,不,您不能在緩存中固定一行以阻止它被驅逐。 使用緩存的唯一方法是作為您加載/存儲的透明緩存。

當然,正常加載肯定會將緩存線帶入 L1d 緩存,至少暫時如此 不過,沒有什么能阻止它在以后被驅逐。 例如在 x86-64 上: mov eax, [rdi]而不是prefetcht0 [rdi]

在存在專用預取指令之前,有時會使用普通加載作為預取(例如,在進入將開始在數組上循環的循環之前進行一些循環邊界計算之前)。 出於性能目的,CPU 可以忽略的盡力而為的軟件預取指令通常更好

普通加載的缺點是在加載的數據實際到達之前無法從亂序后端退出。 (At least I think it can't on x86 CPUs with x86's strongly ordered memory model. Weakly-ordered ISAs that allow out-of-order loads might let the load retire even if it hasn't truly completed yet.) Software prefetch instructions存在以允許預取作為提示,而不會在等待加載完成時阻塞 CPU。

在現代 x86 上,可以強制驅逐緩存 NT 商店保證在 Pentium-M 或更新版本,或 Pentium-M之后的 CPU 上,我忘記了。 此外, clflushclflushopt專門為此而存在。

clflush不僅僅是 CPU 可以掉線的暗示; 它保證了 Optane DC PM 等非易失性 DIMM 的正確性。 為什么x86中存在CLFLUSH?

得到保證,而不僅僅是一個提示,它會讓它變慢。 您通常不想為了性能而這樣做。 正如@old_timer 所說,刻錄指令/周期來微觀管理緩存幾乎總是浪費時間。 從長遠來看,將事情留給硬件的偽 LRU 替換和硬件預取算法通常會提供良好的結果。 SW 預取在少數情況下會有所幫助。


Xeon Phi可以將其MCDRAM配置為大型最后一級緩存,或作為物理地址空間的一部分在架構上可見的“本地內存”。 但在 6 到 16GiB 時,它比片上 L1/L2 緩存或現代主流 CPU 的 L1/L2/L3 緩存大得多。

此外,x86 CPU 可以在緩存即 RAM 無填充模式下運行,BIOS 在配置 DRAM 控制器之前的早期啟動中使用該模式。 但這實際上只是讀取或寫入時沒有填充,無效行讀取為零,因此當激活無填充模式時,您根本無法使用 DRAM。 只有緩存可用,你必須小心不要驅逐任何被緩存的東西。 除了早期啟動之外,它不能用於任何實際目的。

INVD 指令有什么用? Cache-as-Ram (no fill mode) Executable Code有一些細節。

我知道有一些指令會給出“緩存系統”提示,但我不確定這是否足夠,因為這些提示可能會被忽略,或者它們可能不足以表達通過這種進出緩存的移動可以表達的任何內容命令。

直接訪問緩存 sram 與指令集無關,如果您可以訪問,那么您就可以訪問並且您可以訪問它,但是芯片/系統設計人員實現了它。 它可能像地址空間一樣簡單,也可能是一些間接外圍設備,例如訪問控制寄存器,邏輯為您訪問緩存中的該項目。

這並不意味着所有 ARM 處理器都可以以相同的方式訪問其緩存。 (arm 是 IP 公司而不是芯片公司)但這可能意味着不,您不能在任何現有的 x86 上執行此操作。 我知道關於我參與的產品的一個事實,我們可以做到這一點,因為我們在這些 SRAM 上有 ECC,並且有一種訪問方法可以在啟用監視器之前從軟件初始化 ram。 一些 SRAM 可以通過正常訪問來完成,但例如我們使用的 arm 是通過奇偶校驗而不是 ECC 實現的,所以我們在 SRAM 上添加了 ECC 並為 init 添加了側門訪問,因為試圖通過正常的緩存通過 go訪問並獲得 100% 的覆蓋率是一個 PITA,最終不是正確的解決方案。

還開發了一個產品,其中 dram controller 緩存可用作片上 ram 直接訪問,由軟件決定如何將其用作 L2 緩存或片上 ram。

所以它已經並且可以做到,這些都是孤立的例子。 作為篩選部件的一部分,運行了 mbist 測試,但通常這些測試是通過 jtag 驅動的,並且不能直接用於處理器和/或 ram 不可用,有時 mbist 可以通過軟件啟動和檢查,但 ram 可以't,以及一些實現,設計者制作它是為了讓軟件可以觸及所有這些,包括標簽內存。

這導致如果您認為您可以比硬件做得更好並且想要移動東西,那么您可能還需要訪問標簽 ram,以便您可以跟蹤/驅動您想要緩存行的位置,它的狀態, ETC。

基於此評論:

對不起,我是組裝的[初學者],你能簡單解釋一下嗎? 什么是 CPU“模式”? 那是什么HBM? 如何設置CPU模式? 什么是 NDA? – KGM

兩件事,你不能比緩存做得更好,第二,你還沒有准備好完成這項任務。

即使有經驗,您通常也無法比緩存做得更好,如果您想操作緩存,您需要使用與如何編寫代碼、將其放置在 memory 中的位置以及您正在使用的數據的位置相同的知識然后邏輯實現可以更好地為您工作。 刻錄指令和循環試圖重新定位運行時的東西不會有幫助。 您通常需要在公眾無法獲得的級別訪問設計。 因此,NDA(保密協議),即使那樣,您也極不可能獲得所需的信息和/或收益將是微乎其微的,可能僅適用於一種實現,而不適用於整個產品系列等。

更有趣的是你認為你可以做的更好,你認為你可以如何做? (還要了解,我們這里的許多人都可以使任何緩存實現失敗並且運行速度比沒有緩存時慢,即使您創建了一個更新的更好的緩存,根據定義,它只會在某些情況下提高性能)。

暫無
暫無

聲明:本站的技術帖子網頁,遵循CC BY-SA 4.0協議,如果您需要轉載,請注明本站網址或者原文地址。任何問題請咨詢:yoyou2525@163.com.

 
粵ICP備18138465號  © 2020-2024 STACKOOM.COM