以優化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

系統人才的出路

臉友提問：「請問系統設計的人才在台灣是否出路越來越少？」我想這也是當前許多人的迷思，「以偏概全」是台灣教育文化乃至媒體的通病。這樣的問題，不妨拿來做為高中生的人文社會學科的論說文的題目。

要做好論文，要先懂得蒐集資料，看懂別人的論述，吸收消化、綜合分析後才開始做論文。如果從中學開始，我們的國民就有這樣蒐集資料、思辯論述的素養，那麼大家應該就不大會去相信那些偏頗不實的言論，也就不會去看那些所謂亂源的媒體和腦殘的文章。

抱歉，我忘了大家在中學時忙著背書、解考古題、衝高學業成績，哪有那個美國時間做這種事呢？考試的作文又不需要這麼費功夫，只要把那些嘉言絕句背出來、套用一些陳腔濫調的公式，讓閱卷的國文老師認可就行了，而社會科的申論題都是有標準答案的，絕對不能有個人的意見，論甚麼論？把標準答案背出來就是了。

我說過台灣還未擺脫科舉封建和專制的陰影，因為我們上一代和這代人就是在那樣的文化中長大的。混得還不錯的，就覺得聯考那樣的遊戲規則太公平了，學而優則仕才對勁，要有房產巴結權勢才有搞頭，搞到不少人發覺大半輩子都是活在陰影下，為時已晚，但都是別人的錯和大環境的問題。

談到出路，人文社會學科其實有很多有用的東西，為什麼會沒有出路？我覺得和台灣科技業所面臨的問題類似的地方是，我們並沒有讓各領域的文化昇華，所以淺池容不下大魚。很多人提起當年的刻苦耐勞，覺得只要肯努力就有出路，以此質疑現在的年輕人不努力。但我看到的是，要再目前這個全球化的時代中出頭，要學的東西太多，要有新的方法和具有競爭力的環境，就不要再緬懷「紅葉少棒」那種事了，還有能力和資源的話，就帶領子弟兵或是贊助他們去提升專業領域的層次，就不要只出一張嘴說當年勇來教訓子弟。

回歸到系統設計的人才的議題，關鍵也就是在文化上，在系統和晶片廠最賺錢的時候，許多人一窩蜂跳進去，削價競爭，把市場做到爛。當時進到這個產業的人，不知道有沒有意識到，這是一個高科技、高風險的產業，如果沒有持續精進，是沒有辦法維持榮景的。老闆和股東可以不做研發，集體壓低員工薪水，一路賺到公司賠本為止，但員工如果為了本身長遠的出路著想，值不值得為了短期利益願意陪這些老闆這樣玩呢？

或許，說「系統設計的人才在台灣是否出路越來越少」這句話的人所指的是，那個學點技術就能夠進系統或晶片設計代工廠做幾年、靠股票分紅成為科技新貴的時代已經過去了，這點我同意，因為台灣過去靠廉價人力紅透半邊天的傳統系統產業正在萎縮中，原本在裡面的人都要想辦法轉型了，還會找新來的人去進去做老掉牙的東西嗎？

然而系統設計的領域大得很，很多人只注意到消費性電子產業，那些系統廠多半以大資本（政府補助）買現成技術薄利多銷的策略為主，卻不知道還有很多技術門檻較高的產業，總產值雖不高，但利潤高，其實頗適合台灣發展。

有不少做較高端系統產品的業界人士可能會告訴你，他們積極在搶真的懂系統軟體的人才，從國外找人才來做研發，還非常需要系統架構師來帶領研發，甚至砸大錢從大學挖學理兼備的教授和博士生來做研發。而我們實驗室有接不完的業界委託研究計畫，做高階系統研發和雲端服務的公司一直向我要人，教育部長官這兩年來不斷要我們想辦法培育更多的高階系統軟體人才和系統架構師。

這些高利潤、高技術門檻的產業，以往較乏人問津，可能是因為國人總喜歡炒短線、學生一窩蜂去大公司，想要馬上賺錢的觀念。我們看到很多值得投資研發的中長期項目，業界不甩，學生也沒有興趣。現在鼓吹年輕人搞新創，我很支持，但前提是不要短視近利，可能的話，以「以技術立身」。

高階系統人才，需要不斷學習來跟上系統的快速演進，而厲害的系統架構師往往需要多年累積的經驗來造就，這就是以技術立身。我之前在矽谷共事五年的團隊，就是一個實際的例子 [1]。

可惜的是，上述的東西，很多人沒有實際接觸過，但做過我多年的臉書朋友應該會覺得我講上述同樣的東西講到煩了...

我想，機會（出路）是保留給準備好的人的，說句不客氣的話，如果連門檻都進不了，還談甚麼出路？在我所看到的現在和未來，系統領域還有很多創新的空間，可以參考Gartner’s Hype Cycle [2]，不過我再三強調，高科技業也是高風險業，有很多的hype，所以要保險一點的話，還是設法提升自身的技術，才能長久勝任。

不過我知道有些人不怎麼相信「以技術立身」的想法，或許是對自己的腦袋和技術能力沒有信心，或許是對大環境不抱甚麼希望，有人覺得走門路進當紅的公司撈一筆才是機靈，有人覺得要進大公司當經理主管（之後撈一筆）才是正途，有人覺得還是早點弄到第一桶金來錢滾錢炒房產才是王道；對了，還有那些不想與狼共舞，一直在找尋越來越夢幻的小確幸的羊群們...

我不是狼，也不是羊，我屬馬的。

[1] 博士滿座的系統優化團隊 http://hungsh-ntucsie.blogspot.tw/2⋯⋯

[2] What’s New in Gartner’s Hype Cycle for Emerging Technologies, 2015, http://www.gartner.com/smarterwithg⋯⋯

資訊通識教育以及計算思維的教學法

(原發表於2016/4/5的臉書動態時報上)

資訊通識教育以及計算思維怎麼教呢？我很擔心有人把程式設計課本的每個章節拿出來，簡化一番就拿出來教了。現在的程式設計課，很多大學生都學不好，我想如果把簡化版拿去教中小學，恐怕也是問題重重。

國外在這方面進步得很快，我們不妨來參考一下Google在這個「Exploring Computational Thinking (ECT) 」網頁上所提供的教學影片 [1]。

