十月達人之路「x86處理器發展史」連載第11集之「消失的一頁」

坦白講，昨天拿到雜誌後，看到從六頁砍成五頁，而且拿掉我認為最重要的一段，真的差點快昏倒了，不過看在原本沒辦法上稿、bobo好心將我的文章勉強塞到十月號的份上，想想就算了，沒什麼大不了。

簡單多核心與多執行緒並非完美無瑕

但這世界上沒有所謂「絕對」不變的準則，Google放砲是一回事，他們的觀點能否放諸天下而皆準，那又是另一回事。

首先，在相同時脈時，簡單的核心也代表著較差的單執行緒效能，有如銀行希望櫃台可以同時服務最多的客人，卻又不希望讓每個顧客都在櫃台前等太久，在「終極多執行緒輸出率」與「頂級單執行緒表現」中，勢必取得一個平衡點。

其次，要開發出兼具高效能與可靠度的多執行緒程式，其「驗證」的困難，遠超過一般人的想像。為提昇效能，會盡量希望同一塊資源，能盡其所能的被最多的執行緒所共用；但反過來，為確保安全性，最保險的作法，僅讓少數的執行緒存取相同的資源，甚至只讓單執行緒獨享。

想想個人電腦端與企業伺服器端的應用程式有著多驚人的價差（一套大型資料庫賣個幾百萬台幣也不是什麼新鮮事，更罔論大型製造業導入的ERP），就可以瞭解不同市場軟體開發成本的懸殊差異。越高檔的應用，軟體在整台電腦所佔的成本比例就越高。

耗電量則是另一個棘手的麻煩，用較多的「低時脈簡單核心」並不保證整顆處理器的耗電量就一定比較低。事實上，很多人老是喜歡把漏電流（leakage）和高時脈掛在嘴邊，講的好像製程縮小的耗電量問題「都是」該死的漏電流和「天殺」的高時脈造成的。

但他們忽略了一點：有別於可以透過深沉睡眠模式來「裝死省電」的個人電腦，對隨時得醒著的伺服器的需求來說，實作一個低時脈、高執行單元數的多核心，遭遇漏電流的問題機率處理器的運作功耗，其實多半都比一個高時脈、較低執行單元數的較少核心產品來得高，用來連結晶片內大量核心的內部匯流排與交換器結構（Switching Fabric），難道就不是狂吃晶片面積的巨大耗電黑洞？更何況，越多的核心對記憶體頻寬更加嗷嗷待哺，更多的I/O與記憶體介面腳位，也更難縮小晶片的面積。

也許讀者看到這裡腦筋會有點轉不過來，積體電路進一步微型化所面臨的最大問題，竟然是毫不起眼、用來連接晶片上所有元件的細微金屬線？從高度摻雜的矽、矽化物到金屬，許多材料都可以用來做導線。連線的主要問題來對於電流的電阻，與電線的電容，訊號傳過連線的延遲時間與所謂的RC因素，也就是連線的「電阻與電容的乘積」有關。

我們假設將晶片的製程縮小一倍，理論上晶片面積變成四分之一，連線長度也依照同樣的比例微縮，連線與氧化層的接觸面積縮小為原來的四分之一，考量到氧化層厚度也跟著變薄，估計整體電容降低約一倍，這看起來似乎不錯。但連線依照比例縮小，卻產生嚴重的電阻問題，因連線的截面積變小，使得電流更不容易通過連線，這時候截面積縮小四倍，電阻等於增加四倍，加上電阻也與連線長度成正比，長度減為一半，結果整體電阻將將是原先的兩倍，換言之，電阻增加的倍數和電容減少的倍數相同，意味晶片縮小了，連線延遲卻還是固定的，不但限制晶片的速率與縮小的幅度，更增加提高時脈後的耗電量。

一般來講，銅導線的電阻較鋁導線來得低，由IBM領軍，近十多年來高效能汎用處理器的連線材料已從鋁轉向銅，其因在此。但材料本身也有其物理極限，不能克服所有的困難。

像Sun近期發表的16核心/32執行緒/時脈2.1GHz的UltraSPARC RK「Rock」，晶片面積僅比同為65nm製程的四核心SPARC64 VII「Jupiter」還小一點，但電晶體數卻少50%，且耗電量更是兩倍之譜，更別提SPARC64 VII是為了頂級可靠度，整顆處理器90%電路都可修正單位元錯誤的超精密巨獸。God　Father大大詳細介紹Intel用來挑戰NVIDIA/ATI繪圖霸權的「Larrabee」，在16核心/64執行緒/2GHz時脈的組態時，耗電量也起碼150W，結構複雜的內部匯流排，絕對功不可沒。