臺北市
--°
( --° / --° )
氣象
2020-07-31 | 科技新報

時代的眼淚系列:繁華落盡的 SPARC 處理器

時代的眼淚系列:繁華落盡的 SPARC 處理器

「網路就是電腦」(The Network Is The Computer)這句格言,是在 1984 年,由 Sun 第 21 名員工 John Gage 創造。別說網路,在連個人電腦都尚未普及的年代,如此獨樹一幟的另類論點,恐怕讓不少人「想問候小朋友」,但今日雲端運算普及,卻充分印證了 Sun 的另類觀點,的確高瞻遠矚。

時代的眼淚系列:繁華落盡的 SPARC 處理器

時代的眼淚系列:繁華落盡的 SPARC 處理器

稍有年紀的讀者,還記得 20 多年前,在電腦中心與資訊教室隨處可見的 Sun Ultra 系列工作站,那高貴的 Sony 特麗霓虹映像管螢幕、聽說手感還不錯的鍵盤、戲稱為「Slow-Laris」的 Solaris 作業系統與裡面的心臟:UltraSPARC 處理器嗎?頭髮綁馬尾的 Jonathan Ian Schwartz 在任職 Sun 執行長期間,沒事就在官方部落格長篇大論左批 HP 右打 IBM,更是當時資訊業界與科技媒體茶餘飯後的必聊話題。
時代的眼淚系列:繁華落盡的 SPARC 處理器

2008 年 4 月 20 日,Sun 董事會通過決議,同意將以每股 9.5 美元價格,將這間擁有 UltraSPARC 處理器、Solaris 作業系統、ZFS 檔案系統、Java 程式語言、MySQL 資料庫、效能分析工具 DTrace、龐大的伺服器工作站產品線、無數大型企業客戶、無數軟硬體創新(如無人不知的 NFS 網路檔案系統和大型多處理器伺服器)的矽谷知名公司,出售給以資料庫與 ERP 聞名於世的 Oracle。

當時坊間輿論亦不乏對此購併案的擔憂,但看在「Oracle 大多數資料庫產品都運行在 Solaris,且往往跑得還比 IBM AIX 還快」份上,加上 Oracle 從此晉升為「軟硬兼備」的強權,足以跟 IBM 分庭抗禮,所以外界仍抱著「審慎樂觀」態度。
時代的眼淚系列:繁華落盡的 SPARC 處理器

很不幸的,繼在 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 作業系統」無以為繼,讓人不勝唏噓。
時代的眼淚系列:繁華落盡的 SPARC 處理器

Oracle 之所以購併 Sun,以事後諸葛的角度,看似無心永續發展技術與價值,反而更像利用 Sun 多年累積的龐大專利權和商標權,讓公司法務部門到處興訟,狂找其他公司「討債」,例如控告 Google 在 Android 手機使用 Java API 索賠 90 億美元,結果敗訴踢到大鐵板。原本今年 3 月 Google 和 Oracle 要在美國最高法院大決戰,因武漢肺炎(新冠肺炎,COVID-19)影響,繼續歹戲拖棚。

法國漫畫家 Manu 曾在 2010 年,畫了好幾張「奇葩組織圖」一次調侃蘋果、Google、Oracle、微軟、Facebook、亞馬遜這 6 家超級公司,Oracle 這張似乎冥冥之中預言了 Sun 的命運。
時代的眼淚系列:繁華落盡的 SPARC 處理器

(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 高效能運算產品線品牌之一。
時代的眼淚系列:繁華落盡的 SPARC 處理器

當然,也可以自行解釋成「學生創業就是這樣,像什麼有名大站和電玩小站,還不是起源於放在學生宿舍或研究室、腳邊隨時都會不小心踢到而掛站的 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。
時代的眼淚系列:繁華落盡的 SPARC 處理器

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),當恢復先前狀態,再從記憶體載回處理器。
時代的眼淚系列:繁華落盡的 SPARC 處理器

因近代程式架構都高度模組化,不同副程式間的呼叫動作(Subroutine Call),也會造成頻繁的內文交換(Context Switch,亦可稱為「程序切換」或「上下文交換」),增加暫存器和記憶體間的資料傳輸量。過於龐大的「可見」暫存器檔案,也會增加處理器的電路複雜度與內文交換的負擔,並傷害提升處理器運作時脈的延展性。

