龍芯的3A5000代表了中國國內的另一項CPU努力。它實現了四個 LA464 內核，面向從臺式機到服務器再到嵌入式應用程序的所有應用。就像我們之前介紹的兆信KX-6640MA和Phytium D2000一樣，龍芯的芯片以低時鐘速度運行。但與其他中國芯片不同的是，龍芯使用的是基于MIPS的ISA。之前的龍芯芯片兼容MIPS64，但該公司改用名為Loongarch的ISA。Loongarch共享MIPS的大部分語義，但使用不同的指令編碼。龍芯還擴展了ISA以支持256位矢量執行。

　　我們將在這里做一些簡短的基準測試。這樣做的目的不是測試大量應用程序以提供全面的性能圖。Phoronix已經有一些結果，以防您想知道CPU通常位于何處。相反，我們正在運行幾個測試，并使用我們可用的少量性能計數器來分析它們。我們將使用這些數據來幫助我們分析龍芯的架構。

　　為了進行比較，我們將使用AMD的Zen 1架構，因為一些網站認為3A5000可能與Zen 1相當。泰坦尼克號友好地設置了具有雙通道DDR7-1800的Ryzen 4X系統2400-1。Ampere Altra，以來自Oracle云的免費四核實例的形式，也將在這里展示。Neoverse N3內核可能與5000A《》中的內核更具可比性，因為它們同樣不會達到高時鐘速度。

　　高級性能

　　7-Zip是一個高效的壓縮程序，我們看到壓縮從分析Firefox編譯中生成的巨大文件需要多長時間。執行的指令流幾乎完全由標量整數運算組成。此處的結果無法與此站點上以前的結果直接比較，因為我們這次指定了 16 個線程。盡管我們將其限制為四個內核，但運行更多線程可以提高利用率和性能。

　　3A5000在絕對性能上無法與Zen 1相提并論。但是，如果我們不讓 Zen 1 在一個內核中使用兩個 SMT 線程，則每個時鐘的性能具有競爭力。龍芯的實際性能更接近四核安培Altra設置。但即使在那里，它的表現也大大優于。同樣，每個時鐘的性能很接近，但 2.5 GHz 是一個非常低的時鐘速度，即使對于不優先考慮單線程性能的服務器芯片也是如此。

　　視頻編碼

　　libx264 是一個用于處理 H264 編解碼器的免費軟件庫。盡管H264相當古老，但由于廣泛的硬件解碼支持和H265等較新編解碼器的許可問題，H《》仍然很受歡迎。在這里，我們正在轉碼《守望先鋒》游戲玩法的短片，使用“非常慢”預設來優先考慮質量。畢竟，如果您不關心質量并且想要最快的編碼，您只需使用 GPU 的硬件編碼器。

　　一些從Loongarch libx264中反匯編的代碼，顯示了使用“xr”256位LASX矢量寄存器，以及“vr”256位LSX寄存器

　　此測試中執行的指令流包含高百分比的向量指令。Loongson使用內部函數在其libx264的分布式版本中添加了LSX和LASX支持。這非常好，因為嘗試僅使用編譯器生成的代碼進行視頻編碼或其他計算繁重的任務將導致性能極差。

　　不幸的是，性能并不出色。依賴純 C 代碼通常會導致性能降低一個數量級。值得慶幸的是，龍芯避免了這種情況。但3A5000與Zen 1相比表現不佳。它也無法與四核安培Altra相匹配。考慮到這兩個芯片都有128位執行單元，這是一個糟糕的表現。至少在支持 AVX2 的 x86 芯片上，此測試中執行的指令中有 10% 以上是 256 位的。Zen 1確實支持AVX2，但將256位指令解碼為兩個微操作。安培Altra當然僅限于128位NEON指令。Zen 1和Neoverse N1都不以強大的矢量性能而聞名，但都擊敗了3A5000。

　　指令計數和 IPC

　　性能計數器讓我們跟蹤很多事件，其中最重要的事件之一是停用指令的數量。在無序執行的 CPU 中，指令停用是指內核提交指令的結果并使其可見（換句話說，已完成執行并通過所有必需的檢查）。我們在這里不是使用熟悉的 ISA 測試 CPU。如果ISA有影響，一個跡象是指令計數的巨大差異。

　　使用 7-Zip，指令數差異小于 5%。很好。沒有人會執行更多的指令來完成工作。

　　IPC方面，龍芯做得相當不錯。IPC 與每時鐘性能不同，尤其是在使用不同的 ISA 或 ISA 擴展時。但在此壓縮基準測試中，指令計數具有可比性，因此 IPC 與每個時鐘的性能密切相關。在這種情況下，3A5000的主要弱點歸結為其非常低的時鐘速度。