這些教學影片都很簡短，每個影片用通俗語言來解釋一個概念，採用大量的實際世界的範例和日常接觸到的電腦用語，幾乎不用任何術語，目的是很清楚地讓不懂資訊科技的聽眾理解概念。

舉例來說，有一段標題為「Improving the World’s Videos with Algorithms and the Internet」的影片 [2]，解釋如何以演算法和網際網路來改進影片的品質，聽眾不需要懂什麼影像演算法，也不需要知道什麼以太或4G網路。看完影片後，聽眾還是不會寫程式，但是應該能夠理解演算法和網路以及資料中心在實際世界中對影片的作用，以及從作用中摸索其意義。

我個人認為，計算思維中最重要的概念之一，是能夠將計算「抽象化」與「具體化」的能力，例如與影像相關的演算法那麼多，我不需要知道各種演算法長得什麼樣子，但我知道影像壓縮演算法可以幫我省下傳輸時間，影像辨認演算法可以幫我了解影像裡面有什麼物件（以上是抽象化），而這些演算法早已經有聰明的專家實作出來，我們可以透過網際網路，利用資料中心的雲端服務來使用這些演算法（這是具體化）。

至於如何『透過網際網路，利用資料中心的雲端服務來使用這些演算法』呢？想知道的話，就去學寫程式吧！實際上，在某些系統上很可能短短幾行程式就描述了這件工作，學生只需要理解語法，用語法表達想法，將要做的工作描述出來。至於有沒有必要知道這些演算法長什麼樣？我覺得除非想當專家，否則根本不必學。

我想，會寫程式不代表一定懂計算思維，所以要教資訊通識或計算思維的教師，應該要多參考已有的教材，例如Google這裡有個給『教師』去了解計算思維的線上課程 [3]，修課者不需要程式設計的基礎，只需要會使用瀏覽器，花費15-30小時。當然，這類課程也頗適合想瞭解所謂的計算思維的一般人。

反過來說，懂運算思維不見得會寫好程式，那又如何？話說寫程式也只是初步，資訊世界還很寬廣，如果懂得資訊世界的運作，心中有運算思維之後，或許有人會想閱讀程式去更加理解資訊世界，或許有人會想學習用程式設計改變周遭世界，或許會想改進資訊系統的架構，或許會想到新的應用、新的商業模式，或許會用計算思維去解決各類學術研究上的問題⋯⋯

所以，我不是說不要教程式設計，而是不希望過於強調程式設計而框限住學習內容和未來的發展性。還有， Google提供的資料，可能比較強調他所在意的東西，所以也需要多參考其他的資料才好。


[1] https://www.google.com/edu/resource⋯⋯


[2] https://www.youtube.com/watch?v=lTj⋯⋯


[3] "Computational Thinking for Educators", https://computationalthinkingcourse.withgoogle.com/⋯⋯

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⋯⋯

現在和未來新創所需的技能

看到這個世界經濟論壇報告裡講到2015和2020的Top Skills，如下圖。從2015到2020次序略有變動，耐人尋味。不過我比較關切的是從新創的角度來看這些Top Skills。基本上，新創的門檻會逐年提升，所以並不見得適合所有人，而且有些技能本來就需要某些資質和天份，不是說猛力訓練就能出得來，應該適性發展，不能過於勉強。同時，這上面所列的能力還頗多元的，但並不是說一個人必須具備所有表列的技能才行。



我先談與新創最有關係的前三項，之後有空再慢慢補充其他項目：
第一是解決複雜問題的能力(Complex Problem Solving)，但是要如何才能訓練出這種能力呢？我們做系統研究，就是研究複雜系統裡面組件之間各種互動模式中可能產生的問題，這需要蒐集資料、細心觀察、分析問題根源、提出解決方案、實際驗證效果。這不是在學校裡做那些可預見結果的實驗，也不是去業界做那些受幾個月訓練就能上手的工作所能培養的能力。
第二是批判式的思考(Critical Thinking)，更是那些乖乖聽話讀書的人所欠缺的訓練。我們的社會，一向不大鼓勵批判傳統主流想法，甚至把批判和特立獨行看成是叛逆。但是批判式的思考，並不是網民打口水戰、為反對而反對嗆聲，要有足夠深刻的思想，才能脫離膚淺的批判。
第三是創新的能力(Creativity)。在這個資訊爆炸的時代，已經有ㄧ輩子讀不完的好書和電影、電視，還有數位教育課程，甚至還有會解決已知問題、精準完成任務的人工智慧和機器人，如果不創新的話，那要做什麼事來呈現個人的價值呢？但要如何訓練創新的能力呢？除了天才和天份之外，我覺得上述第一和第二項能力也是創新的關鍵，如果懂得解析複雜問題、批判既有作法，那創新的機會可能提高不少。

此外，對於研究人才來說，排在五和第七位的Coordinating with Others和Judgement and Decision Making，也是很重要的技能。

但這些聽起來還是很抽象，要如何發展和應用這些技能呢? 要講清楚並不容易，剛好今天晚上在探索開源系統軟體時，看到一個技術創業的故事，剛好可以拿來對比以上所提到的技能。

話說我對Tachyon這個開源系統軟體很感興趣，原因可能是因為我也早有類似的構想，只是沒有找到有能力而且願意做的博士班學生。今晚突然想關心一下Tachyon的時候，發現他變成了1.0版，而且名字換成了Alluxio (註1)。想多了解一下為什麼換名字，就讀了作者的部落格。



Tachyon/Alluxio的作者HaoYuan Li還在唸博士班，讓我們來看看他的技術創業故事，也試著看看那些地方用得到上述的技能:

