NVIDIA的高效能AI旗艦機DGX-2的賣點

高效能AI受到重視，NVIDIA剛發表專為AI打造的DGX-2，正好做為明天到臺大醫院演講以及下次上課的教案。

DGX-2幾乎是以暴力法解決我們從HGX-1上面看到的一些問題，沒有太大的意外。姑且假裝我是NVIDIA的銷售人員，來述說DGX-2的厲害之處:

- 一台機器8張GPU不夠嗎? 沒問題，一台放進16張。

- 每張GPU只有16GB記憶體太少? 那就加倍給你32GB。

- 這麼多張GPU在交換資料時不會大塞車嗎? 啊，您真是內行人，沒關係，我們用12個NVSwitches打造一秒可讓這些GPU互傳4TB的超高速網路，看您有多少資料要傳都行!

- 嫌一台16張GPU還是不夠力嗎? 太好了，請多買幾台! 每台DGX-2上有8條高速網路通道，比DGX-1還多一倍，而且是Infiniband/Ethernet兩用的喔，不用擔心多台機器之間會塞車了!

- 您說即使GPU很強，CPU不夠力也是枉然? 不好意思，我們特別選了Intel最快的Xeon Platinum 系列，夠誠意了吧? (吐槽技術人員: GPU都加倍了，為什麼只放兩顆CPU，不給四顆呢? 機器都這麼貴了，省這幹嘛? 是做不出來嗎?)

- 不費話，給您兩倍的主記憶體... 雖然現在記憶體很貴，不過貴公司應該負擔得起1.5TB的成本，不過只是60萬台幣上下而已。

- 機器這麼強，硬碟存取的速度跟得上嗎? 哎呀，我們早就不用硬碟，直接給您超快的NVMe SSD陣列，讓你放常用的30TB資料，不夠的話，可以增加到60TB喔。

- 當然，做大數據的您，應該會嫌這60TB太小，不過剛剛才跟您說過每台機器上有8條高速網路通道，請以此連接您資料中心的高速儲存系統，相信做大數據的貴公司，應該有無比強大的儲存系統，對嗎?

- 關於價錢嘛，不貴啦，這台如此強大，比前代賣台幣450萬元的DGX-1快十倍，但是定價不到台幣1200萬元，真的是佛心來著... 提醒您，我們的GPU都賣到缺貨，趕快下訂，買到賺到喔!

- 喔，對了，不要小看這台機器，體積有點大，而且很會吃電，請準備好10000瓦的電力來供養它，最好預先提撥未來幾年的電費...

但是NVIDIA黃總裁和旗下的銷售人員不會告訴你，Google的TPU還有其他公司針對深度學習所研發的晶片，可能比GPU的效率高出十倍以上，Intel也正在急起直追。

不過我想，NVIDIA在市場上，還會領先一陣子。

對了，非NVIDIA經銷商的我，必須提醒大家，比DGX-1快十倍的說法，指的是某個測試程式。以極速(peak performance)來論，DGX-2約略是DGX-1的兩倍，怎麼會高十倍呢? 這就給大家自己想了...

參考資料:

[1] https://www.anandtech.com/show/12581/nvidia-develops-nvlink-switch-nvswitch-18-ports-for-dgx2-more
[2] https://www.inside.com.tw/2018/03/28/jensen-huang-unveils-nvidia-dgx-2-gpu-supercomputer-and-cards
[3] https://news.xfastest.com/nvidia/47580/nvidia-has-announced-dgx-2-and-quadro-gv100/

以優化Tensorflow作為系統研究的教案

前天在課上用TensorFlow Performance Guide [1]為案例，解說「人工智慧」與「系統研究」的關係，嘗試啟發學生的視野。

很多人會用TensorFlow開發深度學習應用，但我不知道有多少人真正在意TensorFlow應用的優化。如果只是分析「小的大數據」，或是不在乎多等幾天，那麼就不用看接下來的長篇大論了。

“This guide contains a collection of best practices for optimizing TensorFlow code.”

首先要知道什麼是best practices? 根據網路字典，best practices是"commercial or professional procedures that are accepted or prescribed as being correct or most effective”，換句話說，在各種商業或專業考量下，最為眾人所接受的，能夠最有效解決實際問題的招數。

可是，要看懂這裡所提到的best practices，恐怕沒那麼簡單，需要懂得系統軟體與計算機結構的實務。不，資工系的同學們，請不要高興得太早，我講的是「實務」，不是應付考試的那種功夫。

業界在談論best practices的時候，通常是搔到癢處、點到為止，提出大原則，但不解說幕後的學理依據和細節，也不提供完整的實驗數據。其目的在告訴大眾（潛在客戶）: 我們有能力做這些別人不大會做的工作，看得懂最好，知道我們很厲害；看不懂也沒關係，反正找我們就對了，只要付了錢我們就幫你 :)

好吧，我們就來看看，為了協助TensorFlow使用者優化應用， Google官網建議了哪些best practices呢？

洋洋灑灑寫了很多，分了三大類:

1. General best practices covers topics that are common across a variety of model types and hardware. （泛用招數）
2. Optimizing for GPU details tips specifically relevant to GPUs. （GPU專屬招數）
3. Optimizing for CPU details CPU specific information.（CPU限定招數）

第一類提出很多應用和硬體都可以用到的招數，其中又分為五小類：

• Input pipeline optimizations（解決資料取得與前處理管線的瓶頸）
• Data formats（降低資料格式轉換的時間）
• Common fused Ops（使用融合運算節省運算成本）
• RNN Performance（RNN專屬的效能因素）
• Building and installing from source（編譯與安裝的效能選項）

光是講第一小類，就花了我大半小時。各位要知道，一個完整的深度學習系統不是只有類神經網路，還包括了資料的取得和前處理。如果是分散式系統，資料取得和前處理會更加複雜，也可能造成效能的瓶頸，因此這段對實際運作很重要，但是往往被忽略。

剛好前一陣子幫業界朋友分析他們手頭上TensorFlow系統效能問題，瓶頸就出在前端的Input pipeline。各位不要笑，如果您的手頭上有一台裝有16張NVIDIA V100 GPU卡的HGX-1高效能伺服器，前處理的難度會高出許多... 如何將影像檔案有效率地從高速網路或高速磁碟陣列所構成的儲存系統中預先提出來放置在記憶體中？如何有效率地用兩顆CPU晶片上的40個處理機核心來做前處理？ 如何有效率地用將CPU處理後的Tensors送到16張GPU卡的記憶體上？

一般缺乏軟硬兼備素養的工程師，往往毫無頭緒。我在當時給了一些best practices的建議，請工程師做一個實驗，把資料送進一個超簡單、超快的model，看看速度會不會變快？如果不變快的話，就表示資料取得和前處理可能是瓶頸。一周之後，工程師回報說只變快一點點，我請他做進一步的測試和估算，跟這個Performance Guide講的幾乎相同:

Determining if the input pipeline is the bottleneck can be complicated. One of the most straightforward methods is to reduce the model to a single operation (trivial model) after the input pipeline and measure the examples per second. If the difference in examples per second for the full model and the trivial model is minimal then the input pipeline is likely a bottleneck. 

• Check if a GPU is underutilized by running nvidia-smi -l 2. If GPU utilization is not approaching 80-100%, then the input pipeline may be the bottleneck. （使用效能監測工具確定GPU忙還是不忙？）
• Generate a timeline and look for large blocks of white space (waiting). An example of generating a timeline exists as part of the XLA JIT tutorial.（使用工具畫出事件在時間軸上的分佈圖，是否有空窗期？）
• Check CPU usage. It is possible to have an optimized input pipeline and lack the CPU cycles to process the pipeline.（確定CPU忙還是不忙？）
• Estimate the throughput needed and verify the disk used is capable of that level of throughput. Some cloud solutions have network attached disks that start as low as 50 MB/sec, which is slower than spinning disks (150 MB/sec), SATA SSDs (500 MB/sec), and PCIe SSDs (2,000+ MB/sec). （算算網路或磁碟夠不夠快？）

以上所述，對於一個受過系統研究訓練的工程師，應該一點都不會很難吧？即使沒看過這篇，也應該可以想出類似的招數，因此不會「卡住」，可能一下子就搞清楚問題所在。反之，一個菜鳥工程師，如果沒有人帶，又不會自己看懂人家寫的招數，那要如何解決問題？加班加到爆肝可能都沒有用。

接下來我又花了一個多小時解說後面列舉的一些招數，其實都只是將我們（系統研究老鳥們）司空見慣的老招數應用在TensorFlow上，看起來沒什麼了不起，但是菜鳥們就是不會。做理論研究的學者可能覺得這些沒學問、沒創新，但要做深度的系統研究，不能沒有這些功夫。

接下來，就是要學生做Lab，練習解決一些小問題。動手做很重要，可以幫助學生把看來得知識內化成經驗和學問。動手做的過程中，不是按表操作，最好是不斷思考為何如此，如果能發現新新問題和發明新招數，那就更好了。

我想再次強調，培育系統架構師並不容易，一流的系統架構師需要會做系統研究，往往具備Ph.D.等級的研究能力，對於前瞻系統研發扮演舉足輕重的角色，不過台灣很少有這樣的人才，因為多數代工產業注重按表操作，給工程師發揮的空間不大。如果想公司想轉型，提升其系統軟硬整合的能力，最好是找到夠格的系統架構師。

這堂課以及後續課程希望讓學生們能體會以下概念:

1. 如何從「系統研究」的角度改善「人工智慧」效能
2. 做實務性的系統研究，需要解決的議題很多，需要好方法
3. Best practices是前人解題的心得，多看會有幫助
4. 學這些招數，要知其然，更要知其所以然才好
5. 動手做是知識內化成經驗和學問的方法之一
6. 寫報告（論文）是進一步整理心得、發想創意的好方法
7. 要博聞，但不要強記招數，要會活用

講到要會活用招術，我自己有兩個作法:

