Lancer

龍芯目前的性能究竟到了何種地步，其設計水準距離國際競爭對手還差多遠，龍芯選擇MIPS究竟出于何種考慮，為何今日的龍芯不是基于現(xiàn)在的當紅小生一ARM架構？針對這些外界爭論多時的問題，本文將用專業(yè)而詳盡的分析予以解答。

談到國產(chǎn)CPU產(chǎn)品龍芯，圍繞它最大的爭議就是性能。雖然龍芯的早期產(chǎn)品并沒有讓大家滿意，但隨著新架構GS464E的披露，以及采用該架構的新一代CPU“3B2000”的正式問世，外界開始非常期待它倍增的性能究竟和Intel的主流產(chǎn)品存在哪些優(yōu)勢和差距。

在前一次《信息科學雜志》給出的數(shù)據(jù)測試結果中，早期編譯的GS464E已經(jīng)接近Intel、AMD現(xiàn)在市場上的主流架構性能，與Intel Core i3-550和AMD FX-8320基本相當，與Intel Core i5-2300略有差距，同時明顯強于Intel Atom、VIA Nano、ARM Cortex-A57等低功耗架構。

那么，龍芯目前的性能究竟到了何種地步，其設計水準距離國際競爭對手還差多遠，龍芯選擇MIPS究竟出于何種考慮，為何今日的龍芯不是基于現(xiàn)在的當紅小生一ARM架構？針對這些外界爭論多時的問題，本文將用專業(yè)而詳盡的分析予以解答。

一黑一白，今日孰是孰非？

坦白來說，龍芯近年來在輿論中受到圍攻已經(jīng)不是新聞，今年初一篇名為《國產(chǎn)龍芯究竟水平如何？》的文章在網(wǎng)上掀起軒然大波，直指號稱面向高性能服務器開發(fā)的龍芯3B-1500處理器尚不如今日ARM Cortex-A57手機處理器。

耐人尋味的是，不到一個月過后，該文的作者再次撰寫了一篇《詳解，新一代“龍芯”能否挑戰(zhàn)Core i7？》，筆鋒一轉為尚未正式公開露面的下一代龍芯大唱贊歌。

在不訴諸陰謀論的前提下，筆者認為這樣劇烈起伏的輿情其實都指向一個事實：對于龍芯的現(xiàn)狀，其實外界并不了解，一般公眾并不具備從龍芯組公開發(fā)表的艱深論文中推斷其結構設計水平的能力，亦并不知曉編譯器，相關軟件系統(tǒng)與所用基準測試程序的偏好，因此對性能的對比也多有偏頗。

例如，被抨擊為不如Cortex-A57的龍芯3B-1500雖然流片于2012年，但其核心卻是2006年左右完成的設計，當時其制定的競爭目標主要是Intel的奔騰3和早期奔騰4處理器，性能自然會落后于今日的手機CPU旗艦。

而被其描述為可以在IPC上與Ivy Bridge一戰(zhàn)的新一代龍芯微結構GS464E，雖然相比上一代產(chǎn)品取得了突破性的進步，但在頻率指標取得突破之前，又將憑借什么與Intel抗衡呢？

歷史原因 為何選擇MIPS指令集？

目前已經(jīng)推出的龍芯核心主要分為三大系列，型號為GS1XX，GS2XXX和GS3XX，其中GS132系列對標ARM CortexM0和CortexM3，GS232和GS264對標ARM9，ARM11與Cortex-A12，GS464E也就是本文即將介紹的最新版龍芯核心，將對標Intel Ivy Bridge。

先前被認為不如手機CPU的龍芯3A 1000與龍芯3B1500均使用上一代GS464和其向量增強型GS464V核心設計，性能差距較大。

上述所有龍芯系列產(chǎn)品都兼容MIPS指令集，注意，這里的兼容并不是如同外界謠傳的那樣指代龍芯使用了來自MIPS的核心，而是僅僅讓龍芯的產(chǎn)品能夠運行MIPS所定義的指令集，例如000000在MIPS中代表加法操作碼，在龍芯處理器上也代表加法操作碼，僅此而已。

硬件方面，從龍芯的微結構到電路、版圖設計均為獨立自主開發(fā)。

很多人也有疑惑，為何龍芯沒有選擇當下如日中天，隱隱與Intel形成分庭抗禮之勢的ARM指令集呢？