1. HaoYuan Li是2008年北京大學畢業的學生，先到美國Cornell大學念碩士，2011年開始在UC Berkeley攻讀博士。他在北大時，在2005-2008年就到Google實習；2010年拿到Cornell碩士後，到Conviva這家2006年成立的新創公司做了一年，才到Berkeley念博士。所以在念博士班之前，就具備了相當的業界經驗。 
2. 他看到AMPLAB實驗室出品的Spark和Mesos這兩個軟體紅起來，卻同時也看到這幾個軟體的不足之處 ，這應該就是所謂的Critical Thinking。 
3. 於是在2012年底產生了Tachyon技術來補充不足之處的想法，這是所謂的Creativity。 
4. 評估之後，決定這是值得研究的題目，馬上開始做，花了幾個月做出了Tachyon的雛型，這是Judgement and Decision Making。 
5. 在2013/04開放原始碼，以與社群合作的方式繼續研發，這需要Coordinating with Others的技能。 
6. 再花了兩年的時間不斷去改進Tachyon ，這就是博士班最強調的Complex Problem Solving 。 
7. 在2015年獲得750萬美元的投資成立公司。到現在，阿里巴巴、百度、華為、IBM、BARCLAYS等大公司都開始用這個軟體，不知道Alluxio這個公司現在價值多少? 他作為CEO，要讓公司發展，可不能光憑技術，也需要People Management、Emotional Intelligence、Service Orientation、Negotiation等技能。 

當然啦，再說一次，我這裡談的是新創，而且不是說其他的技能不重要，也不是說一定要有這幾個技能才能做新創。個人要如何發展，應該是看個人的資質和願景而定，只是說世界在變，大環境所重視的技能也在變，統計上的資料有其參考價值，但還須要多觀察實際的例子以及了解自己的特性。

理想上，上述的技能，當然是越早適性開發越好，但我們常常批評在台灣長大的人，只會念書考試，我想中國也不遑多讓。我想HaoYuan Li本身的資質應該是頗優秀的，不過在這個例子裡，可以看到UC Berkeley研究所提供了發展和應用技能的環境和機會。這樣的研究所環境，台灣有沒有呢? 以前的學術界的問題已經談過很多，在此就不說了，現在學校比較重視新創和產學，所以建議諸位對新創有興趣的同學和業界朋友，可以設法找到這樣的環境，善加利用。

(註1) http://www.alluxio.com/2016/02/allu⋯⋯

改行做軟體與自學新專業

某位臉友來信談到轉行自學的問題，由於是常見問題，在徵得他本人同意之下，我公開回答他的提問，也希望諸位先進給與指教。

Q. 臉友提問：

我是您Blog & FB 的追蹤者，長時間閱讀老師所寫的文章，而老師也時常點出業界的弊病及提出改善的方法，台灣須從高資本低技術轉型到低資本高技術產業，已是刻不容緩的事情。

本身研究所畢業之後從事顯示器背光模組機構設計(兩年)，近年來因技術被大陸追趕，不斷被搶單，而高層只想賺可以立竿見影的easy money，不願意長期投資先端的研發。因為硬體開發成本高的特性，底下的工程師縱使再有想法也無力影響公司改變，最後是失望離開。

因想要轉職＆政府補助，在資策會進修過java web設計，目前做銀行ＡＰ的軟體撰寫。但是從硬體產業跳到軟體產業，發現若不從事深度技術的研發，依然是在做代工。若是想往系統底層技術發展，勢必須在系統軟體鑽研，而根據老師你近日的文章表示，此領域若不能全心投入很難有顯著的成果。

雖然本身透過下班之餘自學，但以非相關背景進入此領域還是感受到困難。由於您在平行運算＆異質系統有深刻的研究，希望可以請教老師有關學習＆如何踏入這行的建議。

A. 我的回覆：

在這個資訊全球化的時代，如果只是會做一些眾多人都會的東西，技術門檻不高的話，那麼無論做甚麼，所可能獲得的利益，恐怕還是會和硬體代工業或是傳統產業差不多，除非有個富爸爸或是政府補助。甚至由於資訊科技的進步極快，較為浮面膚淺的東西過不了多久就被淘汰，因此要在資訊界安身立命，談何容易？

如果細心看我的文字，我從來不隨便鼓勵年輕人走資訊科技這條路的，我只是說資訊界目前需要人才，而且在可預見的將來還持續提供人才發揮能力的舞台，但未必所有人都適合走這條路。事實上，這條路並不容易走，如果只是偏重技術研發，沒辦法在生態系中佔據一席之地的話，到頭來還是只能以技術代工，甚至在一窩蜂搶訂單，無法向上發展的情況下，就會遇到您所見的窘境。

我所謂的在生態系中佔據一席之地、向上發展，並不是說一定要擴大營業額、做品牌行銷。那是一般的迷思，覺得代工廠賺錢後，就應該放大利潤、朝品牌發展、直接面對消費者。我認為，以台灣本身的市場規模和經濟實力，在大型消費市場上做品牌行銷，需要大量資本和商業操作，如果沒有技術門檻的保護，很容易踢到鐵板。

因此，其實我並不反對代工，只是我們總是希望工作可以換取更高的報酬。代工業者如果精益求精，提高自己與競爭者的技術差距，就有機會獲得較高報酬。例如台積電、鴻海這些公司，雖然是代工，但他們長期在製造技術上所投入的研發，讓他們得以在生態系中佔據一席之地。

但是要向上發展的話，不只要會做漸進式的改進，而是要能解決原本不會，或是更複雜的問題。例如組裝iPhone的工廠和設計iPhone的Apple相比，一個強調代工製造的能力，一個強調「Think Different」，各有各的專業，但專業的報酬有頗大的差別。雖然很多人都覬覦Apple的高獲利能力，但這並非台灣的廠商能夠快速趕上的領域。

單單只是換個方向朝「軟體」發展，如果不能提高技術門檻的話，也很難提昇工作的報酬。美國的公司，在十多年前就將一些軟體的工作外包到印度去，而印度也欣然地扶植其軟體代工業，然而迄今印度的軟體技術以及從業人員的收入，仍然大幅落後美國。

印度的軟體代工人員的薪資不高的原因是軟體越來越複雜，用途越來越廣，但提高軟體價值的關鍵不在於軟體本身，而在於如何使用軟體開拓新產業，或是提昇既有產業的競爭力。因此，如果我們不改變想法，一頭熱投向軟體產業，做一些低技術門檻的軟體代工，那結果可能就如同您所描述的「從硬體產業跳到軟體產業，發現若不從事深度技術的研發，依然是在做代工」。因此，我希望國內在做軟體研發的時候，能夠找到一些方法來提昇產業的競爭力，包括與特定產業領域知識的深度結合，或是在軟體技術上產生差異化。