• 搞懂之後就把招數忘了吧，就像金庸小說中的「獨孤九劍」和「太極劍」，達到無招勝有招的境界。（其實是我記憶力不好，不得不如此做 :)）
• 不斷挑戰新的問題，看看是否能夠練到「乾坤大挪移」的境界: 看到人家的招術，就能夠瞬間理解，收為己用。（其實是電腦科技日新月異，不得不如此做 :)）

多虧了這兩把刷子，我能夠一路從超級電腦、電子商務、嵌入式系統、智慧手機、雲端服務、物聯網、大數據，做到今天的深度學習系統和人工智慧，至少還能跟得上時代的脈動，研究如何將當紅的應用在最新的系統架構上做優化。

[1] Performance Guide | TensorFlow. https://www.tensorflow.org/performance/performance_guide

博士滿座的系統優化團隊

今天到Oracle拜訪之前在Sun的老同事。沒想到，兩年不見，之前我工作過的團隊(Performance and Applications Engineering, PAE) 多出了一群生力軍。我在PAE的會議室裡和八位來自台灣的博士聊天，四位是我的學長輩的，四位是這兩年才加入的年輕人。
這四位年輕人，竟然有三位是我密西根大學的學弟妹，其中一位原本在新竹清華大學擔任副教授，幾週前才進來工作。另一位則是我台大電機系的學弟，威斯康辛大學博士... 這真是有緣千里來相會。



PAE擅長的是複雜系統的優化，當Oracle併購Sun之後，PAE的地位和價值更高。今天，Oracle的目標是做出世界最頂尖的Cloud，PAE雖然不直接負責產品開發，但在效能測試與優化上扮演關鍵角色，無論是資料庫系統還是大數據分析系統，PAE必須熟悉各項軟硬體技術，否則怎麼談系統優化？

為什麼需要博士？一位老同事說，因為工作上有很多未知數，沒有受過研究訓練的碩士，看了會怕失敗而不敢做，受過博士訓練的人比較能面對這類問題。他說，他們一天到晚為了解決新的問題，都在學新的東西。（註：在美國，通常碩士不必寫論文，不需接受研究訓練。）

我想起當年，我是PAE少有的博士，但我一開始沒有亮出博士學歷，因為團隊注重經驗多於學位。不過雇用我的老長官總是丟一些新的題目給我，讓我有機會表現，例如當時沒有人碰過的密碼加速卡以及最新的高速網路卡的效能問題，都丟到我手上，我得想辦法自己學。還好，我們圓滿解決問題，幫PAE在公司裡樹立起專業形象。之後，或許是覺得博士好用，新的博士陸續進來，PAE負責解決的問題日益複雜，但始終維持使命必達的好形象。

要知道，這個40多人的團隊，擁有上百櫃的機器，PAE在Oracle內部，是非常燒錢的單位，而且因為PAE沒有直接為公司賺進一毛錢，如果沒有非常良好的形象，如果公司沒有上進心，根本不可能維持這樣的團隊。

我其實很想讓台灣的公司來參觀一下，讓他們看看這個當年SUN能夠在幾年間以效能優化來提升競爭力，讓SUN能以小搏大，力抗IBM、Microsoft、Intel、HP、Dell等強敵的幕後功臣，雖然整個SUN的核心技術團隊已融入Oracle，但Oracle還是把SUN的標誌掛在每一台伺服器上，這說明Oracle對SUN的肯定。

對了，SPARC還在，只用在高檔的商用伺服器上，據說富有的阿拉伯國家很喜歡買...

Linux Kernel與產業發展的故事

下周(3/22)梁文耀博士要來台大講Linux Kernel，我來暖一下場子，提一下Linux Performance Tools，順便說說故事，免得學生覺得這個老師都找業師來上課，自己倒底懂不懂? 而且故事或許可以告訴大家，從以前到現在有甚麼變遷，不要食古不化、學錯重點了。同時大家也可想想，為什麼要學習Linux Kernel? 學了之後有甚麼用? 如何學習? Linux Kernel這麼龐大，要花多少時間來學? 如果學不得法，事倍功半。

早期，很多台灣的學生和工程師學Linux Kernel只是為了寫裝置驅動程式(device drivers)。因為系統代工廠開始採用Linux作業系統，要讓系統能夠在新的硬體上工作，必須找一群人來寫drivers。下游的系統晶片、周邊晶片、周邊設備廠，也得提供幫自家產品寫drivers給客戶用。

這些年有不少資工系的學生畢業後去業界負責寫drivers。例如聯發科技在業界的風評不錯，使用聯發科技的晶片的客戶，只要夠大咖，在driver方面會得到迅速確實的服務，其幕後當然就是那些刻苦耐勞系統的軟體工程師了，一旦有bug，就會在最短時間解決掉。

十多年前，嵌入式系統頗紅，教授只要宣稱有做嵌入式系統，學生就趨之若鶩，就是衝著台灣系統晶片和消費性電子產品的熱潮。那時政府投入到系統晶片的資源多，做嵌入式系統教學研究的人也分到一杯羹，學生畢業後進了像聯發科技這類的公司，也賺了不少錢，好像大家都很開心。

那時很多人學做嵌入式系統，只是看了幾本書，追蹤過Linux Kernel，寫寫驅動程式，讓系統會動、功能正確就好。在學術界做嵌入式系統研究，為了要發表論文，很多人跑去做系統裡面工作的即時排程、節能省電的研究，搞一堆數學模型和heursitics。這些研究成果雖然也很厲害，但是跟當時的業界的技術層級距離頗遙遠。

距離遙遠? 是的，大多數代工廠只需要按照客戶的規格要求把系統做出來，至於系統上面跑甚麼應用就不是他們要擔心的事了。以HTC為例，早期他代工做Windows Mobile手機，最在乎的就是如何選料做出價廉物美的硬體，而整支手機軟體中唯一能改的，就是drivers了 -- 這是2006年我們到HTC訪問時，軟體部門主管回應我的問題所說的話，因為「微軟只讓他們碰這個」。

因為學界被要求要證明自己是世界一流，業界有很多限制，所以學用落差很大，而兩邊又都很忙，很少溝通，但大家似乎不以為意。或許是因為當時的電子業錢太好賺，業界只要學校開一些簡單的實作課程幫學生打基礎就好，反正業界做的也不是甚麼偉大的研發工作，有了基礎到業界就能在短時間上手，那些眉眉角角的know-how，入行久了自然會知道。因此政府出錢，用補助設備和課程開發經費的方式鼓勵學界開一系列強調實作的嵌入式系統課程。

我在2005年回到台大教書，看到這種情況，很不以為然。同樣是做嵌入式系統的教學研究，我特別強調複雜系統的設計、效能分析與優化，我陸續開了一系列課程，包括「輸出裝置與驅動程式設計」「嵌入式處理器設計」「嵌入式多核心系統與軟體」「計算機效能最佳化」「平行計算機系統與應用」「Linux系統核心與應用」，嘗試訓練一些高階系統實務人才，但絕大多數賺錢的業界公司並沒有珍惜這些技能，也沒有想提升他們自己的境界，原因很簡單，因為搶錢都來不及了。

舉例來說，我在2005年去演講的時候，一位技術學院的教授當場嗆我，你講這些對我們沒甚麼用，我們只要能訓練出能寫USB裝置驅動程式的學生，他們就有做不完的工作了。我認為他看到的職場現狀接近現實，當時需要大量的工程師來幫忙做這些做不完的系統軟體開發工作 (註1)，但邏輯上的問題是，這兩年有做不完的工作，未必代表未來二十年都有工作，我們不應該只教那些，業界也不應該只做那些。

大家現在都知道了，膚淺技術的代工業已經大不如前。即便代工，也得有高階技術才能生存發展。(補充說明: 不要誤會了，我很尊重那些注重技術研發、能持續精進的代工廠，包括台積電、聯發科、鴻海這些，他們現在也知道要投資做研發，才有出路。)。那些不上不下的公司，要如何生存發展呢? 這是個大問題。

過了十年，現在還是有很多系統廠還無法轉型和升級，仍然以代工製造硬體搭配膚淺的軟體為主。上個月有一家公司找我去諮商，公司大部分的軟體技術都仰賴微軟的供應鏈，自身的軟體研發能力薄弱。說到為何不用Linux呢? 他們一下子說不敢用，一下子說看不懂市場，一下子又說找不到人才。我說，一直這樣的話，你們也只能讓微軟予取予求，果然講到他們的痛點。以前讓微軟予取予求，就當作是繳稅，現在利潤如此微薄，這個微軟稅繳起來就很痛... 我看那個態勢，似乎是要我介紹人給他們，但我猜想，這公司恐怕僱不起Linux人才，也不見得有給人才發揮的空間，所以就謝謝再聯絡了。

昨天有位考上碩士班的學生來找我，他雖然是名校畢業，但非資工系，全是靠自學。他原本在某家高雄軟體園區的公司上班，做月薪22K的軟體開發工作。一開始聊，他完全聽不懂我在講甚麼，他自承是靠補習考上研究所，但對系統有興趣。其實不只一位學生，這幾天來了好幾位考上碩士班的學生，對系統的認識薄弱到令我訝異。所以我花了不少時間告訴他們如何迎頭趕上，包括看看我們在【開源系統軟體】臉書社團(註9)上分享的資訊和課程內容。

言歸正傳，話說Linux Kernel這麼龐大，要花多少時間來學? 這幾位靠補習考上研究所的碩士生，連Linux都沒用過，要怎麼在短時間內學會做系統研究?

第一，如果想做系統，只要能抽出時間，用力學就對了，不要管要花多少時間，Just Do It! 或許，有了一百小時的研習，可以讓你入門；幾百小時，可成為某個部份的高手，接下來就繼續補充不足、與其他高手過招、漸入佳境。如果想快速成為真正的專家，每天10小時，3年一萬小時，應該有機會。不過各位看看Jserv這麼厲害，我猜他一天超過十小時花在作業系統相關的議題上，搞了30年，大概是10萬小時。