其實，龍芯項目開始前期調(diào)研的時間點是2000年前后，當時ARM的確有被列入考慮范圍之內(nèi)，但是面對龍芯要求實現(xiàn)高性能的初始目標相比，ARM公司的定位則顯得不合時宜，彼時的ARM能拿出的最強核心設計是ARM11，沒有亂序執(zhí)行，沒有多發(fā)射，沒有今天這樣先進的緩存系統(tǒng)。

ARM旗下第一款支持雙發(fā)射的Cortex-A8設計是2005年才對外公布的，在此基礎上加入亂序執(zhí)行的Cortex-A9則更是到2007年前后才宣告面世。這倒不完全是因為ARM在高性能設計上實力孱弱，而更多地是因為ARM將自己的產(chǎn)品定位為面向嵌入式計算的產(chǎn)品，極為緊張的面積和功耗預算使得許多高性能設計上常見的特征難以實現(xiàn)。隨著技術的進步以及嵌入式計算能力需求的暴增，ARM才開始著手打造高性能CPU。

上世紀90年代，MIPS和DEC Alpha等幾大廠商都于1995年前后陸續(xù)實現(xiàn)了亂序四發(fā)射的設計，風頭甚至壓過當時的Intel、MIPS的R4000、R10000以及DEC Alpha 21164。

其中DEC Alpha 21264放眼今日仍然是有志于處理器微結構設計的后學晚輩們所必看的經(jīng)典之作，深度流水線，分支預測，寄存器重命名，Load-Store推測，一應俱全。雖然在90年代后期MIPS和DEC Alpha逐漸勢微，但虎落平陽余威猶在。在x86陣營經(jīng)營多年的專利壁壘無法攻破的情況下，高性能CPU廝殺的戰(zhàn)場上為當時蹣跚起步的中國CPU提供的選擇著實不多。

以當年的情況看，ARM在多年內(nèi)都無力進攻嵌入式以外的市場，這意味著ARM的指令集系統(tǒng)在嵌入式以外幾乎等同于無根之水，沒有人會愚蠢到量產(chǎn)基于ARM11的個人電腦和服務器。單純憑借一個國產(chǎn)項目力圖對抗Wintel聯(lián)盟的鐵桶江山與蚍蜉撼樹別無二致。

而與Intel正面交戰(zhàn)過并且曾經(jīng)享有勝者頭銜的MIPS和DEC Alpha所留下的軟件生態(tài)環(huán)境自然要比ARM強大許多，國內(nèi)先后上馬的龍芯和申威兩大擁有政府支持的CPU項目就是分別采用了MIPS與DEC Alpha指令集。

因此筆者認為，在堅持高性能設計并且想要獲取市場支持的前提下，選擇MIPS/DEC Alpha是一個正確的決策，以今日ARM的崛起來拷問當時的選擇難免有馬后炮的嫌疑，無人能夠超越歷史局限預估到十年之后的未來。

正像無人能夠預見到2000年正踩在鋼絲線上生死未卜的蘋果公司能夠在十年后登上浪潮之巔一樣。但是歷史終究已成歷史，今日龍芯面臨的困境也是眾人皆知的，那么龍芯團隊能不能實現(xiàn)自己當初的目標，他們拿出的新一代GS464E又是什么樣的呢？

喜憂參半 新一代GS464E架構之前端取指

縱觀全局，取指部件是新一代龍芯GS464E中改動最大的幾個地方之一。大體框架上，一級指令緩存（取指部件圖的下半部分）為了追求速度被設計為并行訪問的結構，在IF2階段和IF3階段同時讀取指令（IC Cache Data）和相關的地址標記（IC Cache tag），在IF4階段判斷是否命中，取出命中的指令。從取指部件部分的框架圖來粗略判斷，前端部分的效率仍是喜憂參半。

令人欣喜的地方有三個，在這三個方面龍芯GS464E的結構設計都達到甚至超越了國際水準。

第一，指令緩存的大小達到了64KB（四路組關聯(lián)），超越了IBM Power7的32KB（四路組關聯(lián)）；

第二，取指寬度已經(jīng)達到了每周期8條指令，考慮到龍芯以MIPS32作為基礎指令集，以每條指令32位寬計算，一級指令緩存的取指寬度達到了每周期32字節(jié)，而Intel Haswell處理器的一級指令緩存僅能達到每周期16字節(jié)的吞吐率（但存儲解碼后指令的uop cache能達到32字節(jié)/周期的吞吐率）；