那該如何降低內文交換的負擔,減少多餘的內容值交換?以「空間換取時間」的「暫存器轉轉樂」Register Window 為此而生。ARM 指令集的 Banked Register 也是類似方法。英特爾 Itanium 處理器的 IA-64 指令集也具備相同的機制,但命名為 Register Stack,看似比較貼切。
時代的眼淚系列:繁華落盡的 SPARC 處理器

Register Window 藉由「重疊」不同程序使用的暫存器,即可交換不同程序的資料,但「軟體眼中隨時可見」的暫存器數量仍為 32 個,8 個全域(Global),剩下 24 個當作 Register Window,8 個輸入(In)、8 個區域(Local)、8 個輸出(Out),邏輯上可視為一個巨大堆疊,Register Window 指標器(CWP)一次移動 16 個暫存器的距離,前一個程序的輸出變成下一個程序的輸入,當程序切換時,無須將專屬於特定程序的 8 個區域暫存器搬到記憶體,也減少了暫存器和記憶體之間的資料搬移量。

以下舉一個 3 個 Register Window 案例,一看就懂。
時代的眼淚系列:繁華落盡的 SPARC 處理器

因此 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 處理器

但在踏入主要 SPARC 處理器歷史前,筆者必須先釐清 Sun 和其他 SPARC 處理器廠商的最大思想差異,這也是「軟體色彩極度濃厚」的 Sun,與「高效能處理器傳統路線」的 Fujitsu(與族繁不及備載的眾多處理器廠商)最大的不同點。

對於 21 世紀初期略聞 SPARC 處理器的讀者,應經歷過 Sun 與 Fujitsu 兩家組成 APL(Advanced Product Line)聯盟的歷史。Sun 的處理器時程表上演大風吹,取消雙核心 UltraSPARC II「Gemini」及 UltraSPARC V「Millennium」,轉戰「超多簡單核心、超級多執行緒、巨量記憶體頻寬、目標鎖定網路應用」的 Throughput Computing,Fujitsu SPARC64 繼續專注「較少複雜核心、優秀單執行緒效能、大型主機等級可靠度、應對高效資料處理」,再彼此截長補短,採用對方的處理器推出伺服器產品。
時代的眼淚系列:繁華落盡的 SPARC 處理器

當時還被 IBM 公開嘲諷 APL 應改名為「Sujitsu」,這些年來,IBM 對 SPARC 陣營的嘴砲攻勢,更是從來沒有停過。反正客戶永遠不嫌多,能挖來一個算一個。
時代的眼淚系列:繁華落盡的 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 尚未上市。
時代的眼淚系列:繁華落盡的 SPARC 處理器

1994 年的 SuperSPARC II(0.8μm 製程,時脈 75-90MHz):那年已經出現 100MHz 英特爾 Pentium。

1995 年的 UltraSPARC I(0.47μm 製程,時脈 143-167MHz):英特爾推出 x86 歷史首次正面挑戰伺服器市場的 Pentium Pro,時脈直撲 200MHz,並具備原生四處理器架構與非循序預測指令執行。
時代的眼淚系列:繁華落盡的 SPARC 處理器

當然,對那段往事稍有印象的人,也許會這樣指摘:人家 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。
時代的眼淚系列:繁華落盡的 SPARC 處理器

1997 年的 UltraSPARC IIi(0.35μm 製程,時脈 270-360MHz):整合 PCI 控制器的微幅改進版,從 256kB 激增到 2MB 的 L2 快取記憶體是最大的亮點。

1998 年的 UltraSPARC IIi(0.25μm 製程,時脈 333-480MHz):當年 6 月時脈 400MHz 的首款英特爾 Xeon 問世,x86 世界總算有了伺服器處理器專用的品牌。
時代的眼淚系列:繁華落盡的 SPARC 處理器

2000 年的 UltraSPARC IIe(0.25μm 製程,時脈 400-500MHz):AMD 搶先在英特爾之前登頂 1GHz 大關。
時代的眼淚系列:繁華落盡的 SPARC 處理器

2001 年的 UltraSPARC III(0.18μm 製程,時脈 600MHz):0.18μm 製程的英特爾 Pentum 4 / Xeon 時脈抵達 2GHz。同年發表的 UltraSPARC III Cu,終於靠著 0.13μm 製程和銅導線,衝破了 1GHz,真是可喜可賀。
時代的眼淚系列:繁華落盡的 SPARC 處理器

反觀同時期英特爾(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 為開端)的人,多半都印象深刻。
時代的眼淚系列:繁華落盡的 SPARC 處理器

