眾說紛紜的AI

昨天(3/31)參加一整天的AI論壇，遇到很多內行人和外行人。主辦單位的目的在於橋接業界和學術界，連哄帶騙把許多AI專家，以及業界與政府的重量人士找來，可謂用心良苦，不過在裡頭坐上一整天也真是辛苦，好像一個人去參加一場長達一天的婚宴，必須一邊跟同桌人士哈拉，一邊「欣賞」舞台上的表演...

我因為前晚熬夜寫報告，昨天在會場頭痛了一整天，一直抽空閉目養神，不是偷懶，是頭痛到不行。不過還是得完成主辦單位交付的任務：花費二個多小時跟15位希望引進（或是正在從事）AI的業界/政府人士談話，瞭解他們的問題，個別給出一些建議，最後還要上台給三分鐘的心得報告。

就當作是做功德吧？因為AI紅透半邊天，迫不及待想引進AI的人太多，平常都有一些個案來找我談，但多半是想找一些有即戰力的技術或計畫，在最短時間可以幫到忙，而真的願意花大手筆做研發的倒是少之又少，大部份在談完之後，摸摸鼻子走了。昨天在最短時間內一次談了15位，也很不錯，只希望對方不要覺得這傢伙沒什麼真功夫，幫不了忙。

昨天最後上台報告時，我說我只是配角中的配角，各位如果開始建置AI系統，就會發現系統端的疑難雜症多得不得了，解決這些系統性問題的辛苦可能遠多於機器學習的部份，這時候才可能會需要我這種配角上場救援。

我沒有大聲說的是，反之，如果對AI沒有起碼的瞭解，分不清楚專家系統、機器學習、類神經網路的差異，可能不要貿然找那些做AI研究的大師，除非這些大師很喜歡做功德，像孔祥重院士偕同陳昇瑋博士那樣願意帶著一群學生「下海」，進到製造業的場域去動手做。不過，孔陳兩位大師現在也不可能親自去幫您的忙，想多認識AI的業界人士，可以繳學費去參加他們辦的人工智慧學校。

我希望人工智慧學校能補足業界的一些人才缺口。好比當年個人電腦出現後，很多中小企業開始導入試算表、文書處理，或是寫一些簡單的程式來做自動控制，需要很多人力來做，而我們當年念高中、大學時靠著自學就可以去做這些事，不一定要念資訊系，這也是目前產業AI化的重要途徑。

但是在AI產業化的方面，需要較長遠的規劃和耕耘。如果要在新興的AI產業上有足夠的競爭力，應該不是膚淺的作為就能做到，因此我認為AI產業化與產業AI化兩大方向雖然相關，但應該劃分和解釋清楚，不宜混雜在一起談，否則容易失焦，浪費彼此時間。

不過我還是跟AI的專家朋友說，昨天這場就算是您在做功德，有些參與的人士很少有機會跟AI大師們對談，有些以為AI很好做，各位大師親自出馬釐清真相，也是莫大功德。

例如我這邊在頭痛的情況下勉力為之，應該算是盡到公民的責任，與業界人士大致交流如下：

1. 遇到一群在政府做水利規劃的研究員與顧問公司，一起思考如何運用AI技術，或許他們更了解AI後，挑戰一些可行的目標，不要太好高鶩遠，可以少浪費一些民脂民膏；
2. 遇到一群醫院主管，和我先前遇過的醫界人士一樣，已經開始導入AI，面對的標籤化資料蒐集困難的關卡，但其實國內醫療界素質頗高，有機會結合AI做出新產業，但是要拿得出足夠資源；
3. 遇到立法委員，跟她談我常講的教育界的問題，也希望她幫忙看緊人民的荷包，不讓政府以導入AI為名胡亂撒錢買設備；
4. 遇到不恥下問技術問題的電子業大廠董事長，有點意外，還是想辦法用自然語言釋疑；
5. 遇到急於引進AI的製造業小廠，建議要找上下游業者合縱連橫打群架，不一定要自己做；
6. 遇到想引進AI幫忙自動產出精華影片的媒體，建議這種國外強到不行的應用，不要貿然自己研發，因為這類軟體遲早會普及，除非你有國外沒有的利基，否則不容易做出比人家好的東西。

總之，千萬不要一窩蜂，無論各位要走產業AI化還是AI產業化的道路，最好先搞清楚狀況，走適合自己的道路。

學生也是，資訊系學生可以去幫產業AI化，但是必須願意跨足產業，例如農業、醫療、製造業，不是宅在房間裡就行的，其他科系的學生也可以修一些AI的課，嘗試走這條路；資訊系學生想走AI產業化的道路，要知道AI系統錯綜複雜，要在此產業競爭，往往不是只懂機器學習的一招半式就行的。

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

近來各大家系統災情頻傳?

今天iPhone災情慘重，一早就有長官打電話來問我，但眾說紛紜，而且我所有裝有最新版的iDevices都沒出問題，所以不知道發生何事，直到搜索這篇報導[1]，才知道問題所在。(註: Apple已經提供新的iOS 11.2，更新後應該可解此問題，但我不負任何責任。)



各位可以好好酸Apple，挫挫他的銳氣也好，或許iPhone會因此降價。不過我不想當酸民，所以想從技術面來談談與此相關的事。

據推測[1]，這次災情的原因可能如下:

"The problem seems to be tied to local notifications received from apps that offer daily or repeat reminders. For example, meditation app Headspace, one of the affected apps, sends daily reminders to users to encourage them to take some time to meditate. Any app using local (as in not pushed from a remote server) notifications that repeat will cause a crash".

出問題的使用者，大概跑了某個會在系統的告示板上重複提醒使用者的應用。不過，會因此而當機，作業系統難辭其咎。

為了效率，Apple對iOS做了很多優化。我們知道，如果把一些功能放在作業系統內部空間(kernel space)，可以節省不少負擔(system call, context switch, memory copy)，然而一旦有點小差錯，可能導致系統當機。

請不要小看這類站在時代尖端的系統軟體工程，這需要極度專業的軟體工程訓練，這不是修過基礎的作業系統原理就能勝任的，複雜度遠遠超過寫微控制器的程式，或是寫裝置驅動程式。

系統驗證的難度與日俱增。當系統越來越複雜的時候，越難以保證系統絕不犯錯。軟體驗證工具，如果使用得宜，可能降低出問題的機率。