想與特定產業領域知識的深度結合，以您目前做銀行ＡＰ的軟體撰寫的工作為例，如果只是被動接受委託寫出銀行所需的軟體功能，那就是代工；如果您能夠深切了解銀行的需求，主動提出可能提昇銀行競爭力、因應未來需求的軟體方案，那就是目前最熱門的金融科技（FinTech）了。同樣是幫銀行寫軟體，工作性質有很大的不同。如果要做金融科技的話，就要有能力跟得上這門快速進步中的新興領域，如同我一開始講的，從業者本身若是沒有兩下子，談何容易？

那麼要在軟體技術上產生差異化，可以怎麼做呢？方法頗多，如我昨天在「開源系統軟體」社團上貼文提到，我們可以把改善開源軟體效能的方法分為四大類：

1. 改進演算法，這個是大多數CS的學生都可以試試看的

2. 加入JIT編譯技術加速，範例請參考Jim Huang (黃敬群老師)的筆記（註）

3. 改以平行化，分散式計算或異質運算加速

4. 改進資料流動的效率，例如以DMA/RDMA傳送資料，以caching存取常用資料，以memory取代硬碟存放大數據

要解決實務問題，招數不嫌多。第一招是最多人可以嘗試的，像是參加程式設計競賽一樣，要想到別人想不到的最佳的演算法，難度頗高；第二招需要懂一些動態編譯器的技術，屬於比較硬一點的軟體技術；第三招需要搭配計算機架構/平行計算/網路/GPU，也有其難度；第四招則需要打破傳統以計算為主的思維，在系統層面觀察實際資料的流動，再以軟硬體綜合規劃的方式去改善效能。

然而，要精通上述的每一種招數，都需要花費時間去學習和應用，很難速成。黃敬群老師昨天來我課堂上講三小時，學生起碼要花三十小時才能有起碼的了解，都是學生們必須自己嘗試去學習的，如果所有的東西都要等老師來教，那將來要如何面對快速進化的開源系統軟體？

今天有位大四的學生對我說，他聽了黃老師的課之後非常惶恐，覺得自己懂得太少。我勸他不要太擔心，因為業界有太多人基本的軟體功夫不夠扎實，很少跟社群接觸，根本不知道自己懂太少。知道自己懂得少，有幸遇到明師願意指導，就好好把握學習機會，只要一路學下去，就有機會成為專家。

此外，要使用上述招數之前，必須有能力解析資訊系統和複雜軟體的功能和效能，這些也不是短期間能夠精熟的東西。而且，就算能精通以上的技能，我們還是要回歸到應用面，想辦法用這些技能去改善高價值的軟體應用，提昇產業的競爭力，這樣才會得到重視。

所以說，您問到要如何踏入這行、鑽研系統軟體，這固然有其困難之處，但我想更關鍵的問題在於，您是否了解這個行業快速變化的特質，是否能夠適應這種不斷在演進的場域，願意花多少時間來學習成為專家，以及未來想如何展現身手、持續精進？如果只有下班之餘能夠自學，也不是不可行，但要在有限時間和資源之下迎頭趕上，恐怕難度頗高。

我個人已經浸淫在資訊科技將近三十五年了，到現在還是時常要涉獵新領域、學習新知識、思考新問題，才能維持自己在這個行業的競爭力和敏銳度，如果將此視為興趣，自然會樂此不疲，但若以此維生養家活口，那麼可能還是再考慮一下吧？

延伸閱讀: 關於產業轉型的部分，我另外寫了一篇網誌，可以參考一下: https://www.facebook.com/notes/洪�⋯⋯

（註）

https://ntuoss.hackpad.com/Mar-1-20⋯⋯

https://embedded2015.hackpad.com/Co⋯⋯

非絕招的絕招 - 淺談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.

程式語言

剛剛在臉書上與朋友談論到程式語言。

C/C++對我們做系統研究是很重要的，不過對於某類開發者來說，則強調利用scripting language來使用現成的工具做應用，求新求快。我們應該不能說這些程式語言有高下，但有些人像是入了某個宗派，一昧說自家的好，別家的不好。

說自家的好處，也無可厚非，只不過針對語言的使用情境應該要分辨清楚，而不是以偏概全地說，學某某語言才是王道。我想東西只要有用，都有其重要性，況且程式語言只是個工具，學生要能舉一反三，無論學生先學C、Java還是Python，重點都在於計算思維，如果真的懂了，第二種語言只是一碟小菜。

但教者和學者要知道語言與應用的關聯性，各種語言有其最佳的用途。學生如果不會C的話，進我的實驗室或是到業界從事與系統相關的研發工作時就會有問題。當然，這不代表學生不能先學Python再學C，也不代表他不能花時間學 Python或其他，而這個例子，當然不代表所有資訊產業。

不過，所謂「由奢返簡難」，由scripting language入門者，在遇到較低階的語言時，比較常有適應不良的情況。而設計應用軟體的，用很多友善的圖形介面工具，如果突然來做系統軟體，也常常適應不良。這是習慣問題，並不是改不了，如果當時學習得法，不是硬記的，問題應該不大。如果是硬背的，那當然就麻煩大了。

以下專談系統軟體人才的訓練:

我們發現大多數學生到了研究所，對於系統軟體所需具備的程式能力還欠缺許多，而過去系統廠大多只希望受過訓練的學生去幫系統寫驅動程式，所以學生們也不願積極學。所以我最近在推動的開源系統軟體，也有一部分的原因，是基於這些問題。然而有太多系統商等著要揀現成人才，卻不願贊助人才培育，只會大喊人才不夠。

我人微言輕，平時指導幾位學生，或是跟朋友們分享我認為系統軟體的重要性，而教育的決策，需要更多人一起來影響。例如，廠商若認為系統軟體很重要，不妨多提供一些高級研發的工作機會，或是直接提供資源贊助做系統軟體教學研究的老師。

我隨時歡迎關心人才培育的業界朋友來提供意見和資源，當意見是好的，資源也到位的時候，那麼對的事情就可能發生；但如果沒有直接給予資源，可能意見再好也沒有用。培育菁英系統人才是很耗資源的，需要有先進的設備和足夠的經費，我們才能多做些貢獻。

