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

如何深耕軟體工業基礎技術？

昨天（5/12）被邀請去參加「行政院工業基礎技術第二期次產業投入與深耕項目產官學共識會議-軟體領域」，聽了第一期的執行成果報告，在座的產學人士，包括我在內，都給了一些意見，因為官方希望知道第二期要做些什麼。

在講我的意見之前，先談談第一期的執行面。被派來呈現第一期的成果代表團隊有三個，我特別欣賞中山大學黃英哲教授團隊的報告，他說他早在12年前就開始做軟硬體整合的技術，有與業界合作的產學計畫，也有受科技部補助的前瞻研究計畫，當然我在多個教育部教改計畫中也見到黃教授的貢獻。

我欣賞黃教授的成果，不是因為他報告中所呈現的KPI，而是因為我這些年看過多次他團隊所呈現出來的內容，挑戰困難的實作問題，堅定的態度始終如一，不隨波逐流。因此長久深耕而能累積豐富深刻的技術，進而衍生產學計畫、技轉、專利、論文等等，自然是水到渠成的事，毫不意外。

然而，黃教授也誠實地說，他這12年來深耕軟硬體整合技術，最辛苦的就是做第一期深耕計畫的這四年，因為每隔三個月科技部就要研究團隊填表格提供成果報告，而成果報告表格的項目一大堆，衍生產學計畫、技術轉移、專利申請、論文發表、培育人才、開發課程、辦理推廣活動、邀請業師授課、赴業界演講等等。如果績效不彰，可能就刪減預算，甚至停止計畫。所以光是忙著應付這些關鍵績效指標（KPI），就忙得不可開交。光是這兩週，我就見過他來台北兩次做這個計畫的成果報告。

我發言說我深感認同，因為我們也深為KPI所苦，而且這些年來用數字管理，已經早造成了許多嚴重的問題，應該要換個方式來評鑑執行成效，尤其是這個所謂的深耕工業基礎計畫，如果目的真的是為了好好發展那些「在國際上趨成熟，但台灣過去因產業文化，且未能在短時間看到經濟效益，以致於產業尚未投入深根之技術」（請參考下圖），就應該不是這樣的做法。



這個工業基礎技術發展方案，用「三高一廣」來描述其願景，在三年多前一開始的時候只有幾項質性的KPI，但一路執行下來，為了滿足計畫審查委員和立法院的質詢，不斷加入新的KPI，希望參與的研究團隊能夠提出強而有力的實質證據。

實質證據？如果是前瞻研究或產學計畫，或許可以定義好標竿，但一面說要「深根」和「十年磨一劍」，一面又要執行團隊每年拿出績效，要「三高一廣」，可能嗎？同時，由於這些KPI，反而造成許多「務虛」的事情。填表的事情就不用說了，為了要有經濟效益，研究團隊必須配合廠商，因此也不可能把研發的技術免費方享推廣給大眾，於是立意頗佳的計畫，到頭來只有少數廠商受惠、培養少數研究生而已。

我直接了當說，這些繁瑣的KPI不僅無法評估真正的貢獻，而且還扯後腿，讓研究團隊之間彼此競爭而非合作，成果無法在國內分享推廣。

今天要解決這個問題，關鍵不在於談下一期要做什麼，而是必須基於開放方享的概念，來提昇真正作為工業基礎的生態系（ecosystem）。例如談軟體領域，現代軟體工業的基礎是開放原始碼計畫（open source projects），尤其是那些常見於大型軟體工程以及系統軟體的開放原始碼計畫，包括Linux, Android, Apache, Hadoop, Spark, NoSQL, LLVM, Tensorflow等，國內現在極度缺乏能夠好好使用或修改這些開放原始碼計畫來堆疊出大型軟體應用或是建構先進系統的人才，原因是沒有人好好來經營這個生態系！