之後 Sun Fire 和 Fujitsu 的 PrimePower,再一同被 Sun / Fujitsu 攜手的 SPARC Enterprise 品牌取代,2010 年後,再統一更名成 SPARC M / T(與後來追加的S)系列。
時代的眼淚系列:繁華落盡的 SPARC 處理器

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 在高階伺服器市場的效能戰爭橫掃千軍的高峰。
時代的眼淚系列:繁華落盡的 SPARC 處理器

2004 年,Sun 宣布腰斬 UltraSPARC V「Millennium」和雙核心 UltraSPARC II「Gemini」,但已不值一提。
時代的眼淚系列:繁華落盡的 SPARC 處理器

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 更是第一位上台開場致詞的來賓,剛好滿臉黑線的筆者有幸坐在台下躬逢其盛。
時代的眼淚系列:繁華落盡的 SPARC 處理器

理所當然的,英特爾勢必對 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:簡單多核心、超多執行緒、大量記憶體頻寬。
時代的眼淚系列:繁華落盡的 SPARC 處理器

2005 年的 UltraSPARC T1(0.09μm 製程,時脈 1GH-1.4GHz):8 個簡單微架構核心(單指令派發)、32 粗質執行緒(碰到記憶體存取等較長延遲,才會切換執行緒)。

台灣最大的電玩資訊站巴哈姆特,曾測試 Sun Fire T2000 足足一週,一台取代所有前端網站伺服器群,瞬間湧入 500 名使用者的系統反應時間,從 8 秒縮短到 0.3 秒,足以見證威力。但 UltraSPARC T1 只有一個浮點運算器,不難想見針對網站伺服器「最佳化」的程度。
時代的眼淚系列:繁華落盡的 SPARC 處理器

2007 年的 UltraSPARC T2(65 奈米製程,時脈 1~1.6GHz):前者的強化版,執行緒倍增至 64 條,每個核心都擁有獨立的浮點運算器,因此整數運算加倍,浮點運算提升時倍,更高時脈帶來 1.4 倍的單執行緒效能。後繼的 UltraSPARC T2+ 則是追加 4 處理器延展性的版本。
時代的眼淚系列:繁華落盡的 SPARC 處理器

2010 年取消的 UltraSPARC RK,就是讓人感到極度惋惜的未竟之憾了,16 個 4 指令派發的非循序預測執行核心(Sun 的歷史創舉),每個核心 2 條同時多執行緒(SMT),總計切成 4 塊共享 1 個 32kB 指令快取、2 個 32kB 資料快取、2 個浮點運算器的叢集(Cluster),耗電量高達 250W,也具備了更精細多執行緒記憶體資料同步的 Transactional Memory(近似英特爾 TSX)。
時代的眼淚系列:繁華落盡的 SPARC 處理器

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 處理器

SPARC M7 升級成具改良後的快取記憶體階層和 VIS 4 指令集的 S4 核心,演進到 2017 年的 32 核心 256 執行緒的 SPARC M8。
時代的眼淚系列:繁華落盡的 SPARC 處理器

2010 年的 SPARC T3:40 奈米製程,時脈 65GHz,16 核 128 執行緒,可視為 UltraSPARC T2 的加倍版,然後 SPARC Enterprise 伺服器品牌也取消,統一稱為 SPARC T 系列。

時代的眼淚系列:繁華落盡的 SPARC 處理器

2011 年的 SPARC T4:40 奈米製程,時脈 85~3GHz,8 核 64 執行緒。

時代的眼淚系列:繁華落盡的 SPARC 處理器

2013 年的 SPARC T5:28 奈米製程,時脈 6GHz,16 核 128 執行緒。

時代的眼淚系列:繁華落盡的 SPARC 處理器

2013 年的 SPARC M5:28 奈米製程,時脈 6GHz,6 核 48 執行緒。

時代的眼淚系列:繁華落盡的 SPARC 處理器

2013 年的 SPARC M6:28 奈米製程,時脈 6GHz,12 核 96 執行緒。

時代的眼淚系列:繁華落盡的 SPARC 處理器

2015 年的 SPARC M7:20 奈米製程,時脈 133GHz,32 核 256 執行緒,S4 核心。

時代的眼淚系列:繁華落盡的 SPARC 處理器

2016 年的 SPARC S7:20 奈米製程,時脈 27GHz,8 核 64 執行緒,SPARC M7 的低價微縮版。

時代的眼淚系列:繁華落盡的 SPARC 處理器

2017 年的 SPARC M8:20 奈米製程,時脈 5GHz,32 核 256 執行緒,一顆怪物級的大晶片。