深耕自由系統軟體

我們提出一個以自由的系統軟體為基礎做效能優化的計畫，重點不是要創造全新的自由軟體，而是「善用」自由系統軟體去解決電腦系統面的問題。

我認為，過去在推動自由軟體時有個盲點：只重視產出新專案的件數，而且多半還是以應用軟體為主。結果雖非全然無用，但國內有多少好用的應用軟體是源自於自由軟體計畫呢？

執行面的問題，出在學校教授被要求要生產論文，而花費很多時間教學生以軟體工程的規範去寫軟體，需要寫文件和測試，根本不划算。光是要學生用英文寫好文件，以及與國際接軌，就是一大挑戰，到底是教資訊還是教英文？非常花時間，不如做理論去。

所以我自己在經營自由系統軟體研發時，傾向於以下的作法：

(1) 學生要先學會「使用」和「瞭解」核心的自由系統軟體，例如Linux和OpenStack裡面的好東西。沒有使用，怎麼會深刻瞭解呢？而且這些核心的東西，到很多地方都用得上，學了不會浪費時間。

(2) 「研究」重要的自由系統軟體，例如KVM, QEMU, Hadoop, Spark, OpenXXX之類的東西，看看其中有哪些效能問題，或是功能不足之處，或是架構的改良。這當然必須考量人力、時間、資源的限制，尋求業界的支持，而且最好是有個夠大的團隊和夠專業的人才。

(3) 如果研究有成，希望能夠改良既有的自由系統軟體，或是加入新元素，「回饋」自由軟體社群；或是以自由系統軟體為基礎，打造創新性的產品。這些是我們所樂見的目標，並非申請專利和發表論文，請長官不要用錯誤的KPI來評鑑計畫。

我想，這是值得深耕的領域，而如此按部就班地去做，應該會有好的成果。即使政府部門不贊助，我們也渴望與產業界好好地共同來經營這塊。有錢出錢，有力出力，希望能做出傲人成績，去改變論文掛帥、KPI評鑑的弊病，也為下一代鋪路。

談軟體測試

軟體測試是一門很艱難的工作，軟體工程絕對不是會寫程式或是開發演算法而已。舉例來說，前幾天Facebook Android App一個bug讓我好幾天沒辦法發訊息和留言，還要我自己搞定。

這個bug跟密碼登入和multi-process programming有關：改密碼後，使用Android的Facebook App重新登入，但是無法留言和送訊息，原因應該是Facebook的外掛Messager程式不知道密碼改變了，所以一直送不出留言，但是也沒有給任何錯誤訊息，反而讓打了一大串的留言消失。

解決方案是直接打開Facebook Messager App，強制登出。這應該是Facebook App自己應該做的事情，但是它沒有做。Facebook這麼多厲害的開發者，還是如此，說明軟體測試的難度。

這個問題還有可能跟出國有關：在台北的時候沒問題，到日本才出問題，我一度懷疑到電信商頭上。如果是跟地區的網路服務有關的話，測試就更困難了。

這個問題可能比較特殊，因為還牽涉到資訊安全，但是可以作為一個很好的教案。也就是說，軟體工程要懂很多東西，還要會發揮想像力。

這裡提到好幾項技術領域：multi-process programming, networking, data center, distributed storage, privacy, security, cache coherence。具備實務經驗的高手，可以根據短短幾段描述想像出問題的來源，軟體高手的生產力，比庸手高太多了，就像神醫和庸醫一樣，天差地差。

不過，一般公司的QA通常是照著人家給的流程進行測試，應該是沒有能力自己發明測試流程，更不要談除錯，或是給建議了。測試流程，通常是產品設計師訂的，會有盲點也是人之常情。要突破這個窘境很難，除了願意請資深的產品設計師出來帶領驗證團隊，還要找到願意接這種位子的工程師。

Intel的晶片驗證工程師，往往比晶片設計工程師還要有經驗，原因便是如此，而且因為硬體不能有bug，所以非得如此不可。軟體界因為微軟一天到晚出問題，讓大家對於bug的忍受度不斷放大，所以軟體QA受重視的程度並不高，除非是mission critical的系統，另當別論。

扎扎實實學工程，斤斤計較做虛擬

徵求：研究助理、博班學生、碩班學生。
計畫：Developing Innovative Virtualization Technologies for Heterogeneous System Architecture.
目標：創新技術、新創事業。
要求：有心走在科技尖端、做事能夠專心致志。
團隊：清大＋台大的五位教授與研究生。
時間：希望一年有小成就，計畫可做三年。

什麼是Virtualization Technology? 其實虛擬化（Virtualization）是一個廣義的名詞，在一個有介面（Interface）的地方，把介面以下的實物減量或拿掉，卻仍然可以利用虛擬化技術讓在上面的使用者感覺不到介面以下原來是虛的。

喔，這如果不是神奇的魔法，就是偷工減料、以假亂真的黑心商品？但話不是這樣講，傑出的工程師講究的就是以最少的資源做出令人滿意的產品，這跟愚昧的工程師或是黑心商人為省成本而不顧品質，相差太多了！

對，遠通eTag事件就是一個為省成本而不顧品質的範例。之前有很多的範例，如果台灣的老闆們執意要把省成本作為第一優先，那類似的狀況將來會更普遍。為了省成本，我們可能葬送了整個世代的競爭力。

唉，學術界不也如此？想要用最少代價，爭取那世界大學排名，大老們想出來的策略就是逼著大家寫論文。這樣子不只把「世界大學排名」給虛擬化掉，把學位的價值也虛化掉，是傑出還是愚昧的教育工程？大家心知肚明。

X， 那要怎麼辦呢？天外飛來一句：『扎扎實實學工程，斤斤計較做虛擬』。按定義來說，簡單的東西就不是工程了，所以學工程沒有捷徑，必須扎扎實實搞通複雜的東西。搞通之後再來做虛擬化技術，心態上必須仔細斟酌，哪些資源可以減量，用什麼方法可以讓這樣做對於效能的影響降到最低？

是，讓一顆CPU當做兩顆CPU來用，讓一台機器上跑多台虛擬機器，讓程式覺得有一大堆記憶體可以用，讓使用者不需要擔心工作是在哪裡做好的，這些都是業界耳熟能詳的虛擬化技術。