坦白說，國內在軟體實務工程架構技術上落後先進國家幾十年。不用說先進技術，各位可以到國外參加討論版，就可以知道人家如何從公開的討論和程式碼的分享中培植軟體人才和厚植軟體的實力。上述的開放原始碼計畫，都是經過許多一流專家們千錘百鍊所打造出來的，如同把秘密和寶藏公開放在我們面前供我們免費取用，正是我們好好利用來迎頭趕上的機會，為什麼不把握機會以國家的力量經營這個開放原始碼計畫生態系？

有人說，前幾年科技部不是砸錢搞過開放原始碼計畫嗎？再次，我必須說KPI不對，在執行面上就會失焦。之前科技部所支持的「自由軟體鑄造場」（https://www.openfoundry.org/），目前有將近1976個開放原始碼計畫，立法委員看到數字每年增加很高興，但究竟有多少是有用的呢？開放原始碼軟體貴精不貴多，各位到國外的網站上，可以看到更多的開放原始碼軟體，例如sourceforge.net 就有21539個程式碼。要知道，既然可以免費使用人家的原始碼，我們何必花時間重新打造類似的東西呢？（如果說這是訓練，那要如何證明程式碼不是抄來的呢？）

務實支持開放原始碼計畫，不是鼓勵參與團隊多多發表全新的開放原始碼計畫，應該是聚焦在現有的重量級開放原始碼計畫，鼓勵學界、業界多分享、研究、改進、貢獻這些開放原始碼的技術。學生藉由研究重量級開放原始碼來學習第一流的軟體、強化自己的軟體實力，藉由使用開放原始碼來堆疊出有創意的作品，藉由改進或創新開放原始碼來展現自己的程度。業界要懂得如何善用開放原始碼，而不是看到開放原始碼就轉彎，因為世界上的開放原始碼計畫越來越多、越來越好，看到開放原始碼就轉彎的公司遲早會無路可走，難道沒看到連微軟、IBM也擁抱開放原始碼嗎？

然而，業界要善用開放原始碼來創造價值，一個健全的開放原始碼生態系，其中包括好的人才參與其中、技術的交流、產業的分工。在這方面，我們落後先進國家很多，但是由於開放原始碼的天性，我們可以從網路上取得大量免費的資源加以研究，所以成功的機會遠比那些需要昂貴研究設備的尖端科技，或是需要長期實務經驗累積而成的工業技術來得高，關鍵在於有沒有辦法聚集足夠的高素質軟體人才和產業的參與。

目前的開放原始碼生態系還不夠蓬勃，缺乏業界的支持，雖然許多人有心耕耘，但大多是以社團、同好會、讀書會的形式在運作。雖然如此，但我樂觀其成。這幾個月來我課上演講的業師們，在國內的網路社群上很活躍，他們樂於分享開放原始碼的研究心得，也透過分享讓世界知道他們的才能，對社會和產業造成貢獻。

因此我對長官說，您問我第二期深耕項目要做些什麼？在座的諸位有各種的意見，我也可以把我有興趣或專精的技術項目加進去，但我認為重點不在於技術研發，而在於生態系的經營。至於要如何經營軟體領域中重點項目的生態系？我想可以利用開放原始碼作為基本載具，在上面想辦法加值，把成果分享給所有人，有產官學積極的參與和持續提供充分的資源，自然能把基礎打穩，大可不必讓KPI造成學界、業界的隔閡和浪費資源。

系統人才的出路

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

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

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

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

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

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

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

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

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

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

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

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

人工智慧太厲害了，我們該怎麼辦?

我們為什麼要推計算思維呢? 因為未來各行各業都需要與電腦合作，否則有可能被電腦和機器人淘汰，例如這篇【機器人搶工作　律師、藥劑師也遭殃】所談到的(註1)狀況。如果不懂計算思維，很容易就迷惘了。

最近像這樣的文章和書籍很多，研究未來學的人，認為人工智慧是未來的重要趨勢，極盡能事去想像未來，但究竟有多少真實會發生，有多少只是虛無飄渺的幻想? 我想，很少人有能力確定，不過當前許多學生都跑來研究人工智慧相關的議題，則已成為我在台大所看到的事實。