第二，利用社群資源。一般學生在考試陰影下，潛意識中某種程度敵視老師和同儕，因為一個逼你念書，一個跟你搶名次。殊不知，到了研究所，老師和同儕都是寶貴的資源，甚至為了有更多資源，還要設法到網路社群上找。國內外有很多開源碼的討論社群，都可以加入。尤其是最新的資訊，不可能等到人家寫書或是開課來教你，一定要懂得上社群網路去搜刮最新資訊和參與討論。

第三，挑戰高階(複雜)的實作問題。我認識很多聰明人，給他抽象、簡化過的難題，他們可以解得不亦樂乎，但是真實世界是複雜多元的，如果不會解析複雜問題、化繁為簡的話，根本無從解起。這是現代高階人才該具備的重點能力之首: Complex Problem Solving (註2)。有些資訊系畢業的學生，連上千行的程式都沒看過幾個，要如何探討軟體架構 ( software architecture)? 如果在學校能看懂Linux Kernel架構，能了解其運作，嘗試解決其中的問題，也算是個開始。

比如找一個大數據分析應用，設法解決其效能問題。由於很多大數據應用是架設在Linux系統上，這時候解析Linux Kernel的能力，對於改進系統在做資料儲存、資料交換上的效能非常重要。當然，處理大數據所用的中介軟體也很重要，所以我們之後也會來看Hadoop、Spark之類的中介軟體，但我希望大家可以舉一反三，否則只是學到皮毛而已。

效能工具(Performance Tools)的使用，是在實務上分析效能的關鍵。要解決問題，先要有資料；要有資料，最好是能自己動手蒐集，不必等人。要知道電腦系統裡面有很多效能監控機制，使用者可以透過效能工具取出這些資料加以分析。但是系統中有那些效能工具? 有哪些效能工具? 如何使用效能工具? 如何分析蒐集到的資料? 常常需要專業的知識，我們在學期稍後會講，但同學們可以先看。例如網誌的圖，上面列出玲瑯滿目的工具，來自於介紹Linux Performance Tools的網頁(註3)，作者就是開顧問公司的。我們當年，在SUN的系統上開發了很多效能工具以及分析的方法，後來幾位SUN的工程師出去開了這家顧問公司。

我回到台大之後，也訓練學生做類似的工作，幫業界解決效能問題(註4)。但是因為過去代工業太賺錢了，願意花時間和傷腦筋創新的大公司不多，所以看到一大堆機會沒有被業界把握住，實在可惜。這幾年新創蔚為風氣，但許多贊助新創的機構的思維還是沒變，為了快速回收，只敢投在淺薄的技術研發上。

不過最近一些資金開始關注到某些「務實做有深度研發的項目」，燃起希望的火苗。例如有找我們解決效能問題的公司變多了，題目的素質也提升了；我學生畢業後到VMFive(註5)和Appier(註6)去幫忙解決效能問題；台灣開始有以解決效能問題的新創公司，例如Skymizer (註7); 翟神開的和沛(註8)最近重金禮聘幾位我認識的Linux專家，希望有好的發展。

台灣的競爭力應該是在人才的素質上，而不是人力的數量上。我想，眼前的業界，是朝向「質」的方向發展，這是可喜可賀的事。至於量的方面，關鍵是業界和政府能否把握機會行動，以及學生能否看清現實，而我只能盡人事聽天命，無法預測未來。所以請各位同學、業界朋友、長官不要問我，現在投入系統研發的行列，未來會不會大發。我只能說，學生要做的話就好好做到出師，業界要做的話就卯足全力衝刺，政府學界要做的話就給足資源，不上不下的半吊子，恐怕是難以呈現出價值的。

(註1)嵌入式系統商機大，卻鬧人才荒 (2005/01) http://www.ithome.com.tw/node/27357

(註2)現在和未來新創所需的技能 (2016/03) https://www.facebook.com/notes/洪�⋯⋯

(註3)Linux Performance http://www.brendangregg.com/linuxpe⋯⋯

(註4) https://www.facebook.com/notes/洪�⋯⋯

(註5)http://www.vmfive.com/


(註6)http://www.appier.com/zh/


(註7)http://skymizer.com/


(註8)https://www.hopebaytech.com/


(註9)https://www.facebook.com/groups/159⋯⋯

非絕招的絕招 - 淺談RDMA的小知識與大效用

有些高階網路介面卡支援RDMA (Remote Direct Memory Access)，但仍然很多人不知道RDMA是什麼，以及它能用來做哪些好事情呢?

RDMA主要是可以讓某台機器可以透過網路介面卡所提供的API，直接存取在另一台機器上的記憶體，免去透過傳統作業系統與網路協定所增加的負擔。(註1)

這項功能純粹是為了效能而存在的，對於現代已支援各種網路協定的系統而言，RDMA並沒有增加系統的功能性。換言之，RDMA是一項可有可無的、需要硬體特殊支援的系統功能，有了它，可以節省電腦系統在做資料交換時，作業系統所耗損的運算資源和降低延遲(latency)。

因此，RDMA不是人人都需要懂得，也不是到處可見的，近年來RDMA被率先用於高效能計算(HPC)上10Gbps乃至於100Gbps的高速網路，目前它逐漸被利用資料中心和大數據運算時，作為提高資料傳輸效率、降低系統能耗的手段，例如用RDMA加速Hadoop、Spark，以後可能會被用在某些強調效率的物聯網的裝置上。

實際在網卡上使用RDMA的範例，可參考(註2)。如果看懂這份200多頁的文件，應該就很清楚知道RDMA能做哪些事情。

但光是學會RDMA是不夠的，要發揮出RDMA的作用，必須要懂得將RDMA實際用於應用面上，必須要懂得軟體和效能分析的技術，分析效能的瓶頸和資料交換的模式(pattern)，才能善用RDMA，否則可能不光是達不到預期的效果，還會減損系統效能，甚至危及系統的安全和穩定度。

首先在效能上，必須考量資料的傳輸模式，包括每次資料傳送的大小、資料的連續性、傳送的時間間隔、傳送的對象等等，來決定如何使用RDMA。我們可以讓傳送端主動把資料放進接收端，或是接收端主動到傳送端提取資料，究竟該用哪種模式?何時該進行傳輸?是否要用高階的gather/scatter功能? 這些都是要根據實際狀況才能回答的問題。

為什麼說RDMA使用不當，可能會危及系統的安全和穩定度? 因為「讓某台機器直接存取在另一台機器上的記憶體」這樣的功能，好比「讓某人直接進入你家存取東西」，如果某台機器被入侵，有可能危及其他機器的安全；也好比「共享記憶體」會造成搶資料的問題，如果兩台機器沒有同步好，可能會造成race condition，系統就會不穩定。

因此RDMA也不是隨隨便便能夠使出來的絕招，必須先精通軟硬體的實務才行。所以，絕招其實並非絕招，招數本身說穿了並不難，只是說使用者沒有足夠的軟硬體功力，練了絕招也沒有用。如果笑傲江湖裡的令狐沖沒有好好練個十多年的武功，突然接收了獨孤九劍的心法也沒有什麼用的。當然，並不是每個花很多時間練功的人，都能領悟獨孤九劍的要旨，學了也不見得會用。

話說RDMA也不是那麼罕見的概念，基本上RDMA是由DMA (Direct Memory Access)轉化而來的技術。說到DMA這個幾十年前就廣泛被使用在各種電腦系統的東西，很多做硬體設計和I/O驅動程式的人都很熟悉， 可以在單一機器中讓CPU節省傳送資料的時間，例如把大量資料送到磁碟機、網卡、顯示卡，甚至軟體想做大規模記憶體複製(memory copy)的時候也可以使用，普遍得不得了。

我原本以為，既然DMA是如此普遍的概念，那麼多加利用DMA和RDMA來改善系統效能的這件工作應該不難，但其實並非如此。看懂別人怎麼利用這些招數，和真正學會如何利用這些招數，並不是同一件事。很多做底層作業系統和驅動程式的人都看過DMA，有些會拿現有的範例照抄，但有多少人會調整DMA的使用方式或是用於解決新問題?

舉例來說，我們十年前玩過當年最紅的多核心處理機之一，IBM Cell (註3)，用在超級電腦和Sony PlayStation 3上，所以我們實驗室買了十幾台PS3，用來做教學研究。這個系統晶片有個特點，晶片上多個處理機核心之間資料的傳送，是靠DMA來進行的。雖然DMA很有效率，但是很多程式師不大會用DMA。當年開發Cell的chef architect，Peter Hofstee，後來跟我們一起合作，聊起這件事，他覺得這些程式師暴殄天物。

我讓學生學習如何在Cell上運用DMA，發展效能分析工具，甚至有位學生設計出一個輕薄(lightweight)的message-passing library，使用DMA來加速CPU之間資料的傳送。不只支援Cell，也支援工研院所研發的異質多核心處理機PAC Duo，拿到ACM RACS會議的最佳論文獎 (註4)。事實上，實驗室還有其他幾個作品，也用了DMA來提升效能。

從眾人熟知的DMA延伸到RDMA，只是把單一機器改為多台機器，概念極為類似，所以要理解並不難，但如果要會運用，還是要實際運用才行。因此，我們建置了一套以100Gbps網路連接的小型叢集(cluster)，打算來訓練學生使用RDMA，研究如何解決big data系統中資料傳輸的問題。很多開源碼系統軟體還沒有被好好優化，而且優化的方式就像以上所講的，必須根據實際應用的狀況而定，因此這裡有很大的發展空間。

RDMA 只是眾多非絕招的絕招之一例，還有很多這類的招數。我自己對於效能分析與優化特別感興趣，所以一路走來，到處學習、運用、發掘這類招數。但就像以上所描述的，這類招數說穿了一點都不稀奇，所以旁觀者看了覺得好像沒什麼了不起。國外的公司懂這類技術的人多，比較能夠賞識這樣的技能和成果；但某些台灣公司主事者的心態很奇怪，你化繁為簡，講到他能聽懂，他就以為你沒什麼了不起，以為他自己可以找到價美物廉的人在做同樣的工作。關於這點，可參考我兩周前寫的故事(註5)。

