Power and Programmability The Challenges of ExaScale Computing演講內容
星期五, 1月 06, 2012
星期三, 12月 15, 2010
星期一, 11月 22, 2010
星期日, 9月 12, 2010
星期六, 9月 11, 2010
星期四, 7月 29, 2010
星期六, 7月 10, 2010
星期六, 7月 03, 2010
星期三, 6月 30, 2010
星期日, 6月 27, 2010
[隨手亂畫] Intel x86 Pipeline History
星期四, 1月 14, 2010
差不多也該談談AMD這十多年來的x86微架構發展史了
昨天晚上一邊翻著磚塊、一邊看硬碟裡面，從學生時代至今，存放十多年堆積如山的PDF（目前21.6GB，當兵期間經歷過一次大滅絕）、一邊回顧自己過去數年來屢次大刺刺刊載在雜誌上的個人觀點（等價交換約數十萬稿費）、再一邊想到凌晨兩點多搞到遲遲無法入眠（結果上班狀況還真不是普通的差...），看在AMD Bulldozer和Bobcat終於問世的分上，也差不多該是對AMD的x86 CPU發展史，與Fusion大戰略，班門弄斧野人獻曝附贈痴漢裸奔的時候了。
工作壓力越大，反而越能激發靠著週末大清早起床長篇大論以逃避現實...呃，紓解煩悶的動力。我慢慢可以體驗Pat Gelsinger在Intel期間，明明忙得要死卻可以天天上教堂演講還拼命寫書的心情了。人總是要在極限狀態才能被激發出無窮的潛力。
不過離開iThome近三年，在產業界享受刺激生活兩年多而人間蒸發銷聲匿跡下落不明，應該不會有多少人記得「痴漢水球」到底是誰了吧，哈哈哈。
工作壓力越大，反而越能激發靠著週末大清早起床長篇大論以逃避現實...呃，紓解煩悶的動力。我慢慢可以體驗Pat Gelsinger在Intel期間，明明忙得要死卻可以天天上教堂演講還拼命寫書的心情了。人總是要在極限狀態才能被激發出無窮的潛力。
不過離開iThome近三年，在產業界享受刺激生活兩年多而人間蒸發銷聲匿跡下落不明，應該不會有多少人記得「痴漢水球」到底是誰了吧，哈哈哈。
星期日, 11月 22, 2009
星期一, 9月 14, 2009
星期六, 8月 22, 2009
星期五, 8月 21, 2009
星期四, 7月 02, 2009
[2009/7/2雜談] 終於讀完人月神話了
外科手術團隊... 我應該是躺在手術檯上的那個吧...
最近整理書架時，意外「發現」當年拿免費卻一直未讀的人月神話，用三天上下班搭捷運的時間看完，感觸頗深，基本上，不只大型軟體專案，做任何事情也都是基於相同的道理，特別對這半年來深陷開案風暴和組織運作爭議的本人來說，讀起來格外「有fu」。呃，我怎麼講話越來越鄉民了？
不過，讓我感慨的是，人家老美的專案管理概念已經進化到幾乎等同於四十年前就登陸月球、現在準備直奔火星蓋基地的程度，但今天的台灣的產業界，卻多得是坐井觀天、卻又具有莫名其妙的強烈自信、還躲在山洞裡面造輪子整天幻想搞大外星美女肚子的夜郎。
就算不提工作，最起碼，也增進不少我對IBM S/360的認識（我曾經花不少時間研究IBM的mainframe），以及從那個年代至今的軟體工業發展歷程，如果早個幾年看完，我應該會修正過去對某些事情的偏見。這絕對不是豪洨。
明天開始看宣揚「Google教義」的網路巨變元年好了...我到底還有多少中文閒書買了根本沒看啊？
最近整理書架時，意外「發現」當年拿免費卻一直未讀的人月神話，用三天上下班搭捷運的時間看完，感觸頗深，基本上，不只大型軟體專案，做任何事情也都是基於相同的道理，特別對這半年來深陷開案風暴和組織運作爭議的本人來說，讀起來格外「有fu」。呃，我怎麼講話越來越鄉民了？
不過，讓我感慨的是，人家老美的專案管理概念已經進化到幾乎等同於四十年前就登陸月球、現在準備直奔火星蓋基地的程度，但今天的台灣的產業界，卻多得是坐井觀天、卻又具有莫名其妙的強烈自信、還躲在山洞裡面造輪子整天幻想搞大外星美女肚子的夜郎。
就算不提工作，最起碼，也增進不少我對IBM S/360的認識（我曾經花不少時間研究IBM的mainframe），以及從那個年代至今的軟體工業發展歷程，如果早個幾年看完，我應該會修正過去對某些事情的偏見。這絕對不是豪洨。
明天開始看宣揚「Google教義」的網路巨變元年好了...我到底還有多少中文閒書買了根本沒看啊？
星期五, 5月 29, 2009
星期日, 5月 24, 2009
[新書入手] P&H白算盤第四版
當初第三版變薄，說想讓學生上課時比較好攜帶，結果第四版章節變少，厚度和重量卻又再度和第二版看齊，嘖。嗯...啊...反正白算盤第四版在5/20已經出現在天瓏的架上了，一本1200，看到內容章節會覺得很興奮的人還是快點入手比較好。
不過，姑且先不論書中同時用Roofline model分析比較Intel Clovertown E5345、Sun Niagara2、AMD Barcelona 2356和IBM Cell QS20的雙CPU組態，以及John Nickolls與David Kirk操刀的附錄A，倒是有一點無損全書價值的小錯誤：
Nehalem的die photo解說圖，很明顯參考Chip-Architect早期的錯誤圖解，因為Write Buffer變成L2 cache了...
反正無論如何，GPU正式變成標準教科書的內容，也是好事一樁，最起碼，以後應該不會再看到一票「只要把晶片叫做GPU，就可以無視物理法則、製程限制、軟體瓶頸和程設典範」的詭異謬論了。
星期日, 5月 17, 2009
[隨手亂畫]根據AMD新版SSE5修正圖片...
感謝AMD的「迷途知返」，這下子我又得大改一堆圖片了，哇哈哈～昨天跑新竹參加公司運動會，和同事跑去南寮吃海產，回台北又東跑西跑處理事情，累個半死，早上起床才勉強有力氣畫圖，唉。
這次修正如下：
1. 增加AMD新版SSE5。
2. 修正之前的錯誤，像AVX的Immediate竟然變成2 Bytes...
3. 增加版本控管，因為實在改太多次了。
4. 增加新舊SSE5/AVX/LRBni比較表。
等六月搞定一堆麻煩事，就開始畫顯示晶片的指令集吧...不知道Intel何時才會公佈LRBni的編碼結構，這玩意的設計到底好不好，到時候就知道了。
這次修正如下：
1. 增加AMD新版SSE5。
2. 修正之前的錯誤，像AVX的Immediate竟然變成2 Bytes...
3. 增加版本控管，因為實在改太多次了。
4. 增加新舊SSE5/AVX/LRBni比較表。
等六月搞定一堆麻煩事，就開始畫顯示晶片的指令集吧...不知道Intel何時才會公佈LRBni的編碼結構，這玩意的設計到底好不好，到時候就知道了。
星期五, 5月 15, 2009
嗯嗯，啊啊...
向日葵教授 提到...嗯啊，我懶得去翻硬碟裡面的pdf了，隨便用Google喚起模糊的回憶。
Rock團隊也不知道在幹什么。
65nm的設計，拖到現在都看不到。
哇塞！超過兩年了耶！
In Jan 2007, Sun announced the tape-out of Rock.[12]
In April 2007, Sun CEO Jonathan I. Schwartz blogged an image of a fabricated and BGA-packaged Rock chip, labeled UltraSPARC RK, and disclosed that it can address 256 terabytes of virtual memory in a single system running Solaris.[13]
In May 2007, Sun announced the first silicon of Rock booting Solaris successfully.[14]
As a result of the ISSCC more information is coming out.[15]
Rock Arrived(2007/4/10)
Sunがサーバー向けハイエンドプロセッサ「Rock」の概要を公表(2008/2/4)
當然，這種算是很高檔、而且針對特定應用程式最佳化的server CPU，從CPU試作品到實際系統產品整機出貨有很大的時間差，也不是什麼讓人訝異的事情，更何況Rock最少也有2.0版了。
不過我很期待Rock（尤其當幕後黑手Oracle併購Sun之後）跑database和ERP的表現，如果真的可以做到Sun當初的預期，那高階server市場的遊戲規則可能就要被改寫，特別是製造業用的機器。
1. 一看到名稱，就認定因為AMD命名SSE5，而且維持128 bits XMM register，所以就只是過去SSE的結構性延伸：
這點完全是錯的。
AMD想克服自己搞出來的REX大包，順便弄出3 operand format/4 operand syntax，大規模更動encoding結構，光這點就可以讓這種「直覺反應」完全不成立。講難聽一點，AMD搶先註冊SSE5只是故意搞Intel一下，200%的行銷宣傳目的。
2. AVX對SSE5的優越性僅有「256 bits YMM vs 128 bits XMM」：
這點也完全是錯的。
Intel發展AVX的最主要目的，並不是只為了新增256bits YMM與後來被取消的4 operand format，而是想進一步克服x86指令encoding系統的老問題。如此一來，Intel未來的產品設計就可精簡Front-end，降低耗電量，保留日後更寬issue rate的延展性。
但AMD SSE5完全是疊床架屋，為了解決REX，卻又創造出複雜的DREX + Opcode3結構，人家Intel都把所有重要資訊集中在前方的VEX了，一收到就馬上開工，你卻要讀取大半個指令再玩配對遊戲，然後SSE5的1/2 operand指令encoding方式簡直讓我看到髒話都快罵出來，毫無邏輯可尋，要我畫出圖解根本是一種虐待。
假如AMD堅持下去，姑且不論早在2007年八月就公開的SSE5能不能被市場接受，光就CPU端效率和耗電而言，Bulldozer核心就大概保證打不過Sandy Bridge了。
In April 2007, Sun CEO Jonathan I. Schwartz blogged an image of a fabricated and BGA-packaged Rock chip, labeled UltraSPARC RK, and disclosed that it can address 256 terabytes of virtual memory in a single system running Solaris.[13]
In May 2007, Sun announced the first silicon of Rock booting Solaris successfully.[14]
As a result of the ISSCC more information is coming out.[15]
Rock Arrived(2007/4/10)
Sunがサーバー向けハイエンドプロセッサ「Rock」の概要を公表(2008/2/4)
當然，這種算是很高檔、而且針對特定應用程式最佳化的server CPU，從CPU試作品到實際系統產品整機出貨有很大的時間差，也不是什麼讓人訝異的事情，更何況Rock最少也有2.0版了。
不過我很期待Rock（尤其當幕後黑手Oracle併購Sun之後）跑database和ERP的表現，如果真的可以做到Sun當初的預期，那高階server市場的遊戲規則可能就要被改寫，特別是製造業用的機器。
向日葵教授 提到...這三個月下來，我發現很多人對AVX/SSE5有很大的「直覺性」誤解：
128bit對256bit怎么比
跟當年的3Dnow！一樣呀
功能被SSE包，而且是64bit對128bit，當時咬牙堅持下來了。結果沒人用，還搞到現在的U都要消費電晶體給3DNow！兼容用。
1. 一看到名稱，就認定因為AMD命名SSE5，而且維持128 bits XMM register，所以就只是過去SSE的結構性延伸：
這點完全是錯的。
總而言之，AVX和SSE5的關鍵，在於修正x86指令encoding系統的問題，沿用或創造哪些阿貓阿狗暫存器都完全不是重點。
請大家再跟我復頌一次，x86指令encoding三大問題：
1. Prefix: F3h / F2h / 66h
2. Escape opcode: 0Fh / 0F 38h / 0F 3Ah
3. REX: 去怪AMD吧...
AMD想克服自己搞出來的REX大包，順便弄出3 operand format/4 operand syntax，大規模更動encoding結構，光這點就可以讓這種「直覺反應」完全不成立。講難聽一點，AMD搶先註冊SSE5只是故意搞Intel一下，200%的行銷宣傳目的。
2. AVX對SSE5的優越性僅有「256 bits YMM vs 128 bits XMM」：
這點也完全是錯的。
Intel發展AVX的最主要目的，並不是只為了新增256bits YMM與後來被取消的4 operand format，而是想進一步克服x86指令encoding系統的老問題。如此一來，Intel未來的產品設計就可精簡Front-end，降低耗電量，保留日後更寬issue rate的延展性。
VEX整合Prefix/Escape opcode/REX，也創造「AVX體系舊x64/SIMD指令」，讓「舊」指令也能享受高速解碼的快感。實際上，大多數AVX指令都是「舊指令的升級版」，以FMA為主的新增指令反而只有48個。換言之，只要修改assembler，在既有指令的opcode前方加掛VEX（如VEX.NDS.128.66.0F38 DC /r），更換成AVX指令，即可大幅加速指令的解碼效率，Opcode Map還是一樣的，這也是AVX的核心精神之所在，也保留日後讓其他舊指令脫胎換骨的空間舊的指令欄位亦可保留日後擴充新指令之用。（這段話之前沒寫清楚...當時寫的太high了，後來連我自己也看不懂自己在寫什麼...）
但AMD SSE5完全是疊床架屋，為了解決REX，卻又創造出複雜的DREX + Opcode3結構，人家Intel都把所有重要資訊集中在前方的VEX了，一收到就馬上開工，你卻要讀取大半個指令再玩配對遊戲，然後SSE5的1/2 operand指令encoding方式簡直讓我看到髒話都快罵出來，毫無邏輯可尋，要我畫出圖解根本是一種虐待。
假如AMD堅持下去，姑且不論早在2007年八月就公開的SSE5能不能被市場接受，光就CPU端效率和耗電而言，Bulldozer核心就大概保證打不過Sandy Bridge了。
倒是AMD皈依AVX後，將XOP長度訂死在3 Bytes，也許是比較好的作法，畢竟x86指令長短粗細肥瘦不一，一直都是很令人討厭的缺點。
反正我人微言輕、才疏學淺，講再多都還是會被人當外行人耍，自己就去看後藤一年多前的文章是怎麼寫的：
x86からの脱却を図るIntelの新ロードマップ(2008/4/7)
x86 CPUの弱点が浮き彫りになったNehalemマイクロアーキテクチャ(2008/4/28)
不過話說回來，Intel要到22nm的Haswell才會有AVX的FMA體系指令，AMD該不會想搶先在Interlagos就提供吧...
3. LRBni是很優越的設計：
如果我印象沒錯，Intel到現在都還沒公開LRBni的encoding，連長的怎樣都不知道，這種「結論」大概只有看到暫存器很長、數量很多就爽起來，信奉「數大就是美」的鄉民才會有的生理反應吧。要蓋棺論定，我覺得起碼該等到LRBni-2...反正好像也沒多少人把第一代LaughabeeLarrabee當作一回事。
喔喔喔喔喔～快高潮了～
訂閱：
文章 (Atom)