　　libx264 是一個不同的故事。盡管有 LAVX 支持，但 3A5000 必須處理 12% 到 23% 的指令才能完成相同的工作。ISA 不僅僅是擴展，而不僅僅是矢量寬度。也許LAVX缺少NEON和AVX2的一些專業指令。我們沒有完整的LVX和LAVX指令列表，所以這只是一個猜測。

　　同樣，龍芯的IPC相當不錯。但與 7-Zip 機箱不同的是，3A5000 執行了更多指令來完成工作。這意味著每個時鐘的性能明顯低于 Zen。

　　前端：分支預測

　　分支預測的準確性很重要。

　　所有三個測試的 CPU 的預測準確性非常相似。即使是 Zen 1 在加載兩個 SMT 線程時也不會受到太大影響。但是，3A5000 每條指令遭受的誤預測更多，這意味著它比這里的其他 CPU 更容易遭受錯誤預測處罰。雖然它的分支預測器似乎做得很好，但 Loongarch 指令流的 17.7% 由分支組成，而 x15-1 為 86.64%，16 位 ARM 為 1.64%。

　　在視頻編碼測試中，龍芯稍稍落后。Zen 1和Neoverse N1的分支預測因子在此測試中表現更好，盡管差距并不大。在精度方面，當AMD的核心必須處理兩個線程時，3A5000接近Zen 1。龍芯確實有相當的每條指令的錯誤預測率，但這有點紅鯡魚。3A5000執行的指令比Zen 1多得多，以完成工作。所以，這意味著龍芯正在處理分支之間的更多指令。所有三個CPU的執行分支計數相差不到10%（盡管有趣的是，龍芯的執行分支數最高，為1.2萬億，而Zen 1和Ampere Altra分別為1.1和16.1萬億）。

　　前端：指令提取

　　3A5000 具有 64 KB、4 路設置關聯 L1 指令緩存，有助于加快指令交付速度。Neoverse N1和Zen 1也有不錯的64 KB L1指令緩存。在7-Zip上，它足以容納“熱”指令足跡。事實上，在此測試中，Zen 1 的微操作緩存提供了管道微操作的 85% 以上，這表明 7-Zip 的指令占用空間非常小。

　　在所有三個經過測試的 CPU 中，每條指令的未命中數都非常低。對于龍芯來說，它特別低，這很好，因為3A5000在必須從L2獲取代碼時就沒有那么好了。但是對于每個人低于 1 MPKI 的人來說，這無論如何都不是一個很大的因素。

　　libx264 也有很高的 L1i 命中率，盡管我們看到所有三個 CPU 上的 L1i 未命中率更高。龍芯現在遭受的痛苦更大，盡管2 MPKI仍然不是特別令人擔憂。

　　后端：L1D 命中率

　　這里測試的三個CPU在數據方面有更多的差異。AMD 的 Zen 架構具有相對較小的 32 KB、8 路集關聯 L1D。龍芯的3A5000和Neoverse N1都具有更大的64 KB，4路L1D。在7-Zip中，龍芯的L1D表現出人意料地差。根據性能計數器，L1D 命中率要低得多。Neoverse N1 具有最佳的 L1D 命中率，即使具有類似的緩存幾何形狀。N1 也擊敗了 Zen 1 的 L1D 命中率，因此關聯性較小的 L1D 應該更好。也許龍芯沒有一個好的替換策略，或者經常積極地預取和踢出有用的數據。

　　對于 7-Zip，每條指令的未命中數在很大程度上講述了同樣的故事，因為執行的指令計數相似。

　　龍芯的L1D遭遇了很多失誤。在libx264中，龍芯的表現稍好一些。L1D命中率仍然不是它應該考慮其容量優勢的地方，它仍然無法趕上Zen。但是，這也不太遠。

　　按照指令，龍松沒有遭受太多的失誤。但這主要是CPU在此工作負載中執行更多與計算相關的指令的跡象，這意味著內存訪問代表較少的已執行指令流。這也意味著L1D失誤的影響較小，因為內核必須通過更多的數學指令來阻礙。禪宗的情況正好相反。

　　二級和三級緩存

　　通常，CPU 為其 L1 緩存中的絕大多數訪問提供服務。但是DRAM訪問非常慢，以至于他們需要較低級別的緩存。最后一級緩存 （L3） 的容量在兆字節范圍內，因此速度足夠慢，以至于中級緩存 （L2） 可以帶來性能優勢。龍芯有一個256 KB的二級緩存和一個不錯的2 MB三級緩存。Zen 在四核集群中具有較大的 16 KB L3，但較小的 512 MB L2。Ampere Altra 每個內核使用非常好的 8 MB 二級緩存，但在 3 個內核之間共享 1 MB 三級緩存。

　　L3 緩存的性能計數器在 Ampere Altra 上似乎無法正常工作。它們顯示的 L3 補充比對 L3 的請求多，這意味著 L3 的命中率為負。這沒有意義，所以我們從0%開始圖形比例，根本不會談論Ampere Altra的L3。

