稍有年紀的讀者，還記得20 多年前，在電腦中心隨處可見的Sun Ultra 系列工作站，那高貴的Sony 特麗霓虹顯像屏幕、聽說手感還不錯的鍵盤、戲稱為「Slow -Laris」的Solaris 操作系統與里面的心臟：UltraSPARC 處理器嗎？
頭發綁馬尾的Jonathan Ian Schwartz 在任職Sun CEO期間，沒事就在官方部落格長篇大論左批HP 右打IBM，更是當時資訊業界與科技媒體茶余飯后的必聊話題。
2008 年4 月20日，Sun 董事會通過決議，同意將以每股9.5 美元價格，將這間擁有UltraSPARC 處理器、Solaris 操作系統、ZFS 文件系統、Java 程序語言、MySQL數據庫、效能分析工具DTrace、龐大的服務器工作站產品線、無數大型企業客戶、無數軟硬件創新（如無人不知的NFS 網絡文件系統和大型多處理器服務器）的硅谷知名公司，出售給以數據庫與ERP 聞名于世的Oracle。
當時坊間輿論亦不乏對此購并案的擔憂，但看在「Oracle大多數數據庫產品都運行在Solaris，且往往跑得還比IBMAIX 還快」份上，加上Oracle 從此晉升為「軟硬兼備」的強權，足以跟IBM 分庭抗禮，所以外界仍抱著「審慎樂觀」態度。
不過很不幸的是，繼在2017年初全球大裁員先砍了一批人，主管舊Sun產品線的系統部門執行副總裁John Fowler，8月2日因不明原因離職，2017年9月初，Oracle更一口氣裁撤所有SPARC處理器與Solaris操作系統的964人，曾在互聯網萌芽時代高懸天際的Sun，終究難逃隕落下場。
那時候網絡也不缺替Oracle「洗白」的言論，像「產品計劃表還有『SPARC.Next』和『Solaris.Next』這些未來產品」、「Fujitsu 還是會繼續推出新SPARC64 處理器」、「Solaris 11.5 還是會在2019 年準時發表」，連「Solaris 的技術支持時限直到2034 年」這種借口都講得出口。然后隨著時間流逝，Solaris 11.4 已是將近兩年前的往事，Solaris 12 則看來永遠不會出現。曾幾何時，這譽為「最普及的商用RISC 處理器與Unix 操作系統」無以為繼，讓人不勝唏噓。
Oracle之所以購并Sun，以事后諸葛的角度，看似無心永續發展技術與價值，反而更像利用Sun多年累積的龐大專利權和商標權，讓公司法務部門到處訴訟，狂找其他公司「討債」，例如控告Google在Android手機使用JavaAPI索賠90億美元，結果敗訴。原本今年3月Google和Oracle要在美國最高法院大決戰，因新冠肺炎影響，繼續一拖再拖。
法國漫畫家Manu 曾在2010 年，畫了好幾張「奇葩組織圖」一次調侃蘋果、Google、Oracle、微軟、Facebook、亞馬遜這6 家超級公司，Oracle 這張似乎冥冥之中預言了Sun 的命運。
「相對開放才有出路」的年代
成立于1982 年2 月、全名源自「Stanford University Network」的Sun Microsystems，因3 位創辦人都是斯坦福大學研究生，從誕生到消失，一直保有濃濃的學術味。十幾年前，Sun 尚未被Oracle 購并時，曾有Sun 高級主管當面對筆者這樣形容他們的企業文化：這間公司感覺就很像大學。
從21 世紀開始，「開源軟件」和「開放系統」成為不可質疑的政治正確，你不使用「日用品」等級的x86 指令集兼容處理器或開源操作系統，就是「不夠開放」，而1980 年代以雨后春筍之勢蓬勃發展的Unix 操作系統與他們的RISC 服務器平臺，就紛紛被貼上「昂貴封閉」標簽。但諷刺的是，所謂的「開放」到頭來也只是相對概念，Sun 能從工作站市場發跡，就是因為「比較放得開」。
這里不得不先提那時的工作站（Workstation）市場。成立于1980 年的Apollo Computer（容易讓人誤認為阿波羅登月計劃的導航電腦）是這領域的先驅者，而工作站其實就是比較高端的通用微型電腦，特別是遠優于一般個人電腦的圖形處理能力，而電腦輔助設計（ComputerAided Design，CAD）就剛好是最適當的需求。知道Autodesk這間公司在做什么的，應該清楚這種應用的大致樣貌。
Apollo Computer 最大的客戶，也不外乎像電子輔助設計工具業者（Mentor，現今EDA 工具三大巨頭之一，僅次于Cadence 與Synopsys，在2017 年被德國西門子以45 億美元現金收購）、汽車業（通用汽車、福特、克萊斯勒）和航空業（波音）等。
即使Apollo Computer 初代產品DN100 工作站采用的處理器，是普及到不能再普及的Motorola 68000，但仍難擺脫1970 年代的「遺風」，軟硬件規格都具強烈封閉性，除了專屬硬件規格，連操作系統也是僅提供類似Unix 操作指令的Aegis / Domain。不過Sun 就完全相反，一開始就選擇「開放」，不生產定制化硬件，不同工作站都使用統一Unix 操作系統，再授權給不同公司制造產品。
憑著標準化軟硬件，讓Sun 更容易打造價格更低的產品，快速進入市場。短短幾年，Apollo Computer 很快就被Sun 和DEC 超車，失去工作站市場的龍頭地位。1987 年推出的Sun-4 首度成為采用SPARC 指令集兼容處理器的工作站，當年Sun 也躍升為工作站市場老大，從1985 年到1989 年，年復合成長率是美國企業最高的145%。Apollo Computer 則在1989 年被HP 以4 .76億美元（相當于2019 年的9 億8,200 萬美元）代價購并，慢慢轉形成HP 高效能運算產品線品牌之一。
當然，也可以自行解釋成「學生創業就是這樣，像什么有名大站和電玩小站，還不是起源于放在學生宿舍或研究室、腳邊隨時都會不小心踢到而掛站的DIY 電腦」 。Sun 創辦人之一AndyBechtolsheim 設計的Sun-1 工作站，第一批的部分器件還是從斯坦福電腦科學系弄來的，你不「開放一點」根本沒有其他出路。
這種起源于學校的開放思想背景，自然也影響了Sun 自行研發的RISC 指令集處理器。Sun 在1984年開始進行SPARC（Scalable ProcessorArchitecture，可擴展式處理器架構）指令集研究，開發顧問則是大名鼎鼎的David Patterson，他是兩本必讀電腦架構圖書的的作者、RISC的創造者、RISC-V 的發起者。2018年3月22日， DavidPatterson因開發了RISC微處理器并且讓這一概念流行起來的工程師獲得了2017 ACM圖靈獎。
SPARC 深受早期RISC「精簡」思潮熏陶，希望所有運算動作都可單時鐘周期搞定并高度流水線化，像整數除法之類的「復雜」指令就付之闕如，透過重復的簡單運算取代之，這部分到了1990 年的SPARC v8 才補完。
Sun 在1986 年發表32 位元的SPARC v7 指令集，但Sun并不像其他廠商自己做芯片，而是開放出來并定義嚴謹版本，讓其他廠商也能研制SPARC 指令集的兼容處理器，1987年問世的Sun-4 系列工作站，處理器來源是日本Fujitsu 與Cypress（分別搭配來自Weitek 和TI 的浮點輔助運算器）；世界首顆實做出來的SPARC 指令集兼容處理器，也并非出自于Sun，而是1986 年的Fujitsu MB86900。
1995 年SPARC v9 擴充到64 位元與SIMD 指令集VIS（Visual Instruction Set），Sun 跟Fujitsu 在2002 年聯合提出JPS（Joint Programming Specification）規范并持續演進到UA（UltraSPARC Architecture）、OSA（Oracle SPARC Architecture ）和Fujitsu 自行定義的高效能運算HPC-ACE（High Performance Computing – Arithmetic Computational Extensions）。
不限指令集架構，SPARC 也出現開放VHDL 語言原始碼的LEON 處理器系列（使用針對嵌入式應用而生的SPARC v8E 指令集），采用LGPL 授權，并由非營利SPARC International 組織負責管理。Sun 日后也陸續開源UltraSPARC T1 與T2，成為OpenSPARCT1、S1（單核心的T1）和OpenSPARC T2，讓更多人發出「啊，原來某種處理器技術的實做細節是長這樣，教科書和技術文件根本不會教你怎么下手」的感慨。
總之，有別于80×86世界多年來遲遲缺乏公定版本的亂象，關于電腦最基礎「語言」的指令集架構，SPARC一直都有統一標準。也因此，SPARC指令集兼容處理器的發展史，踩滿了眾多廠商的足跡，讓歷代SPARC處理器的型號總數，秒殺同時期的IBM Power（不算PowerPC）、DEC Alpha、HP PA- RISC及MIPS（如果只算高端處理器的話）等老對手。但這也讓公認當代最強大的SPARC指令集兼容處理器，并非出自創造SPARC的Sun，而是日本Fujitsu。
如果還記得現在x86指令集兼容處理器的戰場，扣掉英特爾、AMD雙雄加上臺灣VIA的Centaur，還有一間俄羅斯 Elbrus，所屬的MCST公司全名就叫「Moscow Center for SPARC Technologies」（莫斯科SPARC技術中心），持續研制一系列應用在俄系軍事武器的SPARC處理器。
然后網絡也隨處可見將「指令集架構」與「處理器微架構」混為一談的高論，講得好像Fujitsu、Cypress 和TI（德州儀器）這些公司「授權生產Sun 設計的SPARC 處理器」，但根本就不是這么一回事。如同英特爾和AMD 在x86 指令集兼容處理器的地位，Sun 和Fujitsu 身為高效能SPARC指令集兼容處理器的兩大主角，兩邊的處理器微架構方向根本大相徑庭，一邊沖多核心多線程，另一邊則是把RISC 處理器當成大型主機來做，不會有人敢說技術源流來自HAL 和Ross 的FujitsuSPARC64 系列，是Sun 授權的「設計」。
SPARC 歷代指令集版本文件封面那句大大的「OneArchitecture……Multiple Innovative Implementations」（統一的指令集架構，多種創新的微架構實作），就是最佳寫照，只是傻傻分不清楚的人還是繼續看不懂。
源自「寄存器窗口」的可延展性
SPARC 指令集里那個「可擴展」（Scalable），起因于獨特的「寄存器窗口」（Register Window），亦可見于Berkeley RISC、AMD Am29000、英特爾i960 與Itanium，即使名稱可能有點不同。
當處理器碰到中斷（如外部I/O 呼叫）、例外（像算術溢位）、進程切換，須將當前的執行狀態，包含所有可存取的寄存器，都以事先定義好的數據結構回存到存儲器，如x86 指令集的TSS（TaskStatus Segment），當恢復先前狀態，再從存儲器載回處理器。
因近代程序架構都高度模組化，不同副程序間的呼叫動作（SubroutineCall），也會造成頻繁的上下文切換（Context Switch），增加寄存器和存儲器間的數據傳輸量。過于龐大的「可見」寄存器數量，也會增加處理器的電路復雜度與上下文切換的負擔，并危害到提升處理器運行時鐘的延展性。
那該如何降低上下文切換的負擔，減少多余的內容值交換？以「空間換取時間」的Register Window 為此而生。ARM 指令集的Banked Register 也是類似方法。英特爾Itanium 處理器的IA-64 指令集也具備相同的機制，但命名為Register Stack，看似比較貼切。
Register Window 藉由「重疊」不同程序使用的寄存器，即可交換不同程序的數據，但「軟件眼中隨時可見」的寄存器數量仍為32 個，8 個全域（Global），剩下24個當作Register Window，8 個輸入（In）、8 個區域（Local）、8 個輸出（Out），邏輯上可視為一個巨大堆疊，Register Window 指標器（CWP）一次移動16 個寄存器的距離，前一個程序的輸出變成下一個程序的輸入，當程序切換時，無須將專屬于特定程序的8 個區域寄存器搬到存儲器，也減少了寄存器和存儲器之間的數據搬移量。
以下舉一個3 個Register Window 案例，一看就懂。
因此SPARC 指令集兼容處理器的「實際」通用寄存器數量是可變的，從力求最低成本的嵌入式應用到重視多工效率的服務器，一般介于72~640。假如想要追求副程序互通有無的效率，也愿意付出較多硬件成本（像8 個Register Window 的UltraSPARC I，144 個寄存器擁有多達7 個讀取埠和3個寫入埠）， Register Window 數量就多多益善，但假若想要減少電路成本、又想縮短發生上下文切換的處理負擔，那就少一點剛剛好。SPARC 名中的「可延展」之意即在此，和日后為人稱道的「多處理器延展性」一點關系都沒有。
效能最好的SPARC 處理器并非出自Sun
由于本文主角是Sun，后面將聚焦服務器與工作站處理器。但隨著時間流逝，一般坊間評價「最好的SPARC 指令集兼容處理器」卻不是來自「Sun 本家」，而是日本Fujitsu（與1990 年代的Ross和HAL），直到Oracle 擺明不玩、只剩下這間日本公司，別無分號為止。
先從指令集版本的演進，用一個表格畫出SPARC 發展史的大致輪廓，至于型號相同、制程不同的微縮版就在此不論（UltraSPARC 歷代出現過大量的制程改進版本）。如前面所述，Sun 讓SPARC 指令集成為「充分開放的業界標準」，除了Fujitsu 為了高效能運算而自定義的HPC-ACE，理論上所有SPARC 處理器，皆可兼容先前所有SPARC 指令集。
但在踏入主要SPARC 處理器歷史前，筆者必須先理清Sun 和其他SPARC 處理器廠商的最大思想差異，這也是「軟件色彩極度濃厚」的Sun，與「高效能處理器傳統路線」的Fujitsu最大的不同點。
對于21 世紀初期略聞SPARC 處理器的讀者，應經歷過Sun 與Fujitsu 兩家組成APL（AdvancedProduct Line）聯盟的歷史。Sun 的處理器日程表上演大風吹，取消雙核心UltraSPARC II「Gemini」及UltraSPARC V「Millennium」，轉戰「超多簡單核心、超級多線程、巨量存儲器頻寬、目標鎖定網絡應用」的Throughput Computing，Fujitsu SPARC64 繼續專注「較少復雜核心、優秀單線程效能、大型主機等級可靠度、應對高效數據處理」，再彼此截長補短，采用對方的處理器推出服務器產品。
當時還被IBM 公開嘲諷APL 應改名為「Sujitsu」，這些年來，IBM 對SPARC 陣營的嘴炮攻勢，更是從來沒有停過。反正客戶永遠不嫌多，能挖來一個算一個。
那時剛好英特爾積極推動Itanium取代RISC處理器、x86處理器挾著64位元這個新兵器在服務器市場四處攻城掠地（AMD靠著Opteron在此崛起）、IBM的Power正展現無窮威力，坊間看法多半是「Sun本來就不擅長研發高效能處理器，加上先進半導體制程與產品研發的成本持續水漲船高，已無力維持高效能處理器的競爭優勢，不得不改弦易轍，另辟出路」，像UltraSPARC發展到第四代的2004年，依舊缺乏非循序指令預測執行能力，遠遠落后其他廠商，效能不如對手的事實，也充分展現于SPEC CPU等效能測試標竿的平庸表現。
但假若回顧Sun 這間公司的歷史──尤其身為Java 創造者的身分，以及長年研究高效能Java 處理器（像對SPARC 處理器發展影響深遠的MAJC，這以后會有專文介紹）的經驗─ ─他們「似乎」從來就不認同近代高效能處理器的諸多重大特色，如高度指令平行化、大型化多層快取存儲器、動態分支預測、非循序指令預測執行等，執行Java 這種虛擬機化物件導向程序語言時，能發揮多少實際效用。至于「地球最先進的服務器操作系統」Solaris 的優異多線程排程能力，更是Sun「膽敢」采取激進策略的信心來源。
換言之，Sun 更偏向以軟件角度，如Java 程序語言與Solaris 操作系統為出發點，思考最合理的處理器架構，結論就不外乎強化多線程和存儲器子系統效能。如果說以UltraSPARC T1 為起點的Throuhgput Computing 是「山不轉路轉」，還不如說是「發揚光大」，甚至「走火入魔」亦不為過。
從遙遙領先到苦苦追趕的歷程
軟硬兼備的Sun，在1980 年代工作站市場、1990 年代的服務器市場，均獲得極重大的成功，這從處理器業界效能指標SPEC CPU 的參考基準，即可略見一斑：SPEC CPU 95 是SuperSPARC ，SPEC CPU 2000 是UltraSPARC I，SPEC CPU 2006 則是時鐘296MHz 的UltraSPARC II。值得一提的是，有別于IBM、Intel、AMD 和DEC，Sun 沒有自建晶圓廠，自行研發的SPARC 處理器均交由TI 代工制造，被Oracle 購并后轉向臺積電。
但商業優異成就，卻難以掩蓋處理器研發進展逐漸脫隊的事實。如果和同期x86處理器（與諸多RISC老相好）相比，Sun的高端SPARC處理器發展史，可謂一部從「遙遙領先」到「苦苦追趕」的賽道紀錄。各位可好好喚醒塵封已久的回憶，回想一下那一年x86處理器有哪些讓你印象深刻的產品。
1992年的SuperSPARC（0.8μm制程，時鐘33-60MHz）：那時英特爾Pentium尚未上市。
1994年的SuperSPARC II（0.8μm制程，時鐘75-90MHz）：那年已經出現100MHz英特爾Pentium。
1995年的UltraSPARC I（0.47μm制程，時鐘143-167MHz）：英特爾推出x86歷史首次正面挑戰服務器市場的Pentium Pro，時鐘直撲200MHz，并具備原生四處理器架構與非循序預測指令執行。
當然，對那段往事稍有印象的人，也許會這樣指摘：人家UltraSPARC可是貨真價實的64 位元處理器（相較Pentium Pro 看起來很沒誠意的PAE-36），又有VIS 指令集和更強的多處理器延展性（像Enterprise 6500 服務器就塞了30 顆UltraSPARC I，Ultra 4000 工作站也有14 顆），但請稍安勿躁，讓我們繼續慢慢看下去。
1997年的UltraSPARC II（0.35μm制程，時鐘250MHz）：英特爾推出300MHz的Pentium II，而UltraSPARC II的微架構基本沿用UltraSPARC I。
1997 年的UltraSPARC IIi（0.35μm制程，時鐘270-360MHz）：整合PCI控制器的微幅改進版，從256kB激增到2MB的L2快取存儲器是最大的亮點。
1998 年的UltraSPARC IIi（0.25μm制程，時鐘333-480MHz）：當年6月時鐘400MHz的首款英特爾Xeon問世，x86世界總算有了服務器處理器專用的品牌。
2000 年的UltraSPARC IIe（0.25μm制程，時鐘400-500MHz）：AMD搶先在英特爾之前登頂1GHz大關。
2001 年的UltraSPARC III（0.18μm制程，時鐘600MHz）：0.18μm制程的英特爾Pentum 4 / Xeon時鐘抵達2GHz。同年發表的UltraSPARC III Cu，終于靠著0.13μm制程和銅導線，沖破了1GHz，真是可喜可賀。
反觀同時期英特爾（P5→P6→P68）和AMD（K5→K6→K7）的飛躍性演進，UltraSPARC III 在微架構層面的改進幅度并不明顯，維持每個時鐘周期擷取解碼4道指令，仍然沒有非循序指令預測執行，僅略為擴增處理器內派發指令的寬度與管線深度與追加VIS 2 指令集。整合存儲器控制器是最實際的改善點，如同AMD 的K8 方法，大幅強化存儲器頻寬并縮減存取延遲。
但即使上市日期整整延宕2 年，原先設定要對抗DEC Alpha 21264 和英特爾Itanium 的UltraSPARC III 依然「藉由優秀的多處理器延展性」獲得那年MicroprocessorReport 的最佳服務器／工作站獎項，隔年則輪到原生雙核心的IBM Power4。
另外，取代Sun Enterprise 的Sun Fire 服務器產品線，也一起和UltraSPARC III 登場。Sun Fire 最令人稱道之處，莫過于美觀又易維護的優異機構設計，理念皆出自于「Sun天字第一號員工」Andreas Bechtolsheim 之手，其x86 服務器亦雨露均沾，有接觸過Galaxy系列AMD Opteron 產品線（以Sun Fire X4100 / X4200 為開端）的人，多半都印象深刻。
之后Sun Fire 和Fujitsu 的PrimePower，再一同被Sun / Fujitsu 攜手的SPARC Enterprise 品牌取代，2010 年后，再統一更名成SPARC M / T（與后來追加的S）系列。
Sun Fire 也是UltraSPARC 處理器在高端服務器的巔峰，Sun Fire 15K 最多支援106 顆UltraSPARC III Cu，而Sun Fire E25K 更是72 顆UltraSPARC IV（144核心）。
2002 年的UltraSPARC IIe+（0.18μm制程，時鐘550-650MHz）：0.13μm制程的英特爾Pentium 4 / Xeon已達3GHz。你沒看錯，到了這時候，UltraSPARC II還活著。
2003 年的UltraSPARC IIIi（0.13μm制程，時鐘1GH-1.6GHz）：這年AMD K8讓x86的世界深入64位元疆界，Opteron處理器品牌也從此改變了AMD與Sun的命運。
2004 年的UltraSPARC IV（0.13μm制程，時鐘1GH-1.3GHz）：UltraSPARC處理器擠身雙核心之列（等于2顆改良版UltraSPARC III），但已經看不到IBM的車尾燈，那年剛好是IBM Power5在高端服務器市場的效能戰爭橫掃千軍的高峰。
2004 年，Sun 宣布腰斬UltraSPARC V「Millennium」和雙核心UltraSPARC II「Gemini」，但已不值一提。
2005 年的UltraSPARC IV+（0.09μm制程，時鐘1.5GH-2.1GHz）：「傳統」UltraSPARC處理器的絕響，這時雙核心64位元英特爾Xeon和AMDOpteron已在服務器市場殺聲震天，再次確立x86處理器主導服務器市場和云端數據中心的大勢。
爬文至此，各位恐怕不難想見Sun 在21 世紀初期被「看衰小」的程度，也難怪會成為英特爾推動Itanium 取代「封閉RISC 系統」大戰略，第一個鎖定「挖墻角」的對象。在2005 年，英特爾扶植的Itanium 解決方案聯盟，啟動ISV Platform ExpansionProgram，透過Transitive 的QuickTransit二進位執行檔轉換技術，鼓勵既有使用SPARC 處理器／Solaris操作系統的用戶，轉移至Itanium 平臺。
更糟糕的還在后頭：SPARC 處理器陣營的另一位要角Fujitsu，不但在2005 年4 月發表Itanium 服務器PrimeQuest 產品線，還是采用自研系統芯片組、最大32 處理器64 核心的巨獸，秋季IDF（Intel Developer Forum）的Itanium 解決方案聯盟發表會，資深行銷副總裁Richard McCormack 更是第一位上臺開場致詞的來賓，剛好滿臉黑線的筆者有幸坐在臺下躬逢其盛。
理所當然的，英特爾勢必對Fujitsu 施以重金、誘之以利，大概又是什么行銷贊助基金之類的。每當筆者多次在公開場合碰到Fujitsu 相關人士，偷偷打探英特爾到底付了多少「補助津貼」，總是得到尷尬又不失禮貌的營業式微笑。隨著AMD「逼出英特爾研發x86 處理器的巨大潛能」而造就Itanium 邊緣化，PrimeQuest 也跟HP 的旗艦SuperDome 一樣，「轉進」到Xeon 處理器，沉沒的Itanic 號觀光郵輪，就再也沒有浮出水面。
邁向Throughput Computing
Sun 在2004 年逐步重整服務器產品布局，除了短暫推出英特爾Xeon 處理器的Sun Fire V60 系列，兵分三路，成果可簡述成以下數點：
- 通用型服務器：Sun成為率先壓寶AMD Opteron的一線服務器大廠，并推出「Galaxy」系列服務器，8顆Opteron的Sun Fire M4600為象征。這件事對AMD也意義深遠，不僅提升AMD驗證產品的能力，更強化企業用戶對「AMD服務器」的信心。
- 高效能服務器：與Fujitsu攜手APL（Advanced Product Line），沿用SPARC64系列，標榜大型主機等級的可靠性。
- 網站與數據庫：Sun購并Afara Websystems后，以追求「像瀑布般的巨大數據吞吐量」的Throughput Computing為名，集中資源打造針對網站服務器特化的UltraSPARC T系列（Niagara）與數據庫導向的UltraSPARC RK（Rock）。
其中最值得大書特書的就是奠定Sun SPARC 處理器發展方向的Throughput Computing：簡單多核心、超多線程、大量存儲器頻寬。
2005 年的UltraSPARC T1（0.09μm制程，時鐘1GH-1.4GHz）：8個簡單微架構核心（單指令派發）、32粗質線程（碰到存儲器存取等較長延遲，才會切換線程）。
臺灣最大的電玩資訊站巴哈姆特，曾測試Sun FireT2000 足足一周，一臺取代所有前端網站服務器群，瞬間涌入500 名使用者的系統反應時間，從8 秒縮短到0.3 秒，足以見證威力。但UltraSPARCT1 只有一個浮點運算器，不難想見針對網站服務器「最佳化」的程度。
2007 年的UltraSPARC T2（65納米制程，時鐘1~1.6GHz）：前者的強化版，線程倍增至64條，每個核心都擁有獨立的浮點運算器，因此整數運算加倍，浮點運算提升時倍，更高時鐘帶來1.4倍的單線程效能。后繼的UltraSPARC T2+則是追加4處理器延展性的版本。
2010 年取消的UltraSPARC RK，就是讓人感到極度惋惜的未竟之憾了，16 個4 指令派發的非循序預測執行核心（Sun 的歷史創舉），每個核心2 條同時多線程（SMT），總計切成4 塊共享1 個32kB 指令快取、2 個32kB 數據快取、2 個浮點運算器的叢集（Cluster），耗電量高達250W，也具備了更精細多線程存儲器數據同步的Transactional Memory（近似英特爾TSX）。
Sun 曾在UltraSPARC RK 砸了不少預算，也持續「堆高」規格，導致芯片開發到2.0 版。或許失控的功耗和經費，就是新東家Oracle 決定腰斬的主因。Oracle 接手Sun 后，「SoftwareIn Silicon」也成為最常喊的口號。
雖然無緣見證UltraSPARC RK 的實際威力，但Oracle 購并Sun 之后的SPARCT 系列，卻處處可見Rock 的殘影，并同時融合Niagara的色彩。像2011 年的SPARC T4，就是8 個雙指令派發、非循序預測執行的S3 核心（代表第三代SPARC 核心，并追加VIS 3 指令集），每個核心8 條同時多線程的產物，一路「核心堆堆樂」到12 核96 線程的SPARC M6。
SPARC M7 升級成具改良后的快取存儲器階層和VIS 4 指令集的S4 核心，演進到2017 年的32 核心256 線程的SPARC M8。
- 2010 年的SPARC T3：40納米制程，時鐘1.65GHz，16核128線程，可視為UltraSPARC T2的加倍版，然后SPARC Enterprise服務器品牌也取消，統一稱為SPARC T系列。
- 2011 年的SPARC T4：40納米制程，時鐘2.85~3GHz，8核64線程。
- 2013 年的SPARC T5：28納米制程，時鐘3.6GHz，16核128線程。
- 2013 年的SPARC M5：28納米制程，時鐘3.6GHz，6核48線程。
- 2013 年的SPARC M6：28納米制程，時鐘3.6GHz，12核96線程。
- 2015 年的SPARC M7：20納米制程，時鐘4.33GHz，32核256線程，S4核心。
- 2016 年的SPARC S7：20納米制程，時鐘4.27GHz，8核64線程，SPARC M7的低價微縮版。
下面呢？下面就沒有了。
順道一提，Sun 體系的SPARC 處理器，從40 納米制程的SPARCT3 開始，轉由臺積電生產，結束了Sun 與TI 的長期合作關系。
按部就班、穩扎穩打的Fujitsu SPARC64
既然Oracle 已確定中斷Sun SPARC 處理器的技術血脈，在1986 年打造出世界第一顆SPARC 指令集兼容處理器MB86900 的日本Fujitsu，就成為唯一碩果僅存的高端SPARC 處理器供應商。相對于「激進敢沖」的Sun，Fujitsu 可謂「傳統保守」，或許更精確一點，他們的訴求是把RISC 處理器，做成與大型主機一樣「高、上、大」。
但打從一開始僅專注嵌入式應用的Fujitsu，高效能SPARC 微架構也并非從頭做起，技術源流可追溯至以hyperSPARC 跟Sun 正面競爭的Ross（Cyress的子公司，后來被Fujitsu 取得技術與專利）和Fujitsu投資的HAL（由IBM Power 的主要設計者Andrew Heller 所創立，有趣的是，HAL 的3 個字母，下一個就是IBM）。
SPARC64 之名繼承自HAL，而在2001 年取消HAL 原案、基于FujitsuGS8900 大型主機而重新開發的SPARC64 V，則是Fujitsu在高端SPARC 處理器的最重要里程碑：四指令派發、非循序指令預測執行、大型主機等級的高可靠度，效能也明顯優于Sun UltraSPARC III。
值得一提的是，出自HAL 的初版SPARC64 V 是個指令平行化極寬（遠高于4 道指令）并具備和英特爾NetBurst 微架構大同小異的Trace Cache（依照分支預測的結果，依序存放解碼的指令執行序列），不幸與Sun 的UltraSPARC RK 一起變成消逝在歷史洪流的遺憾。
SPARC64 V 的后繼發展如下：
- 2004 年的SPARC64 V+：90納米制程，時鐘1.65~2.16GHz。
- 2007 年的SPARC64 VI：90納米制程，時鐘1.5~2.4GHz，雙核心，導入粗質多線程（CMT，Fujitsu稱為VMT），也是首款引進浮點乘積和指令的SPARC處理器。
- 2008 年的SPARC64 VII：65納米制程，時鐘2.4~2.75GHz，四核心，導入同時多線程（SMT），強化數據可靠性（整數寄存器數據透過ECC保護，錯誤檢查點增加到3,400個）。
- 2009 年的SPARC64 VIIIfx：45納米制程，時鐘2GHz，8核心，為了「京」（K）超級電腦計劃而生的高效能運算衍生款，追加Fujitsu自行定義的HPC-ACE指令集與256個浮點運算寄存器。
因為SPARC v9 指令集的編碼位元，不足以定址所有的浮點寄存器，256 個寄存器需要8 位元，浮點乘積和（FMA，A×B＋C＝D）指令會用到4 個寄存器，將會吃光32 位元編碼，連運算碼都沒地方放了，須在運算指令前，排入「補充」寄存器定址位元數的前置指令（SXAR）。
- 2010 年的SPARC64 VII+：65納米制程，時鐘提升到3GHz，L2快取加倍到12MB。
- 2011 年的SPARC64 IXfx：40納米制程，時鐘2.85GHz，16核心，配合PRIMEHPC FX10超級電腦而同步發表。總之，只要看到名稱內有那個小寫的fx就知道這是超級電腦特規版了。
- 2012 年的SPARC64 X：28納米制程，時鐘3GHz，16核心32線程，耗電量沖上270W，存儲器控制器也「搬家」到處理器內部了。
- 2013 年的SPARC64 X+：28納米制程，時鐘2~3.7GHz，16核心32線程，激增的時鐘也充分反應在高達392W的耗電量。
2014 年的SPARC64 XIfx：臺積電20納米制程，時鐘2GHz，34核心（32個運算加2個輔助），新增HPC-ACE2指令集。高度整合存儲器控制器與匯流排界面的SPARC64 XIfx堪稱SPARC世界第一顆超級電腦系統單芯片。
近期奪下Top500首位的日本理化學研究所超級電腦「富岳」，心臟Fujitsu A64FX，實際上就是將指令集架構，從SPARC v9和HPC-ACE2，替換成ARM v8.2A加SVE的進化版。
目前據聞Fujitsu 可能將在2020 年（也沒剩幾個月了）發表新一代SPARC64，就讓我們拭目以待，但也只能祈禱這不會是高端SPARC 處理器的絕響。
SPARC 還有未來嗎？
這是沒人敢打包票的大哉問，特別當Fujitsu 在A64FX 開了「用ARM 換掉SPARC」的第一槍，先不提軟件解決方案從哪里來，哪天想不開如法泡制，做出一顆貨真價實的高端服務器ARM 芯片，好像也不是太讓人感到奇怪的事，加上ARM 服務器最近好像聲勢又有點起色，多少會讓人懷疑「會不會哪天Solaris＋SPARC 將被Linux＋ARM 取而代之」 ，步上OpenVMS＋Alpha（DEC）、Irix＋MIPS（SGI）和HP-UX＋PA-RISC（HP）一個一個淡出舞臺的后塵。
平心而論，畢竟現有使用SPARC 服務器和Solaris 操作系統的客戶還是這么多（應該吧？），Oracle 也不可能不管商譽而棄之不顧，短期應該不必擔心「斷糧」（不是說好Solaris 的技術支援要維持到2034 年嗎？）。但正如x86 指令集的最重要價值，徹頭徹尾建立在「微軟Windows 兼容性」上，SPARC 指令集賴以維生的Solaris 操作系統，假以時日，「老兵不死，只是逐漸凋零」仍是極有可能成真的現實。
回顧SPARC 指令集兼容處理器30 年來大起大落，總讓筆者腦中回蕩著已故香港歌手羅文的臺視八點檔《八月桂花香》主題曲〈塵緣〉，歌詞那句「繁華落盡，一身憔悴在風里」，相信曾陪伴那票Sun 服務器工作站的讀者，心中多少也有類似感觸。昔日任何RISC 處理器家族無不像SPARC，在工作站和服務器，曾獨享極盛一時的繁華。
對親身體驗過那段互聯網大爆發年代的年長讀者，再多千言萬語，亦訴不盡Sun 這間神奇的公司，帶給各位的點點滴滴。往事歷歷在目，至少還記得電腦教室快要凍死人的冷氣。
但往好處想，最起碼當下SPARC 還活得好好的，總比Alpha、PA-RISC 和Itanium幸運太多太多了。不過在遙遠的將來，不會只剩下MCST 那票俄羅斯人在做軍用SPARC 處理器吧？