的確，這沒什麼偉大，但一般人懂了不見得會用，會用不見得會解決問題，所以「專業」不是一天造成的。以為自己官大學問大，不尊重專業，夜郎自大，自我設限是常見的通病。這篇文章的目的，在分享如何在系統開發上「同中求異」的心得，如果不想老是做跟人家一樣的東西，要如何創新? 基本功夠扎實，加上一些特異功能，例如本文的RDMA或是異質計算，那麼很有機會做出比別人好的系統，這其實不難，也不容易，需要務實培養專業能力。往好處看，台灣現在越來越需要，也比較能賞識這類人才。

(註1) https://en.wikipedia.org/wiki/Remot⋯⋯

(註2) Mellanox, RDMA Aware Networks Programming User Manual, http://www.mellanox.com/related-doc⋯⋯

(註3) https://zh.wikipedia.org/wiki/Cell_⋯⋯

(註4) Building a scalable and portable message-passing library for embedded multicore systems, http://dl.acm.org/citation.cfm?id=2⋯⋯

(註5) https://www.facebook.com/notes/洪�⋯⋯

那一年我們做系統優化的故事: 為什麼我們會做學界業界不(屑)做的研發?

 前天在與某廠商開會時遇到10年前做過產學合作的熟面孔，為了保護他的隱私，這裡稱他為X先生好了。X先生說他還清楚記得當年我們幫他的老東家「廣達的儲存伺服器研發部門」所開發的技術，這點讓我頗感驚訝。

事隔十年，保密協定也早過期了，論文也發表過了，所以應該可以來說說這個故事。

在2006~2007年間，我們與廣達做產學合作，那是我2005年回國後第一個產學計畫，我帶著實驗室草創後的第一批研究生，研究廣達剛剛研發出來的中階儲存伺服器。這個中階儲存伺服器，有兩個大腦 (雙控制器)來提供容錯功能，每個控制器上有一個處理機跑著廣達輾轉向國外某公司買來的複雜軟體，為了要快，雙控制器把從硬碟載入的資料放在一塊特殊的共享記憶體，然而整個系統，跟競爭對手比起來，還是不夠快。

X先生在前天對我說，他覺得我們很厲害，能夠搞定這個困擾他們工程師許久的非常複雜難懂的系統軟體，把這個儲存伺服器的極速提高了將近十倍，對於產品的競爭力有很大的貢獻。

其實這不是我們厲害，我們做效能分析和優化都是有方法論 (methodology)和工具 (tools)為基礎的。沒有這些，只能做些簡單的東西，不能做複雜的工程。國內很多研發單位只重視短期研發，根本不懂這些。(我講的十年前的狀況，廣達研究院現在應該好些了吧?) 我聽過有人說: 「什麼方法論、工具的? 反正就叫工程師拼命加班做，限時完成產品不就好了? 」所以我跟這些人談前瞻系統研發，等於秀才遇到兵，說也說不清，只有等他們遇到解不了的複雜問題，才會知道專業的價值 -- 現在搞雲端、大數據、物聯網、異質計算，這類複雜問題比比皆是，所以很多人毫無頭緒自己該做甚麼，可能也沒能力做甚麼。

首先，為了分析這台儲存伺服器的效能，我們還特別打造了效能分析工具。黃書政同學，做出了一個利用GCC編譯器在產生機器碼時在程式的進入點和離開點處插入追蹤器以產生追蹤資料，用以觀測程式執行流程的方法。這個工具幫助我們精確地分析儲存伺服器上軟體的流程，黃同學也以此作為碩士論文:

【一個針對嵌入式軟體的追蹤和效能分析技術 (Developing new tracing and performance analysis techniques for embedded applications) / 黃書政(Shu-Jheng Huang), 2007】

當年追蹤分析系統最強的工具之一，是SUN的 Solaris kernel team所開發的DTrace，這個技術後來也被IBM拿去做Linux上的SystemTap。在黃書政同學開發新工具之時，林以迪同學研究如何利用DTrace來自動化分析應用軟體的效能，後來他的分析方法幫助到這個廣達的計畫，也以此為題寫了碩士論文:

【利用DTrace在Solaris系統上以自動化方式建立應用軟體的效能模型與分析 (Automating server application performance modeling process on Solaris system via D-trace and trace-driven analysis) / 林以迪(Yi-Di Li), 2007】

要知道，一般的效能分析多半是針對CPU-intensive的應用，探討CPU的使用，然而儲存伺服器的重點不只在CPU上，還包括磁碟和網路這類的I/O動作，這些是一般工具和普通工程師較難對付的部分，所以陳人豪製作了一個量測和模擬的框架，讓我們能評估I/O部分的問題，這也是他的碩士論文題目:

【系統層級的效能量測與評估框架 (System-level performance profiling and simulation framework for I/O-intensive applications) / 陳人豪(Jen-Hao Chen), 2007】

不要忘了， 一個複雜的多工系統不只是一次只做一個工作，還有多個核心來做多項工作，所以張筱薇同學 (實驗室唯一的女生!)選擇做這個最硬的研究工作，利用SystemC做出一個能夠快速分析多執行緒應用程式效能的模擬環境，令我感到非常難能可貴:

【設計與實作一個快速分析多執行緒應用程式效能之多核心系統模擬環境 (A rapid simulation environment for application performance estimation on parameterized multi-core/multi-threading architecture models) / 張筱薇(Hsiao-Wei Chang), 2007】

搞清楚效能的問題所在，接下來就是設法優化(optimize)其效能了。怎麼做呢? 我們實驗室研究效能優化，著重的是那些編譯器做不到的事情，而不是那些編譯器可做的事情，這是跟那些做編譯器研究的實驗室最大的不同。我們認為，天底下有太多編譯器做不到的最佳化工作，厲害的人可以手動搞定。

舉例來說，編譯器往往不知道該怎麼優化程式，所以提供一大堆選項讓開發者來選。當時的GCC有42個可能影響效能的選項，請問要怎麼選? 至少有2的42次方種組合，不可能暴力搜尋。陳奇孟同學在十年前就採用的現在最紅的「機器學習」來幫助編譯器自動找到最佳的選項集合:

【以機器學習快速的搜尋最佳編譯器選項集合 (Finding the best compiler optimization option set rapidly via machine learning) / 陳奇孟(Chi-Meng Chen), 2007】

然而，一般的搜尋方式，只適用於普通的應用程式，為了最佳化這個儲存伺服器的核心，每次編譯過後必須重開機測試效能，所以非常耗費時間，所以林煌森同學針對這個議題設計了一套自動化搜尋機制:

【自動搜尋編譯器選項最佳設定 : 應用於儲存伺服器核心模組效能之提升 (Automatic selection of compiler options for performance optimization on the kernel modules of a storage server) / 林煌森(Huang-Sen Lin), 2007】

適當選用編譯器的選項，的確提供了效能，但真正讓這套儲存伺服器效能起飛的是對於軟體架構的改進。然而，如果沒有蒐集足夠的效能資料和對於系統完整的分析，根本不可能碰觸到軟體架構的改進，所以最佳化的成果還是得歸功於整個團隊的合作。

陳嘉翔同學在這套儲存伺服器中，加入了高效率的快取索引表，大幅改善了原本極為沒效率的搜尋機制。誰知道這套廣達花錢買來的軟體，會寫得這麼沒效率呢? 陳同學的碩士論文:

【磁碟陣列系統之最佳化研究 : 快取索引表之設計與實作 ( Performance optimization on a RAID system ; design and implementation of a fast indexing table for disk caching) / 陳嘉翔(Jia-Siang Chen), 2007】

吳建成同學算是集大成者，他不僅加入了預測使用者未來的需求做預先提取(prefetch)的機制，同時負責整合和評估最終的結果，寫出他的碩士論文:

【評估快取與預先提取在儲存伺服器上的效能 (Performance evaluation of caching and prefetch strategies on a storage server) / 吳建成(Chien-Cheng Wu), 2007】

總合來說，這些研究，讓儲存伺服器的極速提高了將近十倍，而廣達只贊助了我們一百多萬台幣的研究經費 ，這不能怪廣達小氣，這對當時沒有國科會經費、又沒有名氣的我來說，這筆錢讓我能夠購買設備和供養學生；不過這點經費大概只能僱一位菜鳥工程師做一年研發的成本，如果比起當年廣達贊助MIT的研究經費以及給台大的捐款，所以我想廣達的經費應該是大大值回票價了。

但或許廣達不這麼看，這才是當時身為菜鳥助理教授的我，最為感到不值的部分。那個儲存伺服器研發部門，被長官要求要自負盈虧，為了要在短期內謀求利潤，只好開始刪減「不必要」的研發開支，所以在一年的研究期間過後，就沒有下文了。

所以我說國內業界短視近利、不懂軟體研發，這是我親身經歷的第一個實例。X先生應該是站在我們這邊，但他當時也是小咖，即便覺得應該持續贊助我們，也改變不了大長官的旨意。X先生目前在某大公司擔任處長，前天開會中發言強調軟體開發的重要性，支持提早做軟體的開發，我聽了非常窩心，希望業界有更多懂得系統和軟體的人才。

另外，在學術方面，我指導這批第一屆的研究生做實務研究，在2007年產出了八份碩士論文，忙得不亦樂乎，隨後將部分論文改寫投稿，在2008才發表兩篇國際會議論文(註一) (註二)，2009年一篇(註二)，投資報酬率極低，發實務研究的論文難度高，是其他領域的人所不能夠理解的。