　　在7-Zip中，龍芯的16 MB L3具有相當不錯的命中率，并且可能在3A5000的每時鐘性能中發揮作用。龍芯也看到了非常好的L2命中率，特別是考慮到它的小尺寸。但這不一定是一件好事。L2命中率很高，主要是因為L1D遭受的失誤比應有的多。

　　查看每條指令的緩存未命中數可以證明這一點。正如預期的那樣，龍芯的 256 KB L2 每條指令的失誤次數比 Zen 的 512 KB L2 多。我們還可以將高 L3 命中率歸因于大量的 L2 未命中。龍芯似乎確實比Zen遭受了更多的L3失誤，但這可能是因為我在Zen上使用了L1D需求填充的事件。在 Loongson 上，我使用的是 perf 中定義的 LLC-load-misses 事件。Loongson 沒有記錄 3A5000 的性能監控事件，因此我不知道該性能事件是否包括預取的未命中。

　　libx264 似乎具有更大的數據占用空間。我們已經看到 L1D 緩存遭受了更多的失誤，而較低級別的緩存同樣不如 7-Zip 有效。Neoverse N1的大L1絕對有助于它。Zen 1的L2有助于緩沖處理在單個內核中運行的兩個線程的數據占用空間的打擊，但命中率并不是很高。查看每條指令的失誤就很好地說明了這一點。Zen 1 在兩個 SMT 線程都處于活動狀態的情況下遭受更多的 L2 未命中，但 L1D 遭受的損失更大，L2 最終捕獲了很多這些訪問。

　　Loongson的L2似乎在這個指標上做得很好，但這只是因為它執行了更多的指令，以至于內存層次結構的影響較小。在絕對計數中，它實際上遭受了這里測試的任何CPU中最多的L2失誤（超過244億次，而加載182個SMT線程的Zen 176和Ampere Altra分別為1和1）。這同樣適用于 L3 未命中，盡管差距較小。同樣，對這些絕對計數持保留態度，因為我們并不確切知道龍芯的性能事件正在測量什么。

　　第一印象（架構和性能）

　　龍芯的3A5000似乎相當稱職。與植酸D2000和兆信KX-6640MA不同，3A5000具有由大型緩存支持的均衡核心架構。每個時鐘的性能在精細壓縮方面是不錯的，盡管它遠遠落后于英特爾和AMD最先進的CPU。但是每個時鐘的體面性能并不意味著可接受的性能。龍芯落后的地方在于時鐘速度。按照今天的標準，2.5 GHz 非常低。即使是高內核數的服務器 CPU 在時鐘遠高于 3 GHz 時也沒有問題。到目前為止，這似乎是龍芯最大的弱點。

　　術語“架構效率”或“同一時鐘的性能”有時被視為衡量良好程度的指標。也許這是為低時鐘速率道歉的一種方式，或者當微電流“有一天”達到該設計實際上無法獲得的時鐘速率時，這是一種暗示更高性能的方式。。。。。。

　　David B. Papworth，《Tuning the Pentium Pro Microarchitecture》，IEEE Micro

　　我們目前正在對 3A5000 進行微基準測試，以了解有關其架構的更多信息。我們最初的印象是，該核心的ROB容量與Phytium的D2000相似，但其他無序緩沖器的尺寸要好得多。最終我們將有一篇完整的文章，但分析這個CPU有點困難，因為我們的大多數基準測試都依賴于匯編代碼。編譯器傾向于做不可預測和復雜的事情，這使得很難從高級代碼中觀察體系結構特征。

　　不幸的是，這意味著我們必須編寫大量代碼來研究龍芯的3A5000。編寫匯編可能很困難，為不熟悉的ISA（LoongArch64）編寫匯編將難度帶到了另一個層次。測試微基準代碼也不容易。通常，我們可以通過在具有已知特征的 CPU 上運行測試并確保結果合理來驗證測試。但在這種情況下，龍芯的 3A5000 是我們唯一的龍 Arch64 CPU，大部分細節都沒有公開。我們幾乎是盲目飛行。每個測試都需要更長的時間來編寫，并且出錯的可能性很高。

　　這就引出了另一個大問題：軟件生態系統支持。如前所述，3A5000運行龍芯專有的ISA，Loongarch。Loongarch與MIPS共享許多約定和語義，盡管使用了不兼容的編碼。一方面，這意味著龍芯能夠復制和粘貼大量現有的MIPS代碼來開始使用。另一方面，MIPS軟件生態系統無法與x86或ARM相提并論。我預計龍芯在他們的軟件生態系統中會遇到很多初期問題。

　　回過頭來看，中國國內的芯片努力有點滑稽。兆信的KX-6640MA和植樹的D2000每核性能都很差。3A5000更好，代表了我們迄今為止在中國看到的最強大的CPU努力。但它不會享受強大的x86或ARM軟件生態系統，如果你不能讓它運行你的軟件，CPU的性能就沒有多大意義。