由此可知系統軟體工程人才的重要性，但台灣這些年說要發展軟體，極力強調創新之餘，是否知道台灣業界極度缺乏專業、高階的系統軟體工程人才?

資安的問題也是如此。很多所謂的資安人才，學會如何運用現成的攻擊與防禦工具，但系統軟體內部的資安議題，則較缺乏關注，例如說，怎麼寫出沒有安全漏洞的軟體呢? 如何設計不會被駭客用硬體手法破解的系統?

上個月Intel的處理機被爆料出事了，幾乎所有2015年之後生產的處理機都中鏢[2]。主要是因為Intel在x86處理機內加裝一顆管理用的小處理機(Management Engine)有安全漏洞，影響Windows和Linux的使用者，但不影響Mac。

但Mac的使用者也不要高興得太早，因為OS X有個更離譜的資安漏洞也在幾天前被揭露出來[3]。使用者如果沒有設定root帳號的密碼，那麼駭客就可能可以輕鬆用root帳號登入，不需要任何密碼。

各位可以酸Intel和Apple，但大家每天在使用的Windows，三不五時就有security update，隨時都在補資安漏洞。

要發展複雜的應用與系統，勢必要有硬底子的系統軟體工程人才和系統資安人才，否則產品很容易出事。

話說，使用深度學習打造出來的現代AI系統是否穩定和安全? 這也是相當值得研究的議題。

[1] Date Bug in iOS 11.1.2 Causing Crash Loop on iPhones as December 2 Hits
https://www.macrumors.com/2017/12/02/ios-11-1-2-date-bug-crash-loop/

[2] 英特爾修補影響數百萬台PC與伺服器的CPU韌體漏洞
https://www.ithome.com.tw/news/118487

[3] Mac作業系統重大資安漏洞 蘋果忙補破網
http://www.cna.com.tw/news/firstnews/201711295007-1.aspx

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

昨天（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⋯⋯

博士滿座的系統優化團隊

今天到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還在，只用在高檔的商用伺服器上，據說富有的阿拉伯國家很喜歡買...

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

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

昨天概說了人工智慧過去和未來性 (註1)，在技術面上著墨不多，所以今天來談談技術面。

首先是關於「摩爾定律」，我在半年前寫了一篇「後摩爾定律的世界和台灣的產業發展」(註2)，有興趣的人可以參考一下。我當時說:

「說白一點，摩爾定律是錢砸出來的。摩爾定律的黃金時代，開始於個人電腦急速成長的時代，但個人電腦的效能在十年前就已經能夠滿足大多數個人，所以「世界」對於摩爾定律的期待逐漸降低，雖然智慧手機和平板的異軍突起，但主要是希望摩爾定律能夠提供更高的性能耗能比（power-performance），然而這幾年手機平板已趨於飽和，也沒看到真正個人所需要的高性能耗能比的應用（killer apps），再加上像Qualcomm、Samsung這樣的公司上在推出新的行動晶片上屢次因為晶片過熱而踢到鐵板，所以在既然沒有消費者的需求，晶片製造商也裹足不前的情況下，自然就會降低對於摩爾定律的挹注。」

「我想，在缺乏資金挹注的情況下，摩爾定律在技術上能延續的機率不高，即便不少研究者熱中於此。除非有真正大眾需要的應用，或是再度出現軍備競賽，否則很難改變摩爾定律的終結。」

但任何事都可能有例外，不能太鐵嘴，還好我最後有加上一個以「除非」開頭的句子。人工智慧是否能成為大眾真正需要的應用，或是用於軍事用途? 我想其可能性還不小，所以我在這幾個月跟一些業界朋友說，不要再搞那些傳統的消費電子產品了，要想想如何將「智慧」加進產品之中。

怎麼把「智慧」加進小型的裝置之中? 基本上，有下列方法:

(1)由小型裝置自己做
(2)藉由網路把工作送到集中式的伺服器去做
(3)藉由網路把計算工作送到周遭多台機器分工合作
(4)上述三種的組合

先說「自己做」行不行? 現在很多人手上的手機，能做多少事情? 其實手機可以做很多事情，只是會遇到過熱和電量不足的問題，但是這兩個問題影響較大的是較長時間使用的應用，如果我們要的是「即時性的智慧」，那麼問題應該比較像是「如果手機在五秒內全速執行，能夠解決那些問題」？

舉例來說，即將出現在手機市場上的Qualcomm旗艦處理機Snapdragon 820有多厲害呢? 據說(註3) 這顆晶片的 4核CPU比前一代S810的8核快35%，省30%的電，支援600Mbps的無線網路，其中的GPU也快了40%、省40%的電，還支援OpenCL 2.0。不只如此，他還有一顆名為Spectra的影像訊號處理機(image signal processor)，可以加速影像處理和支援電腦視覺(computer vision)。

要自己做，可以，要想辦法把各種運算能力整合到晶片上。要讓手機晶片有智慧，不能只靠跑在CPU上的純軟體，一定不夠力的。有些應用可藉由GPGPU來加速以資料為主的運算(data-parallel computing)，例如做機器學習的開源軟體，Mahout和Caffe，都可以用OpenCL程式碼跑在GPU上。另外，以影像和聲音為主的應用，則最好設法在源頭解決問題，也就是說在感測器紀錄影像或聲音之後馬上送到訊號處理機，使用專門特殊化的(specialized)計算架構來提升效率，其實電腦視覺也可算是初步的人工智慧。

從上述的例子，可以看到「特殊化」處理機的趨勢越來越明顯，因為用CPU跑純軟體太沒有效率。時下很多人討厭寫C程式，喜歡用像是Java, Javascript, Python之類的高階語言來開發應用，但是對於開發與效能息息相關的系統軟體的人來說，光是懂得寫C程式可能還不夠，要懂得multithread、OpenCL、CUDA才會善用多核心的CPU/GPU，要懂得訊號處理機的架構和專用語言才能發揮其能力，甚至要會使用「硬體描述語言」才能用FPGA來加速計算。

我預測未來這十年，是大家各憑本事、各顯神通，想盡辦法來打造智慧系統的黃金年代。我們將會看到百家爭鳴，在計算架構和軟體設計上不斷推陳出新，快速發展。當然，演算法也極為重要 -- 再厲害的運算能力，也挽救不了愚笨的演算法。而且，針對大系統所開發的演算法和軟體，不見得適用於小機器，例如把Google釋出的Tensorflow裝在小機器上，可能會發現它的效率不彰，所以各公司可尋找屬於自己的利基市場(niche)。