時代的眼淚系列:繁華落盡的 SPARC 處理器

下面呢?下面就沒有了。

順道一提,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。
時代的眼淚系列:繁華落盡的 SPARC 處理器

值得一提的是,出自 HAL 的初版 SPARC64 V 是個指令平行化極寬(遠高於 4 道指令)並具備和英特爾 NetBurst 微架構大同小異的 Trace Cache(依照分支預測的結果,依序存放解碼的指令執行序列),不幸與 Sun 的 UltraSPARC RK 一起變成消逝在歷史洪流的遺憾。
時代的眼淚系列:繁華落盡的 SPARC 處理器

SPARC64 V 的後繼發展如下:

2004 年的 SPARC64 V+:90 奈米製程,時脈 65~2.16GHz。
2007 年的 SPARC64 VI:90 奈米製程,時脈 15~2.4GHz,雙核心,導入粗質多執行緒(CMT,Fujitsu 稱為 VMT),也是首款引進浮點乘積和指令的 SPARC 處理器。

時代的眼淚系列:繁華落盡的 SPARC 處理器

2008 年的 SPARC64 VII:65 奈米製程,時脈 4~2.75GHz,四核心,導入同時多執行緒(SMT),強化資料可靠性(整數暫存器資料透過 ECC 保護,錯誤檢查點增加到 3,400 個)。

時代的眼淚系列:繁華落盡的 SPARC 處理器

時代的眼淚系列:繁華落盡的 SPARC 處理器

2009 年的 SPARC64 VIIIfx:45 奈米製程,時脈 2GHz,8 核心,為了「京」(K)超級電腦計畫而生的高效能運算衍生款,追加 Fujitsu 自行定義的 HPC-ACE 指令集與 256 個浮點運算暫存器。

時代的眼淚系列:繁華落盡的 SPARC 處理器

因為 SPARC v9 指令集的編碼位元,不足以定址所有的浮點暫存器,256 個暫存器需要 8 位元,浮點乘積和(FMA,A×B+C=D)指令會用到 4 個暫存器,將會吃光 32 位元編碼,連運算碼都沒地方放了,須在運算指令前,排入「補充」暫存器定址位元數的前置指令(SXAR)。
時代的眼淚系列:繁華落盡的 SPARC 處理器

2010 年的 SPARC64 VII+:65 奈米製程,時脈提升到 3GHz,L2 快取加倍到 12MB。
2011 年的 SPARC64 IXfx:40 奈米製程,時脈 85GHz,16 核心,配合 PRIMEHPC FX10 超級電腦而同步發表。總之,只要看到名稱內有那個小寫的 fx 就知道這是超級電腦特規版了。

時代的眼淚系列:繁華落盡的 SPARC 處理器

2012 年的 SPARC64 X:28 奈米製程,時脈 8GHz,16 核心 32 執行緒,耗電量衝上 270W,記憶體控制器也「搬家」到處理器內部了。

時代的眼淚系列:繁華落盡的 SPARC 處理器

2013 年的 SPARC64 X+:28 奈米製程,時脈 2~3.7GHz,16 核心 32 執行緒,激增的時脈也充分反應在高達 392W 的耗電量。

時代的眼淚系列:繁華落盡的 SPARC 處理器

2014 年的 SPARC64 XIfx:台積電 20 奈米製程,時脈 2GHz,34 核心(32 個運算加 2 個輔助),新增 HPC-ACE2 指令集。高度整合記憶體控制器與匯流排界面的 SPARC64 XIfx 堪稱 SPARC 世界第一顆超級電腦系統單晶片。
時代的眼淚系列:繁華落盡的 SPARC 處理器

近期奪下 Top500 首位的日本理化學研究所超級電腦「富岳」,心臟 Fujitsu A64FX,實際上就是將指令集架構,從 SPARC v9 和 HPC-ACE2,替換成 ARM v8.2A 加 SVE 的進化版。

時代的眼淚系列:繁華落盡的 SPARC 處理器

2017 年的 SPARC64 XII:台積電 20 奈米製程,時脈 25~4.35GHz,12 核心 96 執行緒(一個核心 8 執行緒,和 IBM Power9 一樣)。

時代的眼淚系列:繁華落盡的 SPARC 處理器

目前據聞 Fujitsu 可能將在 2020 年(也沒剩幾個月了)發表新一代 SPARC64,就讓我們拭目以待,但也只能祈禱這不會是高階 SPARC 處理器的絕響。

時代的眼淚系列:繁華落盡的 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)

最新科技新聞

延伸閱讀