但，新的HSA架構，要如何虛擬化才好？我們有些想法，但很多東西要做下去才知道。有意者請來找我。

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研究的風景很美，比霧濛濛的雲端好多了，躬逢其盛的學術中人，不妨多多走出象牙塔看看。

OpenCL 2.0

OpenCL 2.0規格要開出來了，有一些有趣和實用新功能。對於手機系統來說，2.0應該是好用多了，或許我們該跳過1.2，提早看2.0。
https://www.khronos.org/news/press/khronos-releases-opencl-2.0

- 如何把OpenCL 2.0的implementation做好，對於聯發科是挑戰，也是機會。
- 如何善用OpenCL 2.0的新功能，對於應用開發者是項挑戰，也是機會。
- 我們這幾陣子講硬軟體統合設計，這就是個好例子。看看這些新功能就知道，都是跟效能最佳化有關。
- 有興趣的同學可以下載規格來看看，自問是否看得懂? 看得懂的話，就表示你可以活用平行處理、計算機結構、作業系統所學的知識。規格下載點:
http://www.khronos.org/registry/cl/specs/opencl-2.0.pdf

Facebook貼文出去後，有位朋友的朋友  Champ Yen，寫了以下的留言，因為寫得很讚，所以在此分享給大家:

路人甲又來不自量力地獻醜一下

1. Shared Virtual Memory (共享虛擬記憶體)
這點應就是 AMD 所倡導的 HSA, CPU-GPU 間能夠直接使用 Host 上的 pointer 傳遞資料, 好處是能夠減少因為 Host-Device 位置空間的不同所做的資料傳輸, 由於 Host/Device 能夠有一致的 VA, 因此對於硬體的挑戰是, Device 可能必須支援 Host Processor MMU 的 page table 格式.

2. Dynamic Parallelism (動態平行化)
應該是單純的 software framework 的改進, GPU 能夠 self-enqueue kernels, 減少 CPU 的介入. 如此可以降低 Host Processor 在 OpenCL 中的重要性. 官方說法是當 CPU 速度不夠快時, 這樣的作法效能較佳.

3. Generic Address Space (通用記憶體空間)
由於 1. 的緣故, OpenCL 1.x 的 Memory Model (global, local, private) 已不適用, Device 可能是直接針對 Host Processor 的 Buffer 計算讀寫, 因此 compilation time 時無需再使用 local, global 等修飾詞.

4. Images ( OpenCL 的 Image 功能)
Image 是 OpenGL/OpenCL 的特別功能, 主要在於 OpenGL Sampler 硬體的支援, 與材質很有關係, 也關係到顯示的部份, OpenCL 1.x 不支援在一個 Kernel 中對同一 Image Buffer 同時提供 read/write 的能力, 移除限制的好處是可以直接對 Image 做修改, 減少這樣的限制造成的 Image Buffer 需求, 許多運算可以直接on-the-fly, 特別是現在已很常見的 FullHD 或是下一世代的4K2K這樣的解析度, 如此能夠大幅減少相當的記憶體使用量, 另外也增進了與 OpenGL 協同的能力, 這對於計算畫面到 OpenGL 有更方便的支援. 硬體上實作上在 image buffer 的使用與 Sampler 硬體可能必須考量讀寫流程與同步上的問題.

5. C11 Atomics
OpenCL 1.x 僅支援 inter-workitem synchronization, 這點應該支援有限的 inter-workgroup synchronization, 這部份應該也是軟體支援上同步機制的要求提高了.

6. Pipes
這點對於硬體的影響是強制必須提供足夠彈性的 DMA 支援與介面.
Pipe 提供了動態資料流動的能力, 在 OpenCL 1.x 的時候, 必須 Kernel 執行之前特定把所有的資料配置完成, 程式在運作時都是存取固定的資料, 這樣的設計缺點是必須遷就資料的流程來設計程式, 另外執行前大量 memory access, 在需大量資料的情況可能會因此造成效能折損, 再者這樣一陣一陣的 memory burst access 對於 SoC 系統並不是好事, 而在 1.x 這樣的問題, 是在 Host 端透過各別的 Queue, 來分開 Control 與 Data 的傳輸, 但這樣的方式也取決於該硬體平台的資料傳輸部份是否支援這樣的行為, 這裡藉由納入規範的 pipe 將能夠對 memory 的存取能有更平均且有效的利用. 

7. Android Installable Client Driver Extension (Android 的 ICD 擴充)
看來是準備推廣到 Android 平台上了.

個人認為比較可惜的是 SPIR 沒有列為必要的項目, 僅僅列在 extension 的部份
對於 Programmer 來說, OpenCL 2.0 的限制變少了, 提供了 pointer 傳遞資料就讓Programmer 不用再考慮Host-Device 間惱人的 buffer 同步問題, 更不用說這樣最大的差異是 Programmer 能夠輕易地 leverage to GPU, 未來因為HSA所帶來的影響可以說一定非常巨大(想想 GUI framework or Vector Rendering 這類軟體架構與環境, 能大幅利用 OpenCL 來分散工作, 大幅提高效能), 還有 Pipe FIFO 這工具可以使用, 同步上也提供了更多的機制. OpenCL 2.0 對於 Programmer 的友善程度真的是大幅提升, 可以說我同意 OpenCL 2.0 可以說是 HW-SW co-design 的好例子.

從來沒有比現在更適合作實務研究的時候

為什麼我喜歡做較實務的研究呢？其實，是因為我不敢做太理論的研究，因為我總是搞不清楚那些沒辦法和個人親身體驗連結在一起的知識和理論。所以，我很不會背書，因為，已經懂的東西，我不覺得需要背；沒有辦法和我的經驗連結的東西，就算背起來也馬上忘記。

最近買到Raspberry Pi，除了喚起三十多年前的回憶，實體東西自在手上把玩幾下，網路關於Raspberry Pi的資訊和討論，包括Wikipedia上的一大堆資料，瞬間變得有意義，這是動手做學東西，似乎可以用來作為hackschooling的材料。