當然，如果不限定要帶在身上，智慧型裝置也可能出現在車上、電線桿上的監視錄影機。因為體積和電力供應較大，我們有機會將百倍於手機的運算能力放進這些裝置。所以某些人工智慧的應用，可能會先出現在這類裝置上，例如前幾天的CES 2016，我們看到NVIDIA和Qualcomm都推出車用的處理機(註4)(註5)，來搶攻這類市場。

這是新興市場，我希望台灣的業界人士看到以上幾段會頗為振奮，尤其是那些在硬體公司寫系統軟體的朋友們，這是值得把握的機會。如果您能夠針對某個智慧型應用設計出又快又省電的系統，那就有機會逐鹿天下。不過呢，要把握機會，必須先搞清楚這些研發工作將會需要「緊密的垂直整合」，最好有一個人才濟濟的團隊，針對應用的需求規劃系統軟硬體，要有「軟體為主，硬體為輔」的思維，最好要找到軟硬兼備的系統架構師(system architect)來領導研發工作，如我在這篇專訪上談到的(註6) 。

當然，我們也可如第二種方法，「藉由網路把工作送到集中式的伺服器去做」，來提升小型設備的智慧。但首先，網路傳輸需要時間，不利於即時性的應用；其次是隱私性和安全性的問題，我們未必希望讓大公司那麼清楚的知道我們的一舉一動，所以也可能不希望把全部的工作送到集中式的伺服器去做；再來，極為耗費運算資源的工作，除非Google能夠由此獲的廣告利益，否則它未必願意提供免費的伺服器資源來幫大眾做這個，所以並非所有應用都會有免費服務。

同時，在資料中心做人工智慧的運算，更需要高效率的加速技術。因此現今很多大公司都在積極找高手來加速需要大量運算的服務，例如微軟有個專門以FPGA加速資料中心服務的研究團隊Catapult，陸續發表加速搜尋引擎和機器學習的技術(註7)。

第三種方法與第二種方法的差別，在於利用較近的機器做計算來縮短時間，選擇能夠信任的機器來保護隱私，以及以互助會的模式來分享互惠資源。我們做過這類模式的相關研究，也實際建構出系統，例如這篇將Android程式中大量數據處理的工作轉移其他機器的作法(註8)。雖然目前還缺乏需要這種模式的高運算量行動應用，不過我相信在未來身邊需要人工智慧的時候，應該會有這類的需求和做法。

實際的作法，也可能是以上三種方法的排列組合。至於如何排列組合，就考驗系統架構師的能力。台灣現在很缺系統架構師的人才，缺到業界連如何善用系統架構師、去哪裡找這些人、如何培養這種人都不知道。以前做代工不需要這種人才就算了，如果現在還不知道，那就難做了。現在業界有不少地方都說要做人工智慧，但我奉勸想加入這類團隊的朋友，先看看帶頭大哥懂不懂，有沒有兩把刷子再說。

(註1) 人工智慧太厲害了，我們該怎麼辦?
臉書版: https://www.facebook.com/shihhaohung/posts/1072464976129323
部落格: http://hungsh-ntucsie.blogspot.tw/2016/01/blog-post.html

(註2) 後摩爾定律的世界和台灣的產業發展
臉書版: https://www.facebook.com/shihhaohung/posts/968793609829794
部落格: http://hungsh-ntucsie.blogspot.tw/2015/07/blog-post_13.html
轉載於Inside: http://www.inside.com.tw/2015/07/14/post-moores-law-and-the-industry-development-in-taiwan

(註3) Qualcomm's Snapdragon 820 INSANE Specs & Features DETAILED
http://www.knowyourmobile.com/samsung/qualcomm-snapdragon-820/23126/qualcomm-snapdragon-820-release-date-specs-features-android-n-launch

(註4) NVIDIA推出車用人工智慧電腦NVIDIA DRIVE PX 2，號稱性能比 Macbook Pro強150倍http://www.techbang.com/posts/40654-nvidia-at-ces-not-flagship-graphics-card-but-strong-for-a-taxi-containing-artificial-intelligence-supercomputers-nvidia-drive-px-2

(註5)
【CES 2016】高通發表 Snapdragon 820A 車用處理器，具機器智能神經學習系統
http://technews.tw/2016/01/08/qualcomm-snapdragon-820a-automotive-processor/

(註6) 深化產學合作！向沒有能力領導創新的大企業說掰
http://www.bnext.com.tw/article/view/id/38432

(註7) Project Catapult
http://research.microsoft.com/en-us/projects/catapult/

(註8) Shih-Hao Hung, Tien-Tzong Tzeng, Gyun-De Wu, Jeng-Peng Shieh. A Code Offloading Scheme for Big-Data Processing in Android Applications, Software—Practice and Experience, first published online May 2014.
http://onlinelibrary.wiley.com/doi/10.1002/spe.2265/abstract

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