第三，GS464E也加入了Intel從SandyBridge期間開始配備的循環(huán)檢測器和循環(huán)指令緩沖區(qū)，這種結構設計允許CPU在不斷取指令的同時，去識別哪些指令構成了一個循環(huán)，在發(fā)現(xiàn)循環(huán)再次出現(xiàn)的時候關掉指令緩存，僅從循環(huán)緩沖區(qū)中取用。筆者相信GS464E的循環(huán)緩沖區(qū)設計從Intel的SandyBridge中獲取了一些靈感，巧妙地把它與負責解耦取指部分和解碼部分的Instruction Queue做成了一個模塊，與SandyBridge一樣支持存儲56條內(nèi)層循環(huán)指令。

而令人擔心的地方也有三個：

第一，當一級指令緩存發(fā)生缺失時，缺失的地址會送給緩存失效隊列進行處理。引入緩存失效隊列（學術界通稱為MSHR）來負責從下層存儲器取出缺失的和即將使用的預取數(shù)據(jù)本是早已成為標準配置的做法，但龍芯的緩存失效隊列卻由一級指令緩存和一級數(shù)據(jù)緩存共享，并且這個失效隊列僅有16項，意味著僅能存儲16個失效請求。筆者預計龍芯此后的設計將會嘗試將失效隊列分離或是提高容量；

第二，從框架上看，GS464E的指令TLB部分距離國際水準仍有差距，Intel在Sandy Bridge微架構上就實現(xiàn)了144項四路組關聯(lián)的一級指令TLB，AMD的Bulldozer也實現(xiàn)了72項全相連一級指令TLB和512項四路組關聯(lián)TLB的搭配，而龍芯僅有64項全相連一級指令TLB（一級指令TLB的大小較難提升），且并未出現(xiàn)二級指令TLB的設計，指令TLB覆蓋范圍的弱勢可能會加劇指令緩存缺失之后的性能損失；

第三，IBM Power7的一級指令緩存部分與龍芯頗為相似，但是加入了先行路選擇技術，推測性地只開啟指令緩存中將要被訪問的一個部分而不是全部，從而削減功耗，在此之外又非常激進地將一級指令緩存切分為16個bank，盡量避免讀寫沖突。而龍芯的指令緩存部分并未提及路預測技術的加入，也僅僅切分為4個bank。綜合優(yōu)勢與劣勢來看，尚不能簡單斷言龍芯的取指令效率能夠比肩國際主流水準。

再來看前端中另一個不容忽視的模塊—分支預測器。GS464E的分支預測器經(jīng)過大幅改造，不難看出是投入了血本、大幅度提高了各項規(guī)格。從表面參數(shù)上來看，它已經(jīng)能夠比肩Sandy Bridge的水準—錦標賽分支預測器，返回地址棧，間接跳轉預測器，可謂一應俱全。

錦標賽分支預測器有三大主要內(nèi)建部件—專門根據(jù)局部歷史預測分支走向的局部歷史表（Local Branch History Table），專門根據(jù)全局歷史分支走向的全局歷史表（Global Branch History Table），以及專門負責決斷前兩者哪一個準確率更高的全局選擇表（GSEL）。三者的存儲空間都達到了16K項的大小，推測與Sandy Bridge齊平，也超過了IBM Power7。

專門負責預測函數(shù)調(diào)用返回地址的返回地址棧（Return Address Stack）能夠存儲16項，與AMD Jaguar和IBM Power7齊平。在基本參數(shù)已經(jīng)追平國際水準的情況下，比拼分支預測準確率的因素就落在了其他細節(jié)設計上，例如返回棧是否支持在錯誤預測下的棧修復、錦標賽預測器是否加入了其他設計技巧降低歷史表的訪問沖突等等。

筆者謹慎樂觀地認為，只要這些細節(jié)設計不出現(xiàn)明顯失誤，GS464E的分支預測能力將可以與Intel的設計一決雌雄。

仍有落后 新一代GS464E之亂序執(zhí)行引擎

盡管同為亂序四發(fā)射的框架，但從表1來看，GS464E的亂序執(zhí)行引擎部分的基本參數(shù)相比Intel的Sandy Bridge仍有顯著落后。