現在要教Embedded Systems課程可用的教具和參考資料比幾年前多太多了。之前我教Linux Device Driver的時候，沒看到幾張好用的板子，現在有一堆open hardware，在這些open hardware上面可以跑一堆open software，就像這篇所介紹的：

• Arduino Uno vs BeagleBone vs Raspberry Pi

幾年前WSN (Wireless Sensor Network) 似乎很熱門的時候，我一點興趣都沒有，因為那些小小的板子速度慢得很，卻貴得要命、貴得沒有道理，不同的硬體規格、作業系統、網路（Zigbee）相容性有問題，除了發論文唬人之外，我才疏學淺，根本想不出什麼有意義的研究。

或許下學期和 Daniel Shih 合開的系統專題研究課程，我們可以考慮讓同學動手玩一玩這些玩具？BeagleBone有新版的，速度可到1GHz，還有 HDMI介面。實驗室還有一些ZedBoard，上面有雙核心的ARM和FPGA，功能更強大，不過體積比較大。

玩這些東西，希望能有一些新創意。我們整天搞系統的人，往往沒時間去想應用，這點倒是該注意。這些open hardware/software，最大的作用，在於它們能夠讓有創意的人，不需要花太多時間在系統上，快點做出雛形（prototype）。當初Apple II也是如此，讓電腦進到一般人的世界。

注意周遭，是否有值得改進的東西？假如能放個小如卡片的電腦在這裡，能夠做什麼好事？這小如卡片的電腦本身能力可能不強，但是連上Internet之後潛力無窮。

不過，不要再提說要把這東西放在冰箱上的這種老掉牙的創意了。「智慧型冰箱」可以監控你每天進出冰箱的食物和熱量，很多人試過了，好像沒多大實用價值。從生活中得到一些啟發，解決一些自己切身相關的問題，全新的主意得來不易，但其實也沒那麼難。

談異質系統

這篇談【How Facebook and Google are changing the future of Intel’s CPUs】

Google和facebook是有辦法用Arm來提高他們的競爭力，因為他們有懂得硬軟體整合的人才。其他很多公司目前還沒有，給他們Arm servers 也沒多大用處。

軟體的部份還有欠缺，尤其是虛擬化和系統軟體，Arm陣營就像馬政府，目前只能說先求有、再求好，短期還無法威脅到Intel。

Arm主導的異質多核的big.LITTLE架構，就是ㄧ個先求有，但還不夠好的例子。因此，MTK現在還不想碰Arm servers，我可以理解。

我如果有錢有時間的話，這兩年訓練出ㄧ批懂計算機結構和系統軟體的人，成立ㄧ家技術諮商服務公司，將來專門幫中大型公司轉型到異質系統，應該有機會賺不少錢。

為什麼會賺錢呢?

1. 看的當然不是臺灣巿場
2. 一般公司IT當然不懂怎麼做
3. 因為1&2, 所以才會賺到一般人賺不到的錢。

談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來玩，有興趣的同學可以來詢問。

略談科技創新與發展

綜合這幾天所見所聞的心得。

朱敬一：科技創新 3箭齊發
http://m.udn.com/xhtml/HistoryArt?articleid=3065947
國科會主委朱敬一昨（28）日表示，台灣科技業尋求創新要符合「市場第1名、破壞性創新、企業規模大」3個特性...

什麼是「破壞性創新」（disruptive innovation）？這是當今普遍在商業和科技評論上用來形容科技界重要技術進步的名詞。

參考 http://en.wikipedia.org/wiki/Disruptive_innovation：
"The term is used in business and technology literature to describe innovations that improve a product or service in ways that the market does not expect, typically first by designing for a different set of consumers in the new market and later by lowering prices in the existing market".

這是個很有趣的定義，但問題來了，既然disruptive innovation是market does not expect，那光是靠業界本身市場主流派人士是根本看不到的。所以朱主委用心良苦，但是如果業界和政府做科技研發的本位心態不改，談了半天還是白搭。

要有disruptive innovation的話，要靠一些獨具慧眼、有熱情、有能力、有毅力的怪才，長期耕耘他們有興趣但是主流派覺得賺不了錢的領域，絕對不是某個組織說要做馬上就能夠有感覺的。台灣在世界disruptive innovation的舞台上，一向扮演的是後來者，"later by lowering prices in the existing market"，角色也很重要，但目前逐漸被中國大陸所取代。

台灣要做破壞性創新，要先去除短視近利的心態，否則一大堆人都跑來誆你跟你騙錢。我們實驗室有一些有可能產生disruptive innovation的研究，但廠商聽到時只關心是否馬上可以用來賺錢，國科會只關心發了多少論文、技轉金額多少，就連孔祥重院士覺得做得還不錯的研究計畫都不願意長期支持，台灣的大環境還沒有準備好，朱敬一主委要推動改革的地方還很多呢。

軟體產業很適合搞破壞性創新和持續性創新，但是國人短視近利的心態，到目前為止連扎根都扎不穩，根本還談不上有什麼真正重要的創新。

張善政說台灣不會做複雜軟體，我很同意。我看過國外怎麼研發複雜軟體和系統，我知道國內為什麼做不出來。國內幾個單位搞雲端，當做人才培育的搖籃還可以，在短期間之內很難真正搞出什麼名堂；慣於硬體代工的業界，整體在軟體方面既不重視也沒有遠見，不然「資訊系」早就應該跟隨國外的趨勢水漲船高。以在下之見，在國內至少應該與電機系平起平坐，但一般長輩在沒有看到軟體產業大賺其錢之前，大部分還是不敢鼓勵學子把資訊擺在電機之前。

要想做好複雜軟體，最好先能夠搞懂複雜的系統；要搞懂複雜的系統之前，最好先搞清楚現有的複雜系統是如何建立的。實際系統的運作，即便是單機，都遠比作業系統所涵蓋的基礎軟體系統架構和計算機結構介紹的基礎硬體系統架構來得複雜許多，即便修過高等作業系統和高等計算機結構，還是差很遠，沒有多年的實務經驗是很難搞清楚的。所以光靠學校努力是不夠的，要有像樣的業界，還要有緊密的產學互動，還要有足夠的時間，才會產生會做複雜軟體的高階人才。