我們為什麼要推計算思維呢? 因為未來各行各業都需要與電腦合作，否則有可能被電腦和機器人淘汰，例如這篇【機器人搶工作　律師、藥劑師也遭殃】所談到的(註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/摩爾定律

轉型到Open Source的世界來尋寶

Open source（ 開源碼 ）是時代趨勢，使用者極多的開源系統軟體，例如Linux、Android，很多廠商都愛用，廣泛用在伺服器和手機上。IBM早在1998年引進Red Hat Linux (註1)，而一直視Linux為敵人、說Linux是癌細胞的微軟，就在前幾天宣布全面與Red Hat Linux合作 (註2)。

我當年在矽谷SUN工作時(2000-2005)，公司深受Linux的威脅，員工的意見分為兩派，在幾年間不斷辯論，不斷嘗試各種路線，好幾位主管做不好就下台。「在某些方面打不過他，就包容他、利用他」，似乎是最後的結論，所以SUN在低階伺服器市場上逐漸引進Linux，把自家的處理機、作業系統和中介軟體用於中、高階市場。

後來Oracle收購SUN之後，也是走相同的路線。Oracle正在銷售的Big Data Appliance (註3)，上面主打的是已經安裝、優化好的開源系統軟體，例如Hadoop、NoSQL、Hbase、Impala、Accumulo、Cloudera、Spark、Kafka等等。當然，Oracle也提供自家的軟體，繼續向那些不敢轉用開源系統軟體的客戶收取高額的軟體授權費用，有肥羊可宰，何樂不為?

這些公司很清楚，要如何放棄利潤過低的產品，如何引進公開好用的資源，在這個科技進展迅速、資訊迅速流轉的時代，要如何做抉擇，找出公司研發的策略，是管理決策階層的職責，也是對他們能力的考驗。決策錯誤就下台以示負責，是常見的事情，而高科技本來就是高風險，賭錯了也不是甚麼丟臉的事，否則Steve Jobs哪有東山再起、重回Apple的機會?

話說台灣，一大堆所謂高科技業的主管，即使這些年來把公司和業界搞到了今天如此慘澹，還能夠振振有詞地說年輕人不夠抗壓、政府補助太少，我覺得被稱為「慣老闆」是咎由自取。我在SUN工作的那五年，公司的股票一路貶值到十五分之一，從來沒有聽說有人說要跟美國政府要求補助的，而公司為了保住人才，還是年年加薪。相較於此，台灣科技產業的有很許多領導階層，非常地不負責任。

只會做那些擅長做的東西，對新的東西多半由道聽塗說而來，對其他領域的東西一知半解，卻要在專家和手下的面前裝出一副「我知道很多你們所不知道的東西」的樣子，是最令人厭惡的行為。在有些公司，中階主管們明爭暗鬥，如同政壇，政客出一張嘴，表面上對罵，實際上架空長官、壓榨下屬，私底下串聯分贓，甚至掏空公司。

前天有人問我產業這樣子該麼辦? 我說，這些人要把公司玩垮，我們也沒辦法，只是政府不應該用大家的錢隨便給補助，讓他們早點垮掉，才能活化鎖在裡面的人才，像Nokia衰落瓦解 （註4） 那樣不也是一條活路嗎？否則連人才都爛在裡面了，將來更慘。也就是說，這些年政府補助扶持產業這招，已經行不通了 -- 政府再怎麼補助，也沒有中國政府厲害，所以靠補助才能生存的公司，面對紅色供應鏈，實際上也競爭不過的。

那麼我們就放棄科技研發了嗎? 當然不是。一些朋友和我認為，台灣在眾多可以嘗試的方向中，可以做的一件事，是集中人才去探索那些「資本門檻不高、技術門檻高」的研發項目，包括既有的產業想轉型，或是新創事業想找方向，都可以考慮。舉例來說:

- 如果某一代工產業所需的資本門檻高，但如果技術門檻不高，那對岸可以靠著充沛的資金和人力，很快來佔領這樣的產業，現在大家都看到這樣的結果，但很多這樣的公司還在吃老本，難以轉型。

- 資本門檻不高的新創企業，如果技術門檻也不高，即便靠創意、靠經營模式，也很容易曇花一現，因為創意和經營模式很容易被複製，有錢的公司可以後來居上。

- 能夠發展出門檻高的技術，不只是技術有價值，人才也是國家重要的資源。如果台灣實際上能好好耕耘這塊，才是長久之道。我十月在荷蘭開會，深深覺得荷蘭產業的發展方法，很值得借鏡。

在資訊產業上，要發展「資本門檻不高、技術門檻高」的產品或是服務，一個非常可行的方式，就是利用高度發展的open source軟硬體的基礎，站在巨人的肩膀上，研究如何打造能吸引大家來使用的優質的系統和應用。資本門檻不高，因為做研發時不需要昂貴的生產機具，不需要昂貴的軟體授權，我們只要有一流的人才，就可以藉由閱讀open source來吸取世界頂尖的智慧，並且證明自己的技術能力 (註5)。

當前的問題是，在台灣的業界能夠領悟並且善用開源系統軟體的優勢的資本家和人才不夠集中。之前學界和業界曾經有一些open source的推廣以及研發計畫，很少有能夠聚集火力攻佔某領域站上世界舞台的作為。現在業界所使用的open source，早已不是搞懂一兩個open source計畫，也不是小眾搞一些自娛娛人的計畫就行的 ，如果可以從系統面貫串到應用面，會有更大的機會。

VMFive是一個例子 (註6)。在許多新創公司中，這家公司所涵蓋的技術層面是較廣的，從系統層面的虛擬化技術連結到應用面，大都採用open source，在某些關鍵點上進行優化，提升效率和功能性，節省系統建置成本。

然而，不少新創團隊，偏向低門檻的作法 ，或者低估技術門檻，一昧想在短期內開發出看起來很酷的產品，因此而走不遠 (註7、8) 。傳統系統代工廠的長官們，似乎還活在上個世紀，腦袋轉不過來，對open source一昧排拒，不懂open source的價值，不會運用open source，如何帶領公司轉型打仗? 眼中只有訂單，只會抱著大廠的大腿，不知道以前的運作方式已經落伍了。

話說 2006年時，我們一行人在參訪HTC的時候，公司所有高層都出來對我們簡報，軟體部門擺在最後，乏善可陳，似乎是最不受重視的部門。當時還沒有iPhone和Android，HTC只會做Windows CE作業系統的智慧型手機，唯一微軟願意讓HTC插手的是與硬體相關的驅動程式(device drivers)，所以也沒甚麼前瞻研發工作可做。

在當時那種封閉的生態系，只要緊抱著Microsoft、Intel、IBM、HP等大廠的大腿，提供價廉物美的組件和代工生產，就可以賺得很高興。早在智慧手機之前，PC和周邊的代工產業已經風光了十多年，所謂Wintel的供應鏈，包括Asus、Acer、廣達等系統廠，以及相關的零組件廠，就像當年的HTC一樣，在軟體上沒有甚麼研發空間。

那段期間(2006~2009)我開授Linux Kernel and Device Drivers課程，學生趨之若鶩，廠商也來邀約演講，因為廠商開始導入Linux，但極度缺乏Linux核心人才。學生為了就業而跑來修課，因為學會寫Device Drivers就可以找到不錯的工作機會。

很多資訊工程的人才到這些產業去幫硬體裝置寫firmware和device drivers，雖然很多人因此成為科技新貴，但我常常聽到這些軟體、韌體工程師向我抱怨，做來做去都是差不多的東西，沒甚麼長進；而且技術門檻不高，要與人競爭只有設法做得比別人快，所以常常要趕工加班，累到過勞爆肝。後來我不大想開這門課，因為我不願學生去幫缺乏研發企圖心的廠商賣肝，而且我認為這種行業撐不了多久。

2009年，Google正式釋出Android的開源碼，而HTC也幫Google開發出世界上第一款Android手機。挾著以往做Windows手機的經驗優勢，HTC靠著硬體技術、研發速度、穩定性、工業設計、行銷管道，在一開始那幾年做得有聲有色，非常風光。

HTC崛起的案例，大部分可以說是受到open source和Google的加持，加上員工們辛勤努力，所產生的必然結果，也算是時勢造英雄。Android最早由2003年成立的新創公司開始研發 (註9)，2005年被Google收購後繼續改進，總共歷經7年才釋出，如果不是Open Source和Google，不可能造就HTC一時的榮景，也不可能與Apple競爭。

可是，Android雖然是open source，但規格主要還是掌握在Google手上，所以HTC做了幾年，又回到老路，在系統上並沒有特別突出的賣點。當時HTC除了在軟體上抱著Google的大腿外，在處理機上抱著Qualcomm的大腿，看人家給甚麼就做甚麼，在系統設計上沒有很大發揮的空間，所以我看了搖頭，不知道他拿甚麼跟人家競爭。

當時我問HTC與聯發科的朋友，兩家公司為何不設法合作？有人猜測是高層有心結，有人說HTC怕得罪Qualcomm，而聯發科的朋友光是做山寨機就忙得不亦樂乎，兩邊都沒有合作的意願。我想，如果當時有合作，現在HTC可能會多一條活路。

「成也是open source，敗也是open source」。如果沒辦法在open source的基礎上加料，端出好菜，那麼其他公司趕上來，尤其是紅色供應鏈挾其廣大資本和市場，自然搞不過人家。所以如何善用open source，是一門大學問。

我們現在談open source，主要看的已經不是手機和傳統雲端服務，而是務聯網（IoT）和Big Data產業所用的系統。為了IoT的市場，許多單位開發開源的軟體，包括ARM公司的Mbed (註10)，不是沒有原因的。簡單來說，IoT談的是利用資訊科技去提升各項既有產業的效率與服務品質，主導權在既有產業，而這些公司當然會希望有可以公開受檢驗其安全性，可以自行根據應用做客製化，容易找到開發人員的開放式平台。Big Data所使用的系統，如同上述Oracle Big Data Appliance的例子，早已大量使用open source。

封閉的系統，除非能做到像Apple那樣，才有辦法存活。但世界上有幾個Apple? 幾乎所有的大公司，連Microsoft和Apple在內，也都積極使用和貢獻open source，但台灣有些公司還在想要如何保護。現在連硬體都得要開源，像是Arduino和Raspberry Pi這類產品，已經招來大量應用開發者成為社群，逐步侵占工業電腦的市場。甚至像UC Berkeley的RISC-V這樣的開源CPU越來越進步，效能接近ARM，可以讓開發者自行客製化指令集，社群積極開發工具組，越來越有吸引力﹑。

可惜台灣大多數既有的產業並不見得重視這塊，部刀ˋ到開放的好處。我們邀請業界來贊助學校的課程，有些人一劈頭就問，你們培育出來的人才，有多少人會來我公司嗎? 我們做產學合作，政府和業界劈頭就問，要產出什麼專利，產出的結果要歸誰？業界不願積極贊助開源的教育研究，那教授和學生自然就做他們自己喜歡做的研究了，所以產學落差日益加大這件事並不意外，政府也管不了，業界再大聲疾呼也無用，要就自己多來跟學校合作。

台灣業界最大的一個迷思，就是誤以為開源的東西沒有價值。這點我前幾天已經論過，有興趣者請參考 (註11)。我們看到很多機會，只要夠厲害，就能夠找到商機，而且know-how可以搞到博大精深，加大技術門檻。如果發展出門檻高的技術，不只是技術有價值，人才也是國家重要的資源，技術和人才都是世界一流的大公司都在積極爭取的。

這是一條可長可久的路，等待更多有眼光的企業家和有智慧勇氣的年輕人來探索。有興趣的話，我這個看過風景的人，可以找嚮導來帶領大家入門尋寶。

(註1)http://www-03.ibm.com/linux/redhat.html

(註2)http://www.forbes.com/sites/janakirammsv/2015/11/11/a-closer-look-at-microsoft-and-red-hat-partnership/

(註3)https://www.oracle.com/engineered-systems/big-data-appliance/index.html

(註4) http://technews.tw/2015/11/13/nokia-7/

(註5)http://buzzorange.com/techorange/2015/11/12/coding-2/

(註6)http://vmfive.com/

(註7)https://www.facebook.com/notes/洪士灝/本立而道生-不要低估技術門檻/1058810250816783

(註8)https://www.facebook.com/weifenl/posts/871591229603778?fref=nf&pnref=story

(註9)https://zh.wikipedia.org/wiki/Android

(註10)https://www.mbed.com/en/

(註11)http://buzzorange.com/techorange/2015/11/18/open-sources/

新世代的FPGA

剛剛看到一篇關於IBM剛剛發表在SC15的論文，使用FPGA來加速big data storage和middleware的報導（註），剛好佐證了我們正在做的研究的意義性。

傳統的FPGA的用法，有很多限制，真的要用FPGA加速應用，必須有突破傳統的程式發展典範與框架（programming paradigm and framework）、編譯器技術與runtime support、計算機系統架構、設計與除錯工具等等。

我們也和IBM有些淵源。故事要回到四年前，IBM Austin Research Lab在2011~2013年間與我們合作FPGA加速的技術，那時IBM合作的夥伴是Altera，IBM把FPGA放在Power CPU的旁邊，讓FPGA可以直接存取主記憶體，在當時是很威的設計。全世界沒有幾台原型機，特別運一台到南港給我們做研究。

後來，IBM一連串改組，FPGA加速計畫不知何去何從，南港的伺服器部門大部分轉給聯想。但我們仍舊繼續這方面的研究，沒有金援，就自己湊錢買有點貴而且代理廠商不大懂得支援的FPGA加速卡。

我們在去年發表一篇關於程式發展典範與框架的論文，有興趣者可參考：
MobileFBP: Designing portable reconfigurable applications
for heterogeneous systems, Journal of Systems Architecture (2014).

前幾天才獲得通知，說我們投稿到FPGA 2016 Conference的最新研究成果被接受了，所以明年二月底有機會去北加州（Monterey），現在開始也可以多談談新的研究內容。

論文題目是： A Platform-Oblivious Approach for Heterogeneous　Computing: a Case Study with Monte Carlo-based Radiation Simulation, to appear in FPGA 2016.

我們正在做的研究目標類似文中這段所描述的：IBM Systems Group developers will create solution stacks for POWER-based servers, storage and middleware systems with Xilinx FPGA accelerators for data center architectures such as OpenStack, Docker, and Spark.

期許我們的研究能與世界同步，徵求人才中。

 （註）http://www.anandtech.com/show/9790/ibm-xilinx-sc15-collaborating-for-better-powerfpga-system-integration

本立而道生 - 不要低估技術門檻

奇群公司的募集群眾資金研發的「貓臉辨識餵食器」，說是低估硬體開發的難度而難產， 向群眾道歉（註）。在此我不想就細節評論這件個案，但我想藉此提醒想創業的人，不要低估系統開發的難度。

現在有太多創業競賽過度強調包裝，甚至主辦單位還特別找人來教參賽隊伍如何把作品「投售」（pitch）給評審。當一天評審下來，忙著拆包裝找技術涵量，發現許多團隊根本不考慮系統面的問題，包括硬體成本、效能、耗電量、網路費用、即時性、例外處理等等實務面上的問題，而且問題不小。

某次擔任某個競賽評審時，我問主辦單位能不能讓大獎從缺，因為作品內涵不夠，但主辦者面有難色。後來知道，不只獎金一定要發出去，而且還要輔導和推銷得獎團隊去創業，這是上級長官交付的任務。有趣的是，媒體人士擔任的評審比學界多，主導了得獎作品的評分，而從結果中發現，他們大多無視於技術面上的問題和難度。

想起一句老話：「君子務本，本立而道生」。本是什麼？想要得什麼道？可能在創業時要思考清楚，業也是有分善業與惡業的。

（註） http://www.bnext.com.tw/article/view/id/37988

複雜系統的自造者

剛剛，我用一分鐘之內瀏覽完一篇Yahoo!機器學習研究團隊的貼文（註）後，嘆了一口氣，也鬆了一口氣。

能一分鐘看完，是因為這篇所講的，剛好就是我上週雇到一位研究助理所要做的事：請他去整合和研發出一套能用GPU加速Hadoop/Spark的系統。因為我們已經做過一些研究（例如Hadoop接上GPU，也裝過Caffe/OpenCL），所以我想這套系統應該可以在幾個月內建置出來，主要還是因為人員的訓練需要花時間。（想來工作嗎？）

嘆一口氣，是因為「想做的東西已經被做出來了，而且幾乎和我想得一模一樣」，所以感嘆我們的進度緩慢：一年前就想做的事，因為資源、人力不足，到現在才有比較足夠的能量來用力動手做。

鬆一口氣，也是因為「想做的東西已經被做出來了，而且幾乎和我想得一模一樣」，那證明我們沒想錯方向，所謂「英雄所見略同」。往好處想，我們就可以省點事，只要搞懂人家的東西，有辦法在人家做好的東西上面堆東西就好。

例如，在上面加上Google最新的開源碼機器學習軟體TensorFlow，或是用FPGA來加速如何？

坦白說，我在國內演講、談論這類想法時，最後不少聽眾總是以「你講得很對，但我們還是等等好了」的態度結束對話。我可以體諒這些聽眾們肩上的包袱，所以當面也沒想對他們個人說什麼，但很不客氣地在此說一聲，就是因為這樣不思進取的文化，把產業給拖垮了。

幾個月前，某家大公司的老闆與我談完後，說他很少遇到有這樣想法的學界人士，很欣賞我們的做法，交代手下要找我合作，但之後與他派來的手下談沒兩下，我就傻眼了。跟我說他們公司在雲端產業上做了很多研發工作，但每當我要切入技術面做深入討論時，他就顧左右而言他。

已經有多次了，我發現有不少大公司的中階主管，只會從國外廠商那邊道聽塗說，知道很多專有名詞，知道供給與需求的現況，但根本不懂系統軟體的技術面，也不懂如何創新研發。之後那家公司沒再連絡，我相信老闆的企圖心，但不知中階主管是如何對老闆回報？

我猜，草草了結的可能原因有三。第一，他不在狀況內，似乎有聽，但我不知他是否有懂；第二，他自己本身應該已經有一大堆工作和責任，大概會選擇跳過這種短期無法收割的研發，老闆如果問起，可能就隨便打發掉，反正我跟他又不熟；第三，老闆日理萬機，極有可能想不起來這檔事，我這個人又不喜歡勉強別人，不會主動去提醒他。

但是沒關係，反正國內還是有識貨的公司，資源雖然不多，還好這裡面用到的全都是開源碼軟體，不需要花大筆錢買，我們可以靠自己來努力，讓自己跟上時代，這也就是目前我所謂推動「開源系統軟體」的想法。我們靠自己來做點東西，就像自造者一樣（maker），有機會做出令人刮目相看的東西。

不過，要學這類效能導向的系統技術，不像學純軟體，必須要有個像樣的系統，光是在建置實驗環境上就很傷腦筋。我們最近好不容易拼湊出一個麻雀雖小、五臟俱全的運算叢集，花了很大力氣去湊錢，還得幫設備找空間，很麻煩的。

我們自己建一個以100Gbps Ethernet為骨幹網路的叢集，接上儲存、計算兩用的端點，有大磁碟空間、大記憶體、GPU，上面用KVM和Docker Container跑Hadoop、Spark、Caffe，還特別找廠商來教學生使用高速網卡做RDMA。

雖然人家Yahoo!和Google用上萬台伺服器做的事，我們沒有資源做，但我們可以思考如何善用幾十台伺服器來做研發。一個全高的機櫃可以放進16台3U的機器，最多可以放入總量2PB的硬碟、32TB的記憶體、128TFLOP的GPU。

知道嗎？十年前最快的超級電腦，也不沒有這麼強，現在世界排名第500名的高速電腦，也不見得比較好用。如果能好好發揮這樣的機能，就有很多機會做出很不錯的事，機器學習只是其中之一。

不過，要發揮機能，說的比做的簡單，有多少人做得到呢？就是一般人做不到，才有趣，才要學！我們以自造者的思維來研發創新，自己建系統、瞭解系統、提早把未來的應用發展出來，這是我目前想做的前瞻研發計畫以及想推廣的活動。

人才和教育訓練是最重要的，有意者參加我們的團隊和活動，無論是有心自我學習、有志於前瞻研發、想接觸最新科技，或是關懷學術產業發展單位，我們都熱忱歡迎。

（註）網址：http://yahoohadoop.tumblr.com/post/129872361846/large-scale-distributed-deep-learning-on-hadoop

程式語言

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

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

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

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

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

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

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

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

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

開源系統軟體的教學與研究計畫

這是我接下來幾年在技術和學術上想努力推動的目標，希望有共同興趣的學界、業界朋友有機會能一起來打拼。目前，我已與台大徐慰中教授、成大黃敬群教授有了一些初步的討論和共識，我也很歡迎對上述構想有興趣的教授、長官、朋友們提出建議和參與行動。我正在徵求對於開源系統軟體有興趣的（全職或兼職）研究助理和行政助理，有意者請與我聯絡。

注意到，這裡談的是「系統軟體」，而不是一般的開源碼計畫，目標不是創造新的開源碼計畫，而是探究如何善用、改造、特殊化既有的開源系統軟體去創造高品質的系統和應用。

【開源系統軟體的教學與研究計畫】

開源軟體(open-source software)，對於資訊科技的發展扮演非常重要的角色。尤其在系統軟體的領域，開源碼計畫更是遍地開花。90年代以Linux作業系統為核心開始集結各種開源碼軟體，顛覆商用軟體壟斷的世界，乃至於有00年代的雲端運算的普及 -- Android手機作業環境和OpenStack伺服器作業環境均採用了大量的開源碼。

近年，更有許多專為物聯網和大數據應用設計的開源系統軟體計畫，例如ARM推出給物聯網使用的mbed平台(註一)，用於大數據儲存與分析的Hadoop(註二)。作為使用這些系統與中介軟體的一般應用開發人員，或許只需要略為了解其原理，搞清楚程式設計介面(API)，應該不會太難上手。但是要如何針對應用的需求和系統的特性進行效能調校(performance tuning)、客製化(customization)、特殊化(specialization)，則必須深入理解系統的工作原理和實地耕耘相關的系統軟體。

放眼國內業界，很多的高階、前瞻的資訊科技研發項目，都需要上述具備足夠能力來發揮與開拓開源系統軟體的潛力和價值。能夠好好調校Hadoop，善用新的系統架構，產生十倍以上的效能，或是解決十倍大的問題，以千萬等級的設備達成他人億元設備所不能達成的功能，這樣的機會隨處可見，如果國內有更多兼通理論與實務的系統人才，那麼台灣會有更多的機會將長年投注於硬體產業所產生的優勢轉型提升至系統層次，例如專為某類型大數據應用特殊化的大數據專用系統(big data appliance)。

但問題是，我們該如何訓練這類兼通理論與實務的系統人才呢? 在資工系的「作業系統」「計算機結構」這兩門課程中教授了不少系統的工作原理，但大多數的學生不容易將原理加以運用；到了業界後，也不大容易透過零碎的訓練課程和單一的工作經驗來整合出完整的系統理論與實務能力。

因此，我想利用「開源系統軟體」作為主題和媒介，展開一系列的教學和研究活動。我希望能邀集到國內通曉開源系統軟體的專家學者，到我下學期開設的【開源系統軟體概論與實務】課程中教授重要領域中具代表性的開源系統軟體，一方面探討這些軟體幕後的原理和設計的方法，一方面要求修課學生瞭解與實地接觸這些開源碼計畫，帶領學生們探討這些計畫的未來發展方向，並且鼓勵學生在期末專題中提出可行的研究計畫。

同時，我想這也是很多學校和業界所注重的領域，因此我希望盡量將課程和研究的資源與學界和業界分享，並且也希望業界來幫忙推展開源系統軟體的教學與研究。我希望利用這幾年的時間與大家一起來深耕開源系統軟體的領域，厚植技術開發與學術研究的基礎，基於開源碼的精神，打造出一個以貢獻和互助為宗旨的技術交流和分享平台，再以此平台培育優秀系統人才以及幫助業界開拓未來。

目前構想中的一學期(18周)的課程概要如下，課程內容可能需要進一步做取捨或修改，如果內容太多，無法割捨，只好考慮開成上下學期兩門課。我們的下一步則是規劃一個【為期兩到三周的暑期密集訓練課程】，如果進度順利的話，將在明年暑假提供給學界和業界參與。講課的部分，錄下來上網應該沒問題，但課程的重點是實做的部分，這也是系統人才不易培養的原因，我希望有辦法設計出容易上手又有深度的實作課程，加上開源硬體，看看能否解決這個問題。

【課程概述】

開源系統軟體的重要性，如上述，不再贅述。

由於重要的開源系統軟體很多，我們將選擇IoT與Big Data領域為當前的重點，挑選具代表性的軟體，製作教學模組。每一模組針對特定領域，教導學生學會使用該領域的代表性軟體，同時鼓勵學生深入探索該領域其他的開源系統軟體，訓練學生舉一反三，進而引導學生思考如何研究改進開源系統軟體。學習使用、多方探索、研究改進，是成為高手的三部曲。我們希望以這門課程帶領學生入門，也希望藉此建構強而有力的開源系統軟體社群，吸引更多高手來教與學，共同來提升臺灣的開源系統軟體的水準。

【課程目標】

在於讓研究所與大學部高年級修課同學：(1) 瞭解開源系統軟體的背景技術知識 (2)  學習使用開源系統軟體開發應用 (3)探索相關的開源系統軟體 (4) 探討如何改進開源系統軟體

【課程大綱】

1.  Introduction to Open-Source Software
1.1 History and concept of open-source software
1.2 Use of open-source software
1.3 Value of open-source software

2. Open-source development tools
2.1 Project and version control system (github)
2.2 Compiler tools (gcc, LLVM)
2.3 Performance analysis tools (perf, Oprofile, valgrind)

3. Open Source Hardware
3.1 Arduino
3.2 Raspberry Pi/Banana Pi
3.3 RISC-V

4.  Open-source Operating Systems
4.1 Linux kernel
4.2 Linux application development
4.3 Android
4.4 Real-time OS
4.5 ARM mbed
5. Open-Source Virtualization Software
5.1 KVM
5.2 QEMU
5.3 Docker

6.  Network Services and Security
6.1 HTTP servers
6.2 WebKit
6.3 OpenSSL
6.4 OpenStack

7. Software Defined Network
7.1 OpenFlow
7.2 Network Function Virtualization
7.3 Software Defined Storage

8. Distributed Systems
8.1 Apache Hadoop and MapReduce
8.2 Apache Spark
8.3  Apache Kafka

9. Machine Learning
9.1 Support Vector Machine
9.2 Caffe Deep Neural Network
9.3 Apache Mahout

10. Project Presentation and Demo
成果發表會

(註一) ARM mbed OS, https://www.mbed.com/en/development/software/mbed-os/
(註二) Apache Hadoop Homepage, https://hadoop.apache.org/

只有高中畢業，竟在聯發科、工研院當顧問、成大教書？

【只有高中畢業，竟在聯發科、工研院當顧問，還讓成大破格錄取當老師？】（註）

文中的這位台灣土生土長的宅色夫教授，是我的好朋友，我在臉書提過多次了，也請他來台大講過課，他的實務能力以及教學熱忱時常令我讚嘆。

如果有一位專家，在實作上有超人的技藝，不斷研究最新的東西，一直推陳出新的創意，同時又樂於把所學所知以簡明扼要的方式分享和教導他人，即使沒有大學的學位和教授的頭銜，我也會非常尊重。

但不要故事只看一半就以此貶低學術的價值，產業界與學術界是可以互補的，前提是要夠努力，而且不要自我設限。但世人多半容易自滿、礙於框架，在學校時只在乎拿學位，到業界只在乎工作相關的事，到學界只在乎升等需要的學術貢獻，時常落入框架而不自知。

有些學界的新進教授問我要如何在當前的大環境下經營產學？我不好意思當面直接說得太直白，但基本上，如果沒有花比別人更多的時間務實去做研究，努力去了解產業界的實際情境和技術需求的話，難道要業界主動來配合你，來讀你的論文？固然獨尊學術論文的大環境相當不利於經營產學，但關鍵還是在於自己有沒有膽識和企圖心。如果只懂得唯唯諾諾的盲從於主流價值和追求小確幸，那麼還是不要強迫自己來做產學比較好。

也有部分的業界朋友太過自以為是，覺得自己有一技之長，就掉入本位主義的框架，大唱學術無用論；或是爬升到某個位階之後就喜歡被人捧，覺得自己的成功之路才是王道，學校教授懂什麼。我也不好意思當面說太多，因為他們大多已經聽不進去。我認識國內外一些厲害、很有成就的工程師，像宅色夫一樣，是樂於在專業上精進，樂於與人交流，樂於為社會貢獻，樂於到學校分享和提攜後進。

話說，台灣的學界和業界的確有不少的人才，但是否能有多一些貢獻者，少一些掠奪者？我想這是產學繁榮發展的關鍵。如果大多數掌握資源和利用資源的人才都是貢獻者，那就會共榮；如果大多數的人才都是掠奪者，那麼最後大家都是輸家。

（註）http://www.businessweekly.com.tw/KBlogArticle.aspx?ID=14184&path=c

大數據與社會人文

學電腦的人大概都聽過一句話：「垃圾進、垃圾出」（garbage in, garbage out）。如果輸入亂七八糟的資料，那麼根據這些資料所產出的結果，很可能也是亂七八糟的。所以一旦發現資料有異常，我們往往儘快停止電腦的運作，免得新產出的垃圾資料覆蓋了正確的資料。

威權時代中教化人心的資訊，有多少是真的呢？只要十句話中夾雜一句謊話，就可以顛倒黑白（參考：金庸的鹿鼎記）。所以我對於從小學校所教的歷史，只當成是欽定的小說。我對考古沒興趣，所以也沒想去找資料去驗證這些故事的真實性。

這不是說歷史不重要，而是說我在很不幸地沒有辦法和時間去確認歷史教材的前提下，不大想用歷史典故去論證些什麼。對我來說，短短數十年所目睹的環境變遷，乃至於金庸小說中的人物故事，可能都比歷史課本的意義豐富。這聽起來很奇怪，竟是一種無奈。

所謂「往事已矣，來者可追」，以前的歷史的真實性有待商榷的原因，一則是上述人為選材、加料所造成的偏頗、扭曲，一則是閱讀、分析歷史者無法蒐集完整資料，以及缺乏時間分析大量資料。

大數據時代的來臨，大幅改變了歷史的記錄和分析機制。現在，具備上網能力的每個人，都可以在互連網上公開記錄與分享他/她所認知的歷史，這些記錄有可能被永久記錄下來，隨時被有興趣的人或電腦所閱讀與分析。而閱讀和分析的結果可能再被公開分享在互連網上，不斷再造微細的歷史事件。

為了設計飛彈、原子彈、先進武器而精益求精的電腦科技，此時可用於整理與分析眾多微細的歷史事件，或許能夠較為客觀地提供我們歷史的全貌，單一事件不會被埋沒，統計可以更精確，事件與事件之間的關係可以被發掘出來。

當然，這樣的歷史，或許不容易被現在的史學家所接受。但誰知道未來會如何呢？或許再過個三五十年，互連網上所累積的大數據，將使得「近代史研究」的面貌大為改觀。而千年之後，或許將以大數據出現為分野，之前的歷史，被稱為古典歷史和黑暗歷史。

以上是我心血來潮所推測的，但我想這並非空穴來風，所以我停筆上網搜尋，發現有學術社群在這兩年開始研究計算歷史（computational history），還發明了一個新字Histoinformatics，有些社群所見跟我自己所想的類似。

除了歷史之外，不少學者也開始利用大數據研究各種社會人文現象。然而，由於目前尚在起步階段，大數據和分析大數據所需的運算資源並非容易取得，而且此類研究需要兼具社會人文的專業和運用電腦的能力，這樣的人才很少。

所以，或許要再過幾年，大家才會看到大數據對於人類文化深層的影響。現在對於社會人文感興趣的年輕人，或許可以及早思索一下如何開創出新道路、為學術研究和實用價值注入新氣象。

深耕自由系統軟體

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

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

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

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

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

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

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

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