首先，關於這類系統研究，教導學生基本知識和技能、指導學生做研究、解決實作問題、驗證研究結果，原本就可能要比其他領域花更多心力；其次，要寫一篇優質的實務研究論文，必須能言善道、精準犀利，但大多數學生推導數學公式可以，寫程式可以，卻不大會用英文談論設計方法、分析利害得失、探討關鍵議題、展現系統優勢，如果要在國際會議或期刊上發表論文，我們必須在論文寫作上花很多時間。另外，寫論文時還要顧及與廠商的保密協議，必須遮遮掩掩的，當然更不利於發表。

所以我說國內學術界在數SCI論文數量的同時，把很多教授和學生逼上找尋容易發表論文的途徑，像這類我認為很有價值的產學合作，在那個SCI掛帥的年代，因為事倍功半，所以被年輕教授們視為畏途。

業界短視近利，加上學術界SCI掛帥，我對於這個系統優化的產學研究案的積極投入，算是非常吃力不討好，唯二能夠安慰自己的，第一是教出一群能實作的研究生，第二是這個研究案讓我更清楚我們能做出業界需要的前瞻研究，只是時機未到。

至於個人的學術成就，懂的人就懂，對於那些只會算論文數量的人，我也不冀望他們的理解。但上述的情況在這些年嚴重阻礙台灣的產學發展，造成前瞻研發不務實、論文氾濫的現象，甚至影響教育品質和人民生計。然而，產業仍不乏有能人，學界還是有志士，只要堅持走對的方向，我們還是有可能走出困境的。

(註一) Shih-Hao Hung, Chia-Heng Tu, and Chien-Cheng Wu, Optimizing the Embedded Caching and Prefetching Software on a Network-Attached Storage System, in Proc. 2008 IEEE/IFIP International Conference on Embedded and Ubiquitous Computing (EUC) , pp.152-161, Shanghai, China, December 17-20, 2008.

(註二) Shih-Hao Hung, Shu-Jheng Huang, and Chia-Heng Tu, New Tracing and Performance Analysis Techniques for Embedded Applications, in Proc. the 14th IEEE International Conference on Embedded and Real-Time Computing Systems and Applications (RTCSA) , pp.143-152, Kaohsiung, Taiwan, August 25-27, 2008.

(註三) Shih-Hao Hung, Chia-Heng Tu, Huang-Sen Lin and Chi-Meng Chen, An Automatic Compiler Optimizations Selection Framework for Embedded Applications, in Proc. the 6th International Conference on Embedded Software and Systems (ICESS) , pp.381-387, HangZhou, Zhejiang, China, May 2009.

如何建構一套CP值很高的處理big data所需的硬體?

要建構一套CP值很高的處理big data所需的硬體，還真是有點難搞，這時候會說「有錢真好」:)

以下整理一下這幾天討論的技術問題，括號裡是有關教學的註解。

Q1. 要採用HD還是SSD呢?

A1. 看容量和應用而定... 現在SSD與一般HD的價差約4倍，但throughput可能有四倍，而且access latency就不用比了，所以如果你的access pattern非常random，還是買SSD吧... 當然SSD有穩定性的問題，就靠RAID去解決了，真的是重要的資料，還是多放幾處比較好。

（這些有關於市場行情、硬體規格知識，常去討論版、多看一些相關的資料就知道了。）

Q2. 系統的架構重不重要?

A2. 系統架構上有個重點是disk controller有多少頻寬。頻寬不夠，再多SSD也没用。例如我正在搞的這台，有3個12Gbps的控制器，20個硬碟插槽，一個做法是放16個硬碟，加上RAID6，8T x (16-2) = 112T的空間，剩下的4個放SSD作為cache。一來SSD cache壞了也無所謂，二來這樣硬碟可以不必又貴又耗電的高速企業級硬碟。

（這些case-by-case的know-how，需要做一些個案研究，做額外的思考，最好是培養出think different的能力。）

Q3. 如何讓效能更好?

A3. 如果儲存系統的部分效能不夠的話，還可採用高速PCIe SSD，還可以放1T的主記憶體做file caching。計算的部分，多一些CPU核心當然有幫助，但要贏過別人的話，可能要靠GPU和硬體加速器，還有又硬又軟的FPGA。一台不夠的話，就多買幾台，用高速網路串起來，現在已經有100Gbps的Ethernet。當然，還有很多高階技術，族繁不及備載，有些需要錢，有些有錢也買不到。

（有些高階技術，說的容易，做起來難，因為技術不見得成熟，有些問題要先驅者自己設法解決，需要一些hacking。有些需要產學合作，拿到一般人拿不到的東西。）

Q4. 還有甚麼要注意的?

A4. 硬體層次的秘密，大概在以上就講完了，沒什麼太難的概念。重點還是在軟體，秘密在於：1. 要知道應用的需求和分析其效能瓶頸 2. 要懂得軟硬體之間的搭配和互動關係 3. 制定高CP值的硬體規格 4. 軟體的優化。沒有注意這些，即使花很多錢買高檔設備，結果可能也是枉然。大部分HPC和Big Data的使用者，一開始都不懂這些，需要特訓。

（大部分資工系大學畢業生並沒有足夠的背景，所以我們實驗室的研究生們，近來時大都必須接受這類特訓。沒有足夠的時間做扎實的訓練，是做不出什麼好結果的。）

Q5. 那要怎麼搞定軟硬體?

A5. 上述的秘密，其實都不是什麼秘密，只是因為一般人搞不清楚整個系統軟硬體的運作，計算機結構、作業系統、程式設計都分開學，學了之後又不會將這些知識融會貫通，才變成秘密。沒有融會貫通的話，就會看到不斷出現的新硬體、新軟體，以及看不懂、學不完的招式。

（學校的價值，不是像一般人吵來吵去說理論重要，還是實務重要，真正該做的是提供學生融會貫通的方法、場域、機會。）

Q6. 所以照以上這樣說，這也不是甚麼了不起的學問?

A6. 天下本來就沒有什麼學問是真的了不起的，「人」才是最重要的。雖然如此，但這些know-how也不能說不是秘密，因為就算我把這些要點都說清楚了，一般人可能還是有聽沒有懂，而且就算懂了道理，實務上可能兜不起來。就像背了獨孤九劍的總訣，沒有悟性，不會活用，也是枉然。

（做學問是來提昇個人境界的，學生要想融會貫通，不能只仰仗老師來教，自己要多學、多想，找問題來挑戰自己。）

研究簡介

巨量資料處理的新的組合：Google Cloud Dataflow + Apache Spark

這篇說到巨量資料處理的新的組合：Google Cloud Dataflow + Apache Spark

【大資料雙強聯手，世界排序冠軍Spark擁抱Google新PB級資料分析技術Dataflow】
http://www.ithome.com.tw/news/93669

圖片來源: GitHub

概念上還是不離data flow和memory cache的概念，只是說，granularity隨著資料量放大，系統有越多的機會去監看執行狀況和最佳化效能。

用Apache Spark來做sorting，算是牛刀小試。對效能有興趣者（國內這種人大概很少吧？）可以看看這篇報告（http://sortbenchmark.org/ApacheSpark2014.pdf），關鍵根本不在memory，而在於硬碟和網路。

系統的Modeling and Design

下週一哈佛大學的Prof. David Brooks會來系上給演講。講題是
Modeling and Design for Composable, Accelerator-Centric Architectures，翻成中文，大概的就是「可重組的加速器為主的計算機架構之模型與設計方法」。

我們實驗室這幾年做了不少相關的題目。所謂的Modeling and Design，重視的就是法則和工具，我們做了一堆幫助系統軟硬體整合設計的模擬器的技術和工具，跟IBM Research合作；成大蘇文鈺​教授也做了一堆ESL工具，只可惜國內業界還沒跟上來，看不到把應用加速器快速做出來的重要性，搞得蘇教授心灰意冷，寧可多花點時間去教小孩寫程式、研究咖啡和音響。

不過，希望遠來和尚念的經，可以讓國內的產學界長官們了解這個領域的重要性，多多支持相關的研究。所謂的支持，不是只送來幾片開發版就算了，很多人的腦袋還停在十幾年前的「微控制器+硬體加速」的系統晶片的思維，用來做做多媒體播放器、數位相機可以，但面對日益複雜、進展快速、必須上網與世界溝通的「物聯網」和「雲端智慧裝置」，你們還用硬體思維做產品的話，是很難有所突破的。

複雜的應用，軟體會先被設計出來，然後不斷演進。如何在這樣的狀況下，利用加速器去改進軟體，達成快速或省電，是一門學問。現在學校礙於教學時數，只能教些簡單的例子，或是反覆研究一些人家做到爛的加速器（例如H.264解碼器），都是老掉牙的東西。

真正有趣和厲害的，是針對那些從未被加速過的複雜應用，把可攜式(portable)的加速機制設計出來，無論是用GPU、FPGA、HSA都好。例如，給我們一個癌症的放射線治療規劃與劑量模擬程式，能否設計出提高其速度與精確度的加速機制？這需要醫師、核工、資工專家一起來做，不是隨便做做就好的。

做設計方法和工具的，一旦短視近利，很快就玩完了。我們自己做了幾年研究，IBM Research才來找我們做癌症的放射線治療規劃，再過了幾年，鴻海把捐給台大的癌症醫院蓋起來了，才開始跟我們談同樣的題目，希望我們來幫忙開發技術。

類似的需求太多了，沒有好的設計方法和工具，等於是土法煉鋼，不易設計出有競爭力的加速器。全系統的設計方法和工具，是一門新興的產業，猶如當年EDA工具之於傳統晶片設計一般，非常重要。而這樣的研究和產業，是台灣很適合去發展的。

以下是「遠來和尚」 Prof. David Brook將要念的經文摘要，看懂的人當知我所言不假。