台灣究竟能不能做複雜軟體和系統呢？我認為可以，但是要全力以赴，不然半調子的東西是沒有人要用的。如果政府和業界到現在還搞不清楚要怎麼有效推動軟體產業，產學界在推動的時候還是沒有搞清楚努力的方向，還是以分享資源的方式在玩，我覺得前途堪慮，不如把錢省下來，免得浪費民脂民膏。最近駁回了幾個業界申請政府研究經費補助案，就有這樣的感覺。

有長官提到資訊系本科生畢業竟然不會寫程式，我想應該是特例，我覺得影響不大。我比較擔心的是「得少為足」，有不少本科生以為自己夠厲害，其實還差很遠。這幾天跟幾位長官出國參加MICRO-45，看到國外的狀況，聊到國內學生的學習態度。我一向不認為社會苛責學生的態度是正確的，因為社會沒有給年輕人良好的環境和示範，但是學生或許該有自求多福的覺悟。我年紀也有一把了，經常都還在學習，惟恐不懂最近的新技術，深怕教給學生的是舊的技術；反倒是一堆同學讀書做研究非常被動，不然就只在乎成績、名次、學位，似乎不知道這年頭學位值不了多少錢，做人態度和做事能力比較重要。

參加MICRO-45感想：國外現在有很多優秀的研究團隊，包括學生和工程師，願意花時間研發模擬器和效能分析工具，例如MARSSx86, GPGPUsim, GEM5, QEMU, Multi2sim,... 有些模擬器和效能分析工具越做越複雜，應該歸類為複雜軟體系統研究，把這些東西搞清楚、會使用來做研究、甚至能改進這些東西，就是不錯的訓練。這是我們實驗室這五年一直在做的東西，也是我們在教學和研究能夠帶給同學一些幫助的地方，但是同學本身要願意學，而且肯不厭其煩努力學，不然老師講破嘴也沒有用。

談新iPad與平板產業

看到Apple公布新的iPad和Apple TV，沒有驚喜，也沒有失望，Apple很精準地做出會大賣的「新iPad」。很有趣，昨晚臨睡前在fb上發文時，靈光一閃，就猜到Apple會用「新iPad」這個字 -- 當時浮現的想法是：既然有Macbook Air、新Macbook Air、新新Macbook Air的前例，為什麼iPad不回歸Apple的慣例？

好吧，我想要一台新iPad和一台新Apple TV，可是和往常一樣，不知道是第幾波才會在台灣上市。哪位朋友可以幫我從國外帶回來？真的，請聯絡我，我不想被水貨商剝削。

「新iPad」一出，誰與爭鋒？前一陣子在MWC風光一時的廠家（Asus, Samsung)，跟我當時的想法一樣，只是在「自High」，連Google前天推出的Google Play也一樣，趁著新iPad出來之前講講話，還有一點點新聞價值。

相較之下，光是Display就差太多了，重點不只在於硬體規格，而是軟體支援的問題。即便有高解析度，像是Asus不知何月何日才會出的Transformer Pad Infinity 700 (好長的名字, iPad只有四個字母，名字比較長就比較厲害嗎？）解析度有1920x1080，可是在十吋螢幕上，很多軟體的字和圖會太小。這是在PC上屢見不鮮的問題，Sony有幾台解析度超高的筆電，例如在13吋上放1920x1080，對眼睛很不友善。

Apple的重點在於能夠把原來設計給iPad 1024x768解析度的軟體，自動地放大到長寬各為兩倍的2048x1536螢幕上，讓我們在看螢幕時，看不到惱人的格點和線條，有像看書的感覺，這個我認為是導致iPhone 4/4S成功的關鍵技術，至今在Android上面看不到有效的回應對策，我相信再次會讓iPad成功，這也算是Steve Jobs的餘蔭。

談到Jobs，我想，缺少了他，Apple的產品發表會不再那麼有趣，產品也不再那麼新奇。不過產品的設計感和精緻度，還是會一直保留下去。在市場上，少了Jobs的堅持，Apple比較有可能會更做一些「市俗」的產品，擴張市佔率，我們等著看。

這波打到不只是Asus，連三星也打。尤其是三星，被Apple認定是主要敵人，在各方面下手不留情。台灣廠商的因應策略為何？我猜部分企業主會想放棄高階平板市場，因為太難做了，研發投資高，人才難尋，風險高，不如朝cost-down方向去發揮吧。我認為，在產品規劃策略上，必須考量現實面，但國家和大企業必須堅持和加碼投入在系統研發上。Apple當年的艱難和近年的成功，證明了系統優化和軟硬體整合是當今個人電腦產業致勝關鍵，也證明了，只要堅持研發，就有機會成功。

「留得人才在，不怕沒機會」。

專題研究導向的課程規劃(2010.09~2011.06)

有鑑於研究生對於做專題的能力不足，欠缺解決問題的能力，又沒有太多時間和機會能接受比較正式的訓練，今年我打算換一個方式來教授研究所層級的課程，在課程中著重專題研究和個別指導，幫學生打下獨立研究、資料搜尋、實際製作、論文寫作的基礎能力。

要參加這些課程的學生，必須有以下的認知：

• 對於做專題有濃厚的興趣
• 有足夠時間收集資料和實作專題
• 能夠每週參加課程討論

上課進行方式，原則上：

• 1/3 時間是講解課程相關知識(lecture/textbook)
• 1/3 時間討論research papers
• 1/3 時間為student presentations and discussions

上學期(2010.09~2011.01)
Linux Kernel, Systems, and Applications

內容大綱：

• Linux systems


• Android systems
• Cloud computing systems
• Virtualization technologies
• Virtual machine technologies
• Virtual platform technologies


• Advanced Linux Programming (2 weeks)


• Basic parallel programming skills
• Pthread & OpenMP Programming
• Message-passing interface
• Performance analysis


• Linux Kernel Development


• Process management & Interrupt handling (2 hours)
• Kernel synchronization
• Memory management
• I/O devices
• Drivers
• Filesystems
• Network

下學期(2011.02~2011.06)
Parallel and Distributed Programming for Cloud Computing

• Parallelization of Applications
• Shared Memory Programming
• Message-Passing Programming
• MapReduce
• Task Distribution and Process Migration
• Distributed File Systems
• Data Synchronization
• Client-Server
• Performance Analysis