我三十四年前在高中時，就對於人工智慧很感興趣，開始學LISP，後來進到台大念電機系，修了兩門人工智慧的課，還旁聽過神經網路，到密西根大學念書，也修過人工智慧，但我沒有繼續研究人工智慧，因為我覺得當時研究者走偏了，而且當年電腦的運算速度遠遠不足以支持有意義的人工智慧，所以根本做不出東西。

我猜對了，1990年代之後，人工智慧成為票房毒藥，沉寂了近二十年。

我選擇做電腦系統，看著電腦系統的效能持續成長，電腦系統的研究者想出各種方法來收割不斷成長的電腦效能，過去這三十年，最忙碌的研究領域之二，是計算機結構和系統軟體，我有幸能優游於兩者之間，探討一些軟硬體整合的議題。

如今，單一處理機的運算能力，約為30年前人工智慧全盛時期的100萬倍(註2)，而且只要願意付些許錢，就可以租用雲端的上百台電腦，運算能力更是30年前的一億倍以上。

要注意到，這一億倍的運算效能，是人工智慧東山再起的關鍵。沒有足夠的效能，電腦很難生出智慧。然而，如今的運算效能，是否足以支持未來學想像中的人工智慧，則是一個大哉問。

大部份未來學專家的預測，都是基於以往的摩爾定律(註3)，但這幾年摩爾定律已經放緩，甚至有可能停滯，主要是成本考量。以往這麼多年透過個人電腦、電子商務、行動運算、雲端服務等應用，半導體產業有足夠的利潤做研發來支撐摩爾定律，而大數據分析和人工智慧是否足以繼續支撐摩爾定律的延續? 如果摩爾定律停滯，那該如何是好?

有的人工智慧應用，需要比目前更高百倍的計算能力，有的實驗研究要成為產品之前，需要將龐大的運算能力縮小進到生活周邊，因此我認為我們做計算系統的，在產品化的過程中，還是扮演舉足輕重的角色，將來應該會有做不完的人工智慧系統設計的工作。

要創造出人工智慧的系統，關鍵在於要有能夠密切垂直整合的團隊，必須要有三種專家密切配合:
(1)領域專家，例如找律師、藥劑師來指導或教導電腦該領域的專業技能。
(2)人工智慧專家，綜合運用機器學習、數據分析、資料探勘等方式設計人工智慧演算法與軟體。
(3)系統專家，提供人工智慧所需的系統整合、資料蒐集、處理和計算能力，針對人工智慧應用優化系統軟體、設計晶片。

台灣比諸於其他許多國家，由於有硬體產業的基礎，非常適合發展「(3)系統專家」(這也是我想來培育的，也是目前即欠缺的人才)，加上台灣目前很多學生對人工智慧很有興趣，學得很快，所以我不擔心會短缺「(2)人工智慧專家」，台灣在各行各業也有很多領域專家，但是能否聚集人才成為優質研發團隊，是真正的重點。

我想，很多有識之士已經看到這個局面，這是值得台灣去發展的好機會。我希望國家和社會多投入一些資源鼓勵產學界共同組成「對」的團隊，來把握這樣的機會，讓學術界多做些有益於這類幫助國家產業發展的研發工作。

然而，在謀求發展的機會的同時，我們也應該做好教育的工作，讓未來的世代能夠好好面對電腦和機器人。與其教學生背誦記憶一堆電腦瞬間可解的問題，不如教他們如何活用電腦、想辦法與電腦和機器人共榮。

另外，科技的民主化以及財富的合理分配，也將會是越來越重要的課題。我們絕對不希望大家多年努力的成果，被少數資本家收割，讓科技成為資本家搜刮社會資源和剝奪人民權益的打手 -- 這是社會大眾需要慎重看待和避免的議題。

(註1)機器人搶工作　律師、藥劑師也遭殃
http://www.cw.com.tw/article/article.action?id=5073792

(註2)以摩爾定律概算，假定每18個月電腦效能增加一倍。

(註3)https://zh.wikipedia.org/wiki/摩爾定律

深耕自由系統軟體

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

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

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

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

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

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

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

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