Traditional performance and energy scaling benefits based on technology improvements have slowed greatly. To overcome these challenges, hardware acceleration in the form of datapath and control circuitry customized to particular algorithms or applications has surfaced as a promising approach, as it delivers orders of magnitude performance and energy benefits compared to general-purpose solutions. The importance of accelerators is most evident in domain-specific computing platforms currently embodied by today’s energy-efficient mobile SoCs and network processors. To broaden the scope of accelerators into the domain of general-purpose computing it will be necessary to preserve flexibility and generality. Chip designers need to develop composable architectures consisting of ensembles of accelerators that can be pieced together to execute a large variety of workloads. These accelerator-centric architectures require quite different tools and design methodologies from general-purpose designs. This talk discusses recent efforts to develop new methodologies for workload characterization, rapid accelerator design, and pre-RTL simulation of accelerator-centric systems.

Intel Atom+FPGA開發版

收到四份廠商捐贈的Intel Atom+FPGA的開發版。感謝Intel, Terasic, Altera的贊助，我們會好好利用的，也希望其他廠商提供新產品給我們嚐鮮。

平行計算像難開的快車

我研究平行計算二十多年，我從來不敢說："parallel computing is the future"。但我想Linus Torvalds對於某些過度宣傳的作法感到不滿，才說出在這篇說出a bunch of crock這樣的類髒話。（http://highscalability.com/blog/2014/12/31/linus-the-whole-parallel-computing-is-the-future-is-a-bunch.html）

持平而論，我會說"parallel computing is an expertise which may provide some competitive edge for certain applications"。就像在賽車場上，決定賽場輸贏的因素很多，但車子比別人好開又快幾倍，贏面就提高了不少。

如果平行處理如果好開又快幾倍，大家當然趨之若騖。只不過事實並非如此，Linus Torvalds大聲反應出軟體工程師的感覺 -- 為什麼要給我一台很難開的快車？那不是叫我去送死嗎？寫平行程式，平白多了一大堆bugs！

所以，我不只同意Linus Torvalds的看法，而且我的看法是，普通人無法駕馭難開的快車，叫一般人來做特技專家的工作，不只事倍功半，還不見得搞得出來。資訊業界有太多可以搞的東西，不是所有人都要來搞懂平行處理。

反過來說，能夠駕馭難開的快車的人，要知道自己是有才的。「平行計算」永遠不會是一般技能，而是一項高度專業。這種專業的價值，在解決重要的問題才有浮現。

我猜會讓Linus真正不爽的是「異質計算」（heterogeneous computing），這個不只是平行計算，而且還是讓不同的處理機來做平行計算，真的會讓系統軟體的人吃不消。

我們在做HSA (heterogeneous system architecture)，就是這個調調。當每個系統裡面都有GPU或是FPGA的時候，軟體要不要用GPU/FPGA來算東西呢? 系統軟體要不要支援呢？這當然對於系統軟體的人增加不少負擔。至於是甜蜜的負擔，還是夢靨呢？因人而異。

比起Linus Torvalds的話，文後的留言可能比較有看頭，不過一般人大概不會去看，但有志學parallel computing的人應該看一下。

撇開流派不談，我看到一個問題是，老闆要程式師寫平行程式，願不願意付出相當的代價？如果把平行程式變成大學必修課，要求所有資工學生都要會這個，那就不怕找不到人來做了。

但是話說，出得起香蕉，只請得到猴子... 請一堆貌似會寫平行程式的猴子，寫得出堪用的東西嗎？我們知道這個問題，但老闆通常不管這麼多。

這個問題在台灣當然是更嚴重的。不用說到系統軟體的平行處理了，一般應用軟體的簡易的平行化都很有問題。但老闆們不知道這個專業的難度，覺得不過就是多了一個平行化的步驟而已。

不願出錢，「平行化」是搞不大起來的。就像說不願出高價，要僱人做系統軟體，也是搞不起來的。

我一直覺得很奇怪，我專門教這類高門檻的技術，業界實際上也很需要，卻不願意多出點錢來僱這類專才？推論至此，我認為是「行情」和「無知」所造成的。

我到目前還沒有看過哪一個台灣的公司願意出足夠的錢搞平行化的。懂平行化的能度的人已經不多了，願意砸錢的人更少，以為能夠自己做的人倒是有一堆。看到這些要自己做的，我只能說，祝好運，請不要回來找我。

現在學的這些，從學校出去以後可以用多久？

我經常被學生問到，現在學的這些，從學校出去以後可以用多久？

標準答案是，看你自己在學校學了什麼？再看你從學校出去以後又學了什麼？不僅止於知識的學習，還包括自學、解題、研究的能力是否有被啟蒙與開竅？

大家知道嗎？現在你修的一些課，講的可能是過去火紅的議題，或是符合現在業界需求的技能，但等到你出去之後，資訊的世界可能又改變了。

你能夠因此說，那我只要學那些基本功夫就好了嗎？還是說，那我要拼命多學，十八般武藝俱全，將來總有一兩項是有用的？

對我來說，這兩種說法都很「廢」，因為太過偏差。

如果你對資訊科技本身並沒有太大的興趣，只是想應用學校所學來在業界找到一份好工作，那我奉勸資訊系畢業的大學生，可以找個自己真正有興趣的行業，然後用你的資訊技能去改變這個行業，機會很多很好。不然，待在變化迅速的資訊領域中，你會很辛苦的。

如果你對資訊科技很有興趣，樂此不疲，將來要走這個專業的話，請繼續讀下去。

我假設你讀到資訊工程研究所了，我想問你，在經營你的研究所生涯的時候，有沒有常常看看外面的世界？除了業界的公司之外，還有哪些？誰能告訴你五年後、十年後什麼技術最為搶手呢？

關於業界在做什麼的資訊，現在非常普遍，你如果說不知道、找不到的話，我真的質疑你是否適合念資訊系。

要了解資訊領域五年後、十年後什麼技術最為搶手的這件事，比較棘手，因為大部分學校的老師都有其專業和個人興趣，你可能要問好幾位老師才有機會能得其全貌，但教授對於業界的掌握度有多高，這就見仁見智了。

我在此做個嘗試，告訴你，你可以自己來嘗試找到你有興趣的未來熱門議題。當然，方法很多，這只是其中之一。

我們來看一下IEEE Transactions on Emerging Topics in Computing (TETC)的網頁（http://www.computer.org/portal/web/tetc）。大家來看看有那些emerging topics （顯化中的議題）正在call for papers？

我把所有call for papers的議題列出，再把跟我有興趣作為工作的部分用雙星號（**）標示，跟我目前個人嗜好有關的部分用單星號（*）標示。在這個實際例子裡，目前一共有9個顯化中的議題，與我們實驗室相關的有4個（嵌入式系統的資安、行動雲端演進、巨量資料系統效能、巨量資料處理），與目前個人興趣相關的有1個（工程教育），總列表放在文章最後。

因為要專精在系統效能、行動雲端應用、資安，所以我們實驗室有很多不做的，以上的議題有四個對我們來說是外行，因為我們不做電路 （circuits），不搞網路協定層（network layers），不精於統計、理論、演算法等等。

但如果有時間的話，我個人是有足夠的背景去看。當年修過的電機系課程，網路課程、影像處理課程、數學、資訊理論，讓我必要的時候，能夠進去逛逛，大致了解其中有什麼新的東西。不過要做研究的話，又是另一回事。

重點是，對於我有興趣的題目們，是否能夠用一個核心的方法論（core methodology）把它們貫串起來，達到所謂「吾道以一貫之」的程度呢？

對於初學者來說，很不容易。我們往往得摸索好一陣子，才能掌握一些要訣；再繼續摸索好一陣子，才能將要訣融合連貫收斂；再來則是實際運用測試收斂後的方法論，達到神而明之的程度。（That's what I call "beyond programming".）

在上例中，我的核心方法論是「系統效能」。我從小就對於電腦的效能非常感興趣，總是好奇，為什麼電腦不能再更快一點？能夠讓電腦更快，就能幫人類解決更多的問題。

當然，有很多方法可以讓電腦更快，但是根本的問題是，我們怎麼知道電腦在做什麼事情、在什麼時候不夠快，不夠快的原因，以及加速的方法，而這個能夠涵蓋這些的一套方法，就是我核心的方法論。這個方法論必須統攝多個相關領域，包括效能量測（performance measurement）、效能分析（performance assessment）、效能模型法（performance modeling）、效能最佳化（performance optimization）等。

我在博士班的研究，建構了這樣的核心方法論（沒有積極發表，因為一般人不能賞識和吸收），對於日後所從事的工作，有極大的助益。這十多年來，靠這個方法論，在一個接一個出來的新興領域，混得還不錯。

我將系統效能方法論用於超級電腦、商用伺服器、嵌入式系統、行動裝置、雲端服務、儲存系統，乃至於巨量資料處理等應用領域，皆是游刃有餘，只需要學習該應用領域的特性，或是與專家合作，即可登堂入室。

我在SUN工作的時候，被找去做資安，發現資安領域中有很多效能的問題，因為要層層加密和檢查，需要耗費大量運算資源。很多的商業應用，也是效能的問題，沒有解決效能問題，服務沒辦法在使用者或工作量持續延展（scale）的狀況下維持服務品質。

行動運算，談的是在小小的、有限能源的系統上做計算；雲端運算和巨量資料處理，很多議題談的是資料的儲存和處理的相依性和一致性，其本質是平行與分散式運算中的做作分割（task partitioning）、資料集中性（data locality）、運算同步（synchronization）、資料一致（coherence）、效率通訊（communications）、優化排程（scheduling）等；異質多核（heterogeneous multicore），是進一步優化效率的形式。

這些相關問題，多得不得了，同學們如果能掌握關鍵方法，很多時候都可以做得有聲有色。

我們希望能做更多，所以想辦法把方法論建置在工具上。因此我們花了很多年時間建構各種虛擬平台（virtual platform），希望能逐步把一些效能量測、分析、模型、最佳化的方法放進去，完成我當年博士論文中所提出的想法。做出這樣的工具，應該可以幫助很多系統的設計者，同學們加把勁吧。

好吧，我把我自己多年來用得很不錯但不怎麼樣的秘密都說給你們聽了，道理很簡單，修行在個人。

附件：

Call for Papers in IEEE TETC, as of 2014-12-09

