「網路就是電腦」（The Network Is The Computer）這句格言，是在 1984 年，由 Sun 第 21 名員工 John Gage 創造。別說網路，在連個人電腦都尚未普及的年代，如此獨樹一幟的另類論點，恐怕讓不少人「想問候小朋友」，但今日雲端運算普及，卻充分印證了 Sun 的另類觀點，的確高瞻遠矚。
稍有年紀的讀者，還記得 20 多年前，在電腦中心與資訊教室隨處可見的 Sun Ultra 系列工作站，那高貴的 Sony 特麗霓虹映像管螢幕、聽說手感還不錯的鍵盤、戲稱為「Slow-Laris」的 Solaris 作業系統與裡面的心臟：UltraSPARC 處理器嗎？頭髮綁馬尾的 Jonathan Ian Schwartz 在任職 Sun 執行長期間，沒事就在官方部落格長篇大論左批 HP 右打 IBM，更是當時資訊業界與科技媒體茶餘飯後的必聊話題。
2008 年 4 月 20 日，Sun 董事會通過決議，同意將以每股 9.5 美元價格，將這間擁有 UltraSPARC 處理器、Solaris 作業系統、ZFS 檔案系統、Java 程式語言、MySQL 資料庫、效能分析工具 DTrace、龐大的伺服器工作站產品線、無數大型企業客戶、無數軟硬體創新（如無人不知的 NFS 網路檔案系統和大型多處理器伺服器）的矽谷知名公司，出售給以資料庫與 ERP 聞名於世的 Oracle。
當時坊間輿論亦不乏對此購併案的擔憂，但看在「Oracle 大多數資料庫產品都運行在 Solaris，且往往跑得還比 IBM AIX 還快」份上，加上 Oracle 從此晉升為「軟硬兼備」的強權，足以跟 IBM 分庭抗禮，所以外界仍抱著「審慎樂觀」態度。
很不幸的，繼在 2017 年初全球大裁員先砍了一批人，主管舊 Sun 產品線的系統部門執行副總裁 John Fowler，8 月 2 日因不明原因離職，2017 年 9 月初，Oracle 更一口氣裁撤所有 SPARC 處理器與 Solaris 作業系統的 964 人，曾在網際網路萌芽時代高懸天際的昇陽，終究難逃隕落下場。
那時候網路也不缺替 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 手機使用 Java API 索賠 90 億美元，結果敗訴踢到大鐵板。原本今年 3 月 Google 和 Oracle 要在美國最高法院大決戰，因武漢肺炎（新冠肺炎，COVID-19）影響，繼續歹戲拖棚。
法國漫畫家 Manu 曾在 2010 年，畫了好幾張「奇葩組織圖」一次調侃蘋果、Google、Oracle、微軟、Facebook、亞馬遜這 6 家超級公司，Oracle 這張似乎冥冥之中預言了 Sun 的命運。
（Source：Manu Cornet / CC BY-SA）
「相對開放才有出路」的年代
成立於 1982 年 2 月、全名源自「Stanford University Network」（史丹佛大學網路）的 Sun Microsystems，因 3 位創辦人都是史丹佛大學研究生，從誕生到往生，一直保有濃濃的學術味。十幾年前，Sun 尚未被 Oracle 購併時，曾有 Sun 高階主管當面對筆者這樣形容他們的企業文化：這間公司感覺就很像大學。
從 21 世紀開始，「開源軟體」和「開放系統」成為不可質疑的政治正確，你不使用「日用品」等級的 x86 指令集相容處理器或開源作業系統，就是「不夠開放」，而 1980 年代以雨後春筍之勢蓬勃發展的 Unix 作業系統與他們的 RISC 伺服器平台，就紛紛被貼上「昂貴封閉」標籤。但諷刺的是，所謂的「開放」到頭來也只是相對概念，Sun 能從工作站市場發跡，就是因為「比較放得開」。
這裡不得不先提那時的工作站（Workstation）市場。成立於 1980 年的 Apollo Computer（容易讓人誤認為阿波羅登月計畫的導航電腦）是這領域的先驅者，而工作站其實就是比較高階的通用微型電腦，特別是遠優於一般個人電腦的圖形處理能力，而電腦輔助設計（Computer Aided 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 億 7,600 萬美元（相當於 2019 年的 9 億 8,200 萬美元）代價購併，慢慢轉形成 HP 高效能運算產品線品牌之一。
當然，也可以自行解釋成「學生創業就是這樣，像什麼有名大站和電玩小站，還不是起源於放在學生宿舍或研究室、腳邊隨時都會不小心踢到而掛站的 DIY 電腦」。Sun 創辦人之一 Andy Bechtolsheim 設計的 Sun-1 工作站，第一批的部分料件還是從史丹佛電腦科學系弄來的，你不「開放一點」根本沒有其他出路。但如果再回味一次某些資訊業界創業名人的歷史，或多或少會感覺到，所謂的「學生英雄」似乎有那麼一點令人熟悉的相似性。
名列商用 RISC 處理器始祖精靈之一的 SPARC
這種起源於學校的開放思想背景，自然也影響了 Sun 自行研發的 RISC 指令集處理器。Sun 在 1984 年開始進行 SPARC（Scalable Processor Architecture，可擴展式處理器架構）指令集研究，開發顧問則是大名鼎鼎的 David Patterson，只要正統資訊科班出身，不可能不知道這位兩本必讀電腦組織結構的作者、RISC 之名的創造者、RISC-V 的發起者。
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，成為 OpenSPARC T1、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 的 Fujitsu SPARC64 系列，是 Sun 授權的「設計」。
SPARC 歷代指令集版本文件封面那句大大的「One Architecture……Multiple Innovative Implementations」（統一的指令集架構，多種創新的微架構實作），就是最佳寫照，只是傻傻分不清楚的人還是繼續看不懂。
源自「暫存器框格」的可延展性
SPARC 指令集裡那個「可延展」（Scalable），起因於獨特的「暫存器框格」（Register Window），亦可見於 Berkeley RISC、AMD Am29000、英特爾 i960 與 Itanium，即使名稱可能有點不同。
當處理器碰到中斷（如外部 I/O 呼叫）、例外（像算術溢位）、行程切換（多工應用環境），須將當前的執行狀態，包含所有可存取的暫存器，都以事先定義好的資料結構回存到記憶體，如 x86 指令集的 TSS（Task Status Segment），當恢復先前狀態，再從記憶體載回處理器。
因近代程式架構都高度模組化，不同副程式間的呼叫動作（Subroutine Call），也會造成頻繁的內文交換（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（Advanced Product 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 依然「藉由優秀的多處理器延展性」獲得那年 Microprocessor Report 的最佳伺服器／工作站獎項，隔年則輪到原生雙核心的 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 和 AMD Opteron 已在伺服器市場殺聲震天，再次確立 x86 處理器主導伺服器市場和雲端資料中心的大勢。
爬文至此，各位恐怕不難想見 Sun 在 21 世紀初期被「看衰小」的程度，也難怪會成為英特爾推動 Itanium 取代「封閉 RISC 系統」大戰略，第一個鎖定「挖牆角」的對象。在 2005 年，英特爾扶植的 Itanium 解決方案聯盟，啟動 ISV Platform Expansion Program，透過 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 Fire T2000 足足一週，一台取代所有前端網站伺服器群，瞬間湧入 500 名使用者的系統反應時間，從 8 秒縮短到 0.3 秒，足以見證威力。但 UltraSPARC T1 只有一個浮點運算器，不難想見針對網站伺服器「最佳化」的程度。
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 後，「Software In Silicon」也成為最常喊的口號。
雖然無緣見證 UltraSPARC RK 的實際威力，但 Oracle 購併 Sun 之後的 SPARC T 系列，卻處處可見 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 奈米製程，時脈 65GHz，16 核 128 執行緒，可視為 UltraSPARC T2 的加倍版，然後 SPARC Enterprise 伺服器品牌也取消，統一稱為 SPARC T 系列。
- 2011 年的 SPARC T4：40 奈米製程，時脈 85~3GHz，8 核 64 執行緒。
- 2013 年的 SPARC T5：28 奈米製程，時脈 6GHz，16 核 128 執行緒。
- 2013 年的 SPARC M5：28 奈米製程，時脈 6GHz，6 核 48 執行緒。
- 2013 年的 SPARC M6：28 奈米製程，時脈 6GHz，12 核 96 執行緒。
- 2015 年的 SPARC M7：20 奈米製程，時脈 133GHz，32 核 256 執行緒，S4 核心。
- 2016 年的 SPARC S7：20 奈米製程，時脈 27GHz，8 核 64 執行緒，SPARC M7 的低價微縮版。
- 2017 年的 SPARC M8：20 奈米製程，時脈 5GHz，32 核 256 執行緒，一顆怪物級的大晶片。
下面呢？下面就沒有了。
順道一提，Sun 體系的 SPARC 處理器，從 40 奈米製程的 SPARC T3 開始，轉由台積電生產，結束了 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 原案、基於 Fujitsu GS8900 大型主機而重新開發的 SPARC64 V，則是 Fujitsu 在高階 SPARC 處理器的最重要里程碑：四指令派發、非循序指令預測執行、大型主機等級的高可靠度，效能也明顯優於 Sun UltraSPARC III。
值得一提的是，出自 HAL 的初版 SPARC64 V 是個指令平行化極寬（遠高於 4 道指令）並具備和英特爾 NetBurst 微架構大同小異的 Trace Cache（依照分支預測的結果，依序存放解碼的指令執行序列），不幸與 Sun 的 UltraSPARC RK 一起變成消逝在歷史洪流的遺憾。
SPARC64 V 的後繼發展如下：
- 2004 年的 SPARC64 V+：90 奈米製程，時脈 65~2.16GHz。
- 2007 年的 SPARC64 VI：90 奈米製程，時脈 15~2.4GHz，雙核心，導入粗質多執行緒（CMT，Fujitsu 稱為 VMT），也是首款引進浮點乘積和指令的 SPARC 處理器。
- 2008 年的 SPARC64 VII：65 奈米製程，時脈 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 奈米製程，時脈 85GHz，16 核心，配合 PRIMEHPC FX10 超級電腦而同步發表。總之，只要看到名稱內有那個小寫的 fx 就知道這是超級電腦特規版了。
- 2012 年的 SPARC64 X：28 奈米製程，時脈 8GHz，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 的進化版。
- 2017 年的 SPARC64 XII：台積電 20 奈米製程，時脈 25~4.35GHz，12 核心 96 執行緒（一個核心 8 執行緒，和 IBM Power9 一樣）。
目前據聞 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 處理器吧？
（首圖來源：pixabay）
"少一點" - Google 新聞
July 31, 2020 at 08:02AM
https://ift.tt/2ErQPWX
時代的眼淚系列：繁華落盡的SPARC 處理器 - 科技新報 TechNews
"少一點" - Google 新聞
https://ift.tt/39xGrI1
Shoes Man Tutorial
Pos News Update
Meme Update
Korean Entertainment News
Japan News Update
Bagikan Berita Ini
0 Response to "時代的眼淚系列：繁華落盡的SPARC 處理器 - 科技新報 TechNews"
Post a Comment