首先，重定序隊列（Re-Order Buffer，ROB）決定了亂序執(zhí)行引擎能夠從多大的指令范圍內(nèi)抽取指令級并行度、挑選不相干指令進行亂序執(zhí)行。而整數(shù)物理寄存器數(shù)量決定了最多容納多少次整數(shù)寄存器重命名，在這些參數(shù)上龍芯仍有較大差距需要追趕。

除此之外，龍芯在發(fā)射隊列上還是選擇了設計難度較小、容易提高容量、但是也容易導致資源配置不均衡的分離式發(fā)射隊列設計。AMD和MIPS歷史上都曾使用過這種設計，在這種設計里面所有允許亂序執(zhí)行的指令都是分類型分開存儲的，比如整數(shù)指令存儲在自己的獨立發(fā)射隊列中，浮點指令存儲在另一個獨立發(fā)射隊列中，碰到整數(shù)密集型的程序把整數(shù)隊列占滿了之后，浮點發(fā)射隊列可能是全空的。

與之相對的設計是集中式發(fā)射隊列，集中式的發(fā)射隊列設計復雜，極難大幅提高容量，但是所有的指令都存儲在同一個地方，避免了空置的情況，這是與分布式發(fā)射隊列不同的權衡。

在這種設計上，Intel已經(jīng)浸淫多年，Intel的第一代亂序多發(fā)射微結構P6就是采用集中式發(fā)射隊列，從Pentium4的Netburst開始改成了分布式發(fā)射隊列，從Core開始又改回了集中式發(fā)射隊列，并一直堅持至今，堪稱是集中式發(fā)射隊列設計的忠實擁簇。

在Core時代，Intel的集中式發(fā)射隊列容量僅為32條指令，而AMD的K8所配備的分布式發(fā)射隊列的總容量達到了60條指令，幾乎多了一倍，但強大的Intel硬生生地將自己的發(fā)射隊列容量逐年提高，終于在Haswell上實現(xiàn)了72條目的集中式發(fā)射隊列和8發(fā)射端口的設計。在不存在并發(fā)條件限制的情況下，單單這一個集中式發(fā)射隊列每周期就可以分派8條允許亂序執(zhí)行的指令到各個執(zhí)行單元，可謂是集中式發(fā)射隊列的登峰造極之作。

龍芯在論文中并未透露自己的分派寬度，但從發(fā)射隊列和執(zhí)行單元的配置來看，筆者估計可能在4～6條指令之間。

當然，在具體的細節(jié)上，龍芯GS464E這一邊的設計也有值得稱道的部分。所有頻繁觸及的執(zhí)行單元都能夠單周期完成操作，并通過激進的數(shù)據(jù)前遞設計在數(shù)據(jù)依賴的情況下支持背靠背發(fā)射，訪存流水線支持訪存指令的推測性發(fā)射和指令回放（一種較為困難的訪存優(yōu)化技巧，可以縮短訪存延遲）。

更值得稱贊的是，物理寄存器堆（PRF）和基于指針的發(fā)射隊列處理邏輯也被早早地引入，這是一條曾經(jīng)被Intel放棄的路線，后來為了引入AVX指令集又不得不選擇相同做法，龍芯非常聰明地避開了Intel曾經(jīng)走過的彎路。

但是這些細節(jié)改進并不足以幫助GS464E在亂序執(zhí)行能力上叫板Core i7，龍芯需要再花費多長時間才能達到Haswell的亂序執(zhí)行引擎的設計水平，就要看龍芯的物理和電路層設計水準能不能夠撐得住規(guī)模更大的發(fā)射隊列、更加復雜的數(shù)據(jù)前遞網(wǎng)絡以及支持更多并發(fā)讀寫口的物理寄存器堆，這些關鍵結構是支撐亂序執(zhí)行引擎的設計重點所在。

容量充足 新一代GS464E之緩存系統(tǒng)

GS464E的一級數(shù)據(jù)緩存部分與指令緩存同為64KB，四路組關聯(lián)，但是改成了串行訪問設計，亦即先訪問地址標記陣列（Tag Array），確定命中后再訪問數(shù)據(jù)陣列（Data Array）。這種設計的意圖是犧牲幾個周期的訪存延遲帶來更低的訪存功耗，但在GS464E可以維持4周期的一級數(shù)據(jù)緩存裝載至使用（load-to-use）延遲的情況下，這個代價是可以接受的。

比較有趣的是一級數(shù)據(jù)緩存之下的部分，每個GS464E核心在一級緩存下還有一道獨立緩存系統(tǒng)，龍芯組將它稱之為Victim Cache。