Special Issue on Circuit and System Design Methodologies for Emerging Technologies

**Special Issue on Emerging Security Trends for Deeply-Embedded Computing Systems

**Special Issue on Advances in Mobile Cloud Computing

*Special Issue on Emerging Trends in Education

**Special Issue on Big Data Benchmarks, Performance Optimization, and Emerging Hardware

**Special Issue on Methods and Techniques for Processing Streaming Big Data in Datacentre Clouds

Special Issue on Approximate and Stochastic Computing Circuits, Systems and Algorithms

Special Issue/Section on Low-Power Image Recognition

Special Issue/Section New Paradigms in Ad Hoc, Sensor and Mesh Networks, From Theory to Practice

巨量資料很厲害？能搞定一個應用再說...

這篇「海量資料萬歲？請三思！」（http://pansci.tw/archives/42114）值得讀一下。我以下講的是相關的題外話。

Big Data的重點在於提供新的研究方法和處理技術，但不是萬靈丹；正如同雲端運算的重點在於為大型資訊服務提出新的內部架構和運作管理機制，並非取代原有技術。

雖然把這些技術當成方法和工具，可以提高成功開發新應用的機會，但是這類當紅的高風險、高報酬的高科技業，最怕的進到就是那種短視、只會跟風、又缺乏實力的研發團隊，比人家晚半拍做出比人家差的東西。

台灣幾年前一些搞雲端的公司，把問題看得太容易了，投入的資源不夠，台灣本身的軟體人才也不足，卻想在短期間賺錢，所以起不來。

軟體工程的人才，不是短期間就訓練得出來的。先天上，軟體比硬體複雜許多，規格和測試都難很多，急於土法煉鋼的結果，做出來的軟體誰敢用？

現在很多人趕著搭Big Data的列車，彷彿學了幾門資料課就能做出了不起的應用。我們實驗室研究Big Data幾年，仍然在學習模式，不大敢說我們會做些什麼應用。

要知道，每個應用都有其獨特性，如果是玩真的，一定會不斷針對應用去優化，因此對於應用的特性必須瞭如指掌，除了domain knowledge之外，也要做好workload characterization。拿Google做過的東西套在自己的應用上，不見得好，所以開發者應該先抱著「一次搞定一個應用」的態度，才能做好實務工作。

二十年前，我們在U of Michigan的一個平行處理實驗室裡面，七、八位Ph.D.學生，花了幾年的時間一起來想辦法搞定「一個應用」。

或許在台灣的產業、學術界眼中，扎扎實實作研發已漸漸成為天方夜譚，因為這個體系不只不鼓勵，反而處罰扎實作事的人。多年來短視近利、只看到數字的作法，搞得大家成天疲於奔命，很多時候，不是設法賺一些蠅頭小利，就是用花拳繡腿唬人，但是真正知道要跑去哪裡的人好像不多。似乎每個人在跟在某個人後面跑的同時，還不斷在問：「明天要跑去哪裡？」

你知道你自己明天要跑去哪裡嗎？要問自己還是問別人？

複雜系統的效能分析與調校

終於找到一篇類學術的文章可以跟學生介紹『複雜系統的效能分析與調校』。這篇文章談的東西很實用，對我來說好親切，書後列出的參考書目裡面的東西，大都不是學術論文，而是實務工作心得。

大客戶的高級商用伺服器出現效能問題，找誰來解決？先找個駐點的Field Support Engineer來看；解決不了，請比較厲害的System Engineer來；還是解決不了，送到總公司請Performance Engineering Team幫忙看。有朋友戲稱我們是大內高手。

我一直認為，當年(2000-2005)的SUN擁有最強的Performance Team，因為IBM和HP都不是靠效能在賣商用伺服器。IBM是靠金字招牌，HP是靠行銷術，只是SUN是靠「性價比」角逐市場。

這篇講的東西，就是我當年在SUN的Performance Engineering Team專精的工作項目之一。效能分析與調校，有一些基本的法則可以遵循。同一個問題給專家解，還是給庸手解，結果會差很多吧？想學嗎？看看這篇文章吧，台灣的學校大概是不會教的。

這種課，我曾在台大教過，吃力不討好，懂系統能夠體會個中精隨的人幾乎沒有。到業界教，也沒好到哪裡去，台灣的工程師們多半只想著解眼前的bug，想學一些可以現學現賣的絕招，對於methodology沒興趣。

如果我自己開公司要雇用系統分析高手，我會請來應徵者看看這篇，然後考他懂不懂這篇在講什麼？

我也有想過，打造一個精通效能分析與調校的團隊，開發各種效能工具，以及幫忙需要的人解決效能問題。

效能問題有多重要？看看eTag和戶政系統的緩慢，就應該知道。我想，政府很需要這樣的團隊來評估和解決各種效能問題。

"Performance issues can be complex and mysterious, providing little or no clue to their origin. In the absence of a starting point—or a methodology to provide one—performance issues are often analyzed randomly: guessing where the problem may be and then changing things until it goes away. While this can deliver results—if you guess correctly—it can also be time-consuming, disruptive, and may ultimately overlook certain issues. This article describes system-performance issues and the methodologies in use today for analyzing them, and it proposes a new methodology for approaching and solving a class of issues".

註：ACM Queue 是個發表平台，這篇跟Queueing Theory 一點關係都沒有。
http://queue.acm.org/detail.cfm?id=2413037

戶政系統的問題

我想很多朋友應該不需要專業知識就能看得懂這個壓力測試報告大概在講甚麼。250個使用者連線就出問題，簡直遜到爆。全台灣的戶政事務所的總數都不只250個了，何況每個事務所同時要為多個使用者服務。簡單的算術就知道這樣的系統一定會出問題，怎麼會讓他上線?

對於公文中提及的技術問題，每一項其實可以當成題目。有興趣的人，可試著拆解每一個問題。

伺服器同時要幫很多人服務，是典型的平行處理的問題。我在SUN時候所參加的Performance Engineering團隊，對系統軟體和重要的伺服器應用做了很多效能調校和最佳化的工作，後來這個團隊併入Oracle之後，負責的工作更重要。

懂不懂多工處理，會不會寫平行程式，能不能分析效能，都是吃這行飯很重要的技能。找不對的人開發應用，花再多時間都沒用。這個剛好作為我學期平行與分散式程式設計課程的案例。

話說回來，如果政府縱容這種沒技術的公司來做政府標案，隨隨便便就賺好幾億，那我們這些人真的虧很大。一方面失去靠技術賺錢的機會，另一方面用辛苦賺來的錢繳的稅還被浪費掉。

難怪我看台灣廠商對伺服器效能分析技術沒多大興趣，原來只要有辦法，沒有甚麼技術也能做大生意...

我上週批評戶政系統時，還不知道「謝愛齡」這號人物是誰，但根據專業和常理判斷，就知道在技術上怎麼也不應該差到這種程度… 看看這篇：文官奇才謝愛齡 早該調職　（http://www.stormmediagroup.com/opencms/news/detail/d788504d-9456-11e3-91ae-ef2804cba5a1?uuid=d788504d-9456-11e3-91ae-ef2804cba5a1）

這些年的官場如何腐敗無能，可想而知。像這樣的官員，多得很。

專利：虛擬時間裝置

剛收到這張專利證書，發明叫做【用於虛擬平台上時間評估之虛擬時間裝置及其方法】。這應該是個有用的專利，至少名字可以拿出來嚇人。

UC Berkeley怎麼做big data研究?

看看UC Berkeley怎麼做big data... 以系統研究（計算機架構、作業系統、資料庫系統）的教授為主體，加上幾位做演算法、理論、Machine Learning研究的教授對各種重要的巨量資料應用做最佳化。

巨量資料應用包括：
BLB: Bootstrapping Big Data
Cancer Tumor Genomics: Fighting the Big C with the Big D
Carat - Collaborative Detection of Energy Bugs
CrowdDB - Answering Queries with Crowdsourcing
DNA Processing Pipeline
DNA Sequence Alignment with SNAP

發展出來用以支持巨量應用的系統研究包括：
Akaros - An operating system for many-core architectures and large-scale SMP systems
DFC -- Divide-and-Conquer Matrix Factorization
MDCC: Multi-Data Center Consistency
Mesos - Dynamic Resource Sharing for Clusters
MLbase: Distributed Machine Learning Made Easy
PIQL - Scale Independent Query Processing
Real Life Datacenter Workloads
Shark: SQL and Rich Analytics at Scale
Spark - Lightning-Fast Cluster Computing
Sparrow: Low Latency Scheduling for Interactive Cluster Services

應用很值錢，人家的source code不會給你；另一方面，系統軟體很多都是open source，很大方的提供給識貨的人來用。

現在是application-system co-design的時代，也是打群架的時代。人家組一個團隊來創造擴大價值，我們有些研究團隊還停留在組隊去跟政府要錢分錢的山頭主義。即便能力不足以創新，會善用人家的技術和軟體，也能夠創造很高的價值。

Big data研究的風景很美，比霧濛濛的雲端好多了，躬逢其盛的學術中人，不妨多多走出象牙塔看看。

談Intel的60核心協同處理器Xeon Phi

最近用『說』的方式，發表了一些看法，感覺上還滿方便的。ITHome的主編來訪問我，聊個半小時，講的東西就被記錄下來，比自己打字還快 :)

我講的東西被刊登在這篇報導裡：
Intel推60核心協同處理器Xeon Phi挑戰GPU繪圖卡
http://www.ithome.com.tw/itadm/article.php?c=77741&s=1

有些話不便在採訪中講得太重，免得被斷章取義，在這裡補充一下，在古文裡，這叫做『注』『釋』或『註釋』 :)

以下原文摘要用斜體字，註釋用藍字或紅字。開始的那幾段跟我沒有關係，是編輯自己整理的，或是訪問其他人的，後面那幾段才是我講的，算是壓軸嗎?