一般來說Victim Cache是附在一級緩存邊的一個小Cache，僅能存儲極少容量，主要為了接住被一級緩存踢出的數(shù)據(jù)，并在急需時快速傳回它們。而龍芯的Victim Cache卻有256KB，從術語約定上來說這就已經(jīng)不是Victim Cache，而是正統(tǒng)的私有二級緩存。稱呼它為Victim Cache的原因應該是因為這一道緩存與一級緩存之間是互斥式設計，亦即出現(xiàn)在一級緩存中的指令和數(shù)據(jù)在二級緩存一定沒有備份。

作為參考，AMD也使用了相同的互斥式設計。而Intel和IBM則堅持包含式設計，亦即一級緩存中出現(xiàn)的內(nèi)容在二級緩存中一定存在，這兩種設計方式主要會影響到緩存命中率以及多核情況下的緩存一致性維護，各有優(yōu)劣。

包含式設計的優(yōu)點是簡化了多核心計算下的同步問題，因為一級緩存中的數(shù)據(jù)保證在下層中存在，所以查詢數(shù)據(jù)同步狀態(tài)時只需要詢問下層存儲器即可，但缺點也非常明顯，就是浪費了緩存空間，因為多層緩存都保存了多份同樣的數(shù)據(jù)副本。而互斥式設計避免了空間浪費，但是每次處理多核心同步時都要檢索整個多級緩存體系，讓多核心的一致性問題變得更加復雜。

龍芯的二級緩存采用16路組相連設計，使用與一級數(shù)據(jù)緩存相同的串行訪問模式，龍芯的論文中稱這道緩存系統(tǒng)采用LRU替換算法，筆者認為這可能屬于筆誤，或者論文撰寫者與緩存模塊實際設計者雙方出現(xiàn)了溝通不暢。

因為16路組關聯(lián)如果要采用LRU替換算法就需要維持一個16！的狀態(tài)數(shù)=20922789888000的狀態(tài)機，這顯然是無法實現(xiàn)的。歷史上也從來沒有超過四路組關聯(lián)設計的緩存搭配了LRU替換策略，GS464E這里采用的應當是一個經(jīng)過簡化的偽LRU算法。

需要指出的是，采用偽LRU算法這并不是一個性能缺陷，好的偽LRU算法的替換準確率與LRU相差無幾，在真LRU無法實現(xiàn)的情況下，所有超過四路組相連的緩存設計都是采用了偽LRU替換，Intel、AMD、IBM概莫能外。

在這個Victim Cache之下，還有最后一道被稱為SCache的片上共享三級緩存，這一級緩存仍舊是16路組相連，每個SCache模塊是1MB大小，四個核心的SCache模塊拼接起來就是4MB。一般而言末級緩存系統(tǒng)都是切分多個Bank之后通過掛接到Crossbar上，各個獨立核心通過Crossbar訪問共享的末級緩存。龍芯將SCache直接掛接到GS464E核心外，可能說明龍芯已經(jīng)采用了一些NoC（Network on Chip）的設計思路，在為未來擴展多核、眾核做準備。

值得稱道的是，龍芯的二級、三級兩級緩存都維持了較大的容量和組關聯(lián)度，但是訪問延遲較長，二級緩存的訪問延遲超過20個周期，比Intel處理器的二級緩存相比慢了幾乎一倍，三級緩存需要超過50個時鐘周期的時間，與Intel處理器基本持平。

同頻性能接近Sandy Bridge實測數(shù)據(jù)分析

龍芯目前公布的實測數(shù)據(jù)主要是在RTL仿真以及硬件加速仿真驗證平臺上取得的，設定頻率為1GHz，如果實際芯片能夠運行在1GHz上，并且接口時序設定正確，它們和實際芯片運行性能是沒有什么差別的。

從表2可以看到，龍芯GS464E號稱訪存性能即內(nèi)存性能提高了10～20倍。據(jù)悉前代龍芯過于注重核心微結構，內(nèi)存控制器設計則過于輕視，甚至連突發(fā)傳輸模式的支持都沒有做好，因此內(nèi)存性能非常低下。而這一次流式訪存性能暴漲則也是因為修正了內(nèi)存控制器的bug，同時加上了激進的多級預取機制的結果。以Memcpy和Stream-Copy兩個測試子項來看，龍芯的內(nèi)存控制器在操作雙通道DDR3-1000時，在局部性較好的流式訪問上距離Ivy Bridge + 單通道DDR3 1333的平臺還有20%左右的差距。