每年公布兩次的全球超級電腦5百強排名，不只是各國展現運算國力的排名，從排名中也可以看出高效能運算技術的新趨勢。… 但是，這份排名中，也有6臺超級電腦採用了Intel剛推出的第一款60核心協同處理器Xeon Phi，其中包括了全球超級電腦排名第七，位於德州先進運算中心的Stampede超級電腦，這也是第一部採用Xeon Phi協同處理器的超級電腦。 … Xeon Phi的首度登場，超級電腦除了利用GPU來提高運算效能的作法之外，又有了新選擇。 

XEON Phi登場，為什麼選超級電腦作為最初的戰場？當然是有理由的。

1 Pflops相當於每秒可以執行1,000兆次的數學浮點運算。而可以提供17.59Pflops運算效能的Titan超級電腦有多快？每個人每秒若能計算一次浮點運算，全臺灣2,300萬人需連續計算24年所累積的計算量，就相當於Titan用1秒鐘所完成的計算量。

這段實在是有講等於沒講，現在很多地方都好像有這種弱智的對話。

因為Nvidia早在1999年就推出第一款GPU繪圖卡，2006年時更發表了GPU的開發框架CUDA（Compute Unified Device Architecture），協助開發人員透過C語言或Fortran語言來運用GPU的平行運算核心，2008年更推出專供高效能運算用的GPU繪圖卡後，不只超級電腦，許多HPC高運算伺服器也紛紛搭載Nvidia的GPU繪圖卡，來提高運算效能。 … 不過，Nvidia GPU繪圖卡在平行運算領域的地位，開始受到了挑戰。英特爾推出了Xeon Phi協同處理器來對抗Nvidia的GPU。 

CUDA是比較早出來的東西，市場佔有率高。不算非常好用，但是硬體的性能價錢比很高，所以很適合用來建超級電腦，反正超級電腦的使用者已經很習慣花很多時間去開發和調校城市了。（我博士論文就是搞這個的）。

英特爾推出超多核心架構的Xeon Phi協同處理器5110P，採用PCIe介面卡設計，可作為HPC的運算加速卡，單顆處理器內建了60個運算核心，運算效能媲美1臺1997年的超級電腦。 … 這款處理器採用22奈米製程，時脈1.053GHz，採用常見的PCIe介面卡設計，並搭配被動式散熱機制，功耗為225瓦，可搭載8GB的GDDR5記憶體。 … 除了5110P之外，另外還有還將推出一款更低價的Xeon Phi 3100協同處理器，可支援6GB記憶體，同樣採用22奈米製程，但熱設計功耗較高，達到300瓦特，預定明年上半年上市，售價將會低於2,000 美元。

2000美元的處理機貴嗎？新東西當然貴，如果量夠多的話，價格會降下來的。問題是，銷售量有沒有辦法衝高？這是雞生蛋 蛋生雞的問題。Intel在個人電腦的市場上呼風喚雨，憑藉的就是市佔率，現在豬羊變色，Intel是後來者，要靠什麼打江山？


英特爾亞太區暨大中華區高效能運算解決方案架構師Scott David表示，因為Xeon Phi協同處理器延續了Xeon的x86架構，所以，可以沿用平行處理常用的開發語言如C、C++和Fortran語言，也能沿用原有的平行運算模型，所以，在原有Xeon E5處理器環境中執行的程式碼，略作調整並重新編譯，也可以在新的Xeon Phi處理器執行環境中，不需要重新改寫程式碼，就可以提高效能。

Intel官方的說法，就是靠這個Intel最厲害的市佔率，叫大家不要學什麼CUDA了，用原本寫給多核心Intel (x86)電腦的方法就對了！真的嗎？廠商講的話不能盡信，要仔細檢視喔，所以我小小吐槽一下。

不過，臺灣大學大資工系副教授洪士灝認為，雖然可以執行，但要充分發揮Xeon Phi的運算效能，還是得費心調校平行運算的程式。

『費心調校』這四個字，說得很模糊，但是內行的人就聽得懂。這不是普通人會做的事，剛好可以拿來訓練我的學生！

若用核心數來比較，Nvidia的GPU繪圖卡擁有高達2千多個運算核心，而Xeon Phi介面卡只搭載一顆Xeon Phi，只有60核心。看起來GPU的核心數比Xeon Phi多很多，但是，洪士灝認為，Nvidia的GPU繪圖卡和Xeon Phi介面卡，同樣都是可以用來加速HPC平行運算的效能，但兩者適合的運算架構截然不同，對於平行運算的加速效果，不一定能放在同一個標準上比較。

不一定能放在同一個標準上比較，那要怎麼比較？請來修計算機結構。接下來這幾段是我對採訪人員免費上的課：

臺灣大學大資工系副教授洪士灝表示，GPU類似SIMD架構，而Xeon Phi則是MIMD架構，兩者的運算架構截然不同，擅長的平行運算任務也不同。HPC常見高效能運算方式有兩種，第一種是資料平行化的運算方式，也就是Data Parallel，也可稱為Stream計算。這種作法適合處理大量資料，資料就像水流一樣持續提供給處理器，處理器執行完運算指令後，處理過的資料不需保存在GPU加速卡中，而是繼續提供下一筆資料給處理器，就像水流一樣持續流動。洪士灝表示，GPU擅長這種運算方式，運算量不大，也不用保留資料，處理完就送走。 


另外一種運算方式則是要對同一批資料反覆進行大量運算。例如汽車碰撞的程式，可以用來計算汽車和牆壁碰撞後，汽車或汽車內木偶的變形過程。分析人員可用3角形來模擬汽車外觀，再透過平行運算來計算汽車受力後的變化，這是工程上常用的有限元素分析方法或者稱為蒙地卡羅模擬。運算時，程式每次計算一個奈秒後的變化，如哪些地方受力會發生改變，計算出結果後，程式再依據前一奈秒的結果，採用同樣的運算規則來計算下一個奈秒的改變情形。資料就只有車子和牆，同一批資料要計算幾百萬次。洪士灝認為，Xeon Phi比GPU更擅長處理這類型的運算。 

因為GPU擅長Stream風格的平行計算方式，接近是SIMD（Single Instruction, Multiple Data，單一指令多重資料）的運算模式，這是指所有運算核心都執行同一個指令，只是作用在不同的資料上。而Xeon Phi則是MIMD架構（Multiple Instruction, Multiple Data，多重指令多重資料）的運算模式，Xeon Phi中的60個核心，每個核心都可以處理不同的指令和不同的資料。正因為如此，每個處理核心彼此需要許多同步和通訊的機制，所以，Xeon Phi處理核心的電路遠比GPU的核心更複雜。 

而SIMD架構的GPU，上千個處理核心會分群執行，例如一次使用256個核心，每個核心都是同步執行相同的指令，所以，彼此之間不需複雜的通訊或同步機制，而且所有核心可以共用同一個指令分派元件，所以，單一運算核心的電路可以簡化，就很容易在單一晶片中設計出大量的運算核心。但是，洪士灝認為，遇到蒙地卡羅模擬這類運算需求，例如汽車碰撞模擬，要對同樣的資料進行反覆大量運算的需求，GPU就不容易處理。

我已經盡可能用白話文解釋了，聽不懂的話，我也沒辦法。話說回來，為什麼中文的科普教材幾乎都沒有『電腦科學與工程』？電機資訊人應該去編一些科普教材，向下扎根才是。

不過， Xeon Phi介面卡目前內建記憶體只有8GB，有些大型運算任務的資料量容易超過這樣的規模，程式得先切割資料後才能放入Xeon Phi中計算，這樣作會影響運算效能，所以，Xeon Phi目前也不一定能滿足這類大型運算的需求。 洪士灝表示，Xeon Phi的處理核心是x86架構，雖然複雜性相當於是十年前的處理器架構，只是現在集中到同一個晶片中，就像是在一張主機板上有60顆處理器一樣，彼此組成運算叢集。「若能找到適合這類處理器的應用，這種在單晶片中放入60核心的作法，能以更低成本來取代現有的伺服器叢集或大型平行運算用的電腦。」他說。

Xeon Phi到底好不好用？答案是：『It depends』。要看你遇到的問題而定，見招拆招。有多少招？請參考拙著『 Optimizing Parallel Applications』，這本1998年寫的博士論文，到現在還很有用。

我們實驗室很快就會拿到這個XEON Phi來玩，有興趣的同學可以來詢問。

為什麼要『卡三爽』？

裝了20個應用程式之後，Samsung i9000『卡』到不能忍受，用z4root取得root權限之後，裝OCLF（所謂的『卡三爽』的一種...好一個俗又有力的名字），修改/etc/gps.conf，比較順了，再來多裝20個應用程式試看看...

另外，本來很順的Samsung Galaxy Tab在裝了50個應用程式之後已經開始卡了，看來卡不卡還是跟使用者的需求有關，CPU快一點，RAM大一點，只是讓卡機現象延後發生。

為什麼會卡呢？主要是因為RAM不夠用，只有512MB的RAM，扣掉Linux kernel和Android常駐程式佔據的空間之後，大概頂多剩下200MB，原本應該還好，但是現在很多的應用程式都提供了背景服務(services)，越來越佔空間，而且還自動會復活，殺都殺不完。這是Android的大問題，在允許應用程式提供多工服務的同時，這問題就存在。

Apple在開發iOS的多工服務的時候，比Google要小心翼翼多了，雖然給某些開發者太過於控制的觀感，但是的確讓Apple較能夠掌控iPhone的效能，因此，比較少有用戶抱怨，除了iPhone3G在升級到iOS3的時候效能變得非常差之外，大部分都還過得去，裝上百的應用程式都不成問題。

所以，裝Android程式要謹慎，但是一般使用者懂那麼多嗎？我看遲早Android陣營必須學Apple Store那樣提供Genius諮詢服務，解決一般手機用戶的疑難雜症。現在Android的行銷策略遲早會有問題，靠手機行和電信業者來解決電腦問題應該是不夠的，除非找到一個更好的管理機制，減少這種事情發生的機會。