同時龍芯公布了Whetstone，Coremark，Dhrystone等幾個小型benchmark的測試結果，如表3所示。一般來說這幾個測試結果的可信度不如Spec，PARSEC等大型測試程序。但是這種小型測試能夠輕松地在龍芯RTL測試平臺上運行，該測試平臺可以給定靜態(tài)時序分析結果，并通過RTL代碼仿真一顆芯片，而無需流片，使用更加方便。

所幸龍芯還公布了Spec CPU 2000的測試結果，如表4所示目前GS464E在1GHz頻率下的整數(shù)性能得分為762，相對上一代漲幅104%左右，浮點性能達到1125分，提升幅度更加驚人，達到278%。其整體性能已經(jīng)非常接近同為1GHz頻率，采用Sandy Bridge核心的Core i5 2300。

若以Spec CPU 2000的初步測試結果作粗略估計，龍芯的IPC還是比較樂觀的，但從另一面看龍芯還不能提前開香檳慶祝。從最新披露的消息來看，基于GS464E架構的龍芯處理器主要有3A2000、3B2000兩種。其中龍芯3A2000為單路四核桌面版本，龍芯3B2000則是支持雙路八核、四路十六核的服務器版本。由于是新架構的第一版產(chǎn)品，制造工藝仍舊是40nm，主頻只有1GHz左右?？紤]到頻率只有當今Intel、AMD處理器的1/3，因此新一代龍芯處理器總體的絕對性能大約僅為Haswell的20%～30%左右。何時能采用更先進的28nm工藝生產(chǎn)，能否在新架構上大幅提升工作頻率？還是一個大大的問號，龍芯仍有比較長的路要走。

成功不可能一蹴而就

據(jù)筆者了解到的消息，龍芯目前已經(jīng)打入了軍方和航天市場，這兩個市場都對安全性極為重視，性能要求則相對比較寬松，龍芯的抗輻照版本問世后也裝上了北斗衛(wèi)星。中國那段由國家領導人親自出馬談判進口抗輻照芯片的過去可以宣告埋入歷史塵埃了，但龍芯要在民用市場上對抗Intel和AMD還是很難，畢竟絕對性能上差距過大，在短期內(nèi)恐怕仍無可能。

龍芯項目啟動迄今已過十五年，有過明察秋毫拒絕使用超長指令字結構的睿智，但也同樣有過不知深淺“一步到位”的狂熱；有過在媒體上放話打敗Intel的自負，也有過公開承認性能差距過大的誠懇，這些都已經(jīng)是龍芯成長歷程中被凝固的筆墨。

時過境遷，筆者認為，對待今日龍芯的進步，我們需要拋開過往，保持足夠冷靜和理智，如計算所的前任所長李國杰院士2004年就在《科技日報》上撰文指出的那樣：

“我國CPU/SoC設計任重道遠”，“今后若干年內(nèi)，龍芯CPU的性能只能做到國外最高水平CPU性能的一半左右”，要時刻清醒地認識到在這個國外已經(jīng)發(fā)展超過五十年（以亂序執(zhí)行發(fā)明的時間計算）。有十萬至數(shù)十萬頂尖水平從業(yè)者支撐的行業(yè)里面，龍芯以區(qū)區(qū)數(shù)百人的規(guī)模和幾十分之一到幾百分之一的投入做到幾分之一的性能已經(jīng)足堪自豪，至于追平和趕超，還是需要耐心。

不久前中國計算機協(xié)會舉辦的走進龍芯活動中，龍芯項目負責人胡偉武坦誠“乞丐與龍王比寶，越比越落后”，希望“重視整機性能，在每一個局部都不如別人的情況下實現(xiàn)整機性能的反超”，龍芯目前已經(jīng)將自己走向“支柱型CPU產(chǎn)業(yè)”的規(guī)劃劃到了2020～2030年，這將會是一場曠日持久的大戰(zhàn)。

如果成功了，中國CPU產(chǎn)業(yè)將多出一位內(nèi)能自給自足，外能力拼英美的巨頭，即便失敗，以龍芯項目這些年的投入，以及作為第一個國產(chǎn)亂序多發(fā)射高性能CPU的先驅所貢獻的經(jīng)驗和培養(yǎng)的人才來說，亦是能夠有所慰籍的。