# 21 世紀的系統軟體

主講人: [jserv](http://wiki.csie.ncku.edu.tw/User/jserv) / 課程討論區: [2016 年系統軟體課程](https://www.facebook.com/groups/system.software2016/)

## 有所變，有所不變

* 1980 年代的電腦廣告: [IMSAI 8080](https://en.wikipedia.org/wiki/IMSAI_8080)


* source: [twitter](https://twitter.com/HistoryInPics/status/552536619849613312)

* USD $5995 (而且是 35 年前的物價！) 只能買到 8-bit 微處理器，搭配 64 KB 主記憶體和 10 MB 硬碟。有趣的是，當時軟體開發的模式部分還延續至今
* 硬體突飛猛進，軟體的問題依舊還在

## Maslow’s pyramid of code review


* 21 世紀的軟體開發均已規模化，絕非「有就好」，而是持續演化和重構，code review 是免不了的訓練
* uber 工程師 Charles-Axel Dein 認為好的程式碼應該要:
* [ Correct ] : 做到預期的行為了嗎？能夠處理各式邊際狀況嗎？即便其他人修改程式碼後，主體的行為仍符合預期嗎？
* [ Secure ] : 面對各式輸入條件或攻擊，程式仍可正確運作嗎？
* [ Readable ] : 程式碼易於理解和維護嗎？
* [ Elegant ] : 程式碼夠「美」嗎？可以簡潔又清晰地解決問題嗎？
* [ Altruist ] : 除了滿足現有的狀況，軟體在日後能夠重用嗎？甚至能夠抽離一部分元件，給其他專案使用嗎？
* 「需求」層次: 正確 → 安全 → 可讀 → 優雅 → 利他
* @[Chaoint](https://twitter.com/Chaoint) : 「沒關係」總是講給自己聽的。
* 「人們不敘述自己的過往，而是為自己的過往作證。」—— Frantz Fanon
* 「如果你把游泳池當作浴缸泡著，再泡幾年還是不會游泳」 -- jserv

延伸閱讀: [Code Reading](https://en.wikipedia.org/wiki/Code_Reading)

* 大量篇幅回顧 C 語言概念，以及在真實世界中的程式如何展現，細節！

## 什麼叫做簡潔？


尤拉猜想是 Euler 在 1769 年對費馬定理的延伸： n 個正整數的 k 次方的總和，若是另一個正整數的 k 次方，則 n 不可能小於 k。n = 2 就是費馬最後定理，不過這個猜想在 1966 年被號稱「最短論文」給否定。

延伸閱讀: 

* [美麗的錯誤--猜想的真與假](http://www.mathland.idv.tw/fun/erroneous.htm)
* [邏輯思維：費馬大定理](https://www.youtube.com/watch?v=7nORW4edSaI) (YouTube)

## 「事實」很容易被遮蔽，所以我們要 Benchmark / Profiling


source: [twitter](https://twitter.com/Harvey1966/status/624099087466500096)

## 《[進擊的鼓手](https://en.wikipedia.org/wiki/Whiplash_(2014_film))》之後


"No pain, no gain"

source: [CSAIL at MIT twitter](https://twitter.com/MIT_CSAIL/status/614140774620332032/photo/1)

* 延伸閱讀: [Operational Amplifier](http://memo.cgu.edu.tw/shin-yan/0909_Electronics(I)/2_OP.pdf)

## 運算模式的巨變

[ [source](https://www.facebook.com/shihhaohung/posts/995419510500537) ]

* 早年計算能力相對低的年代，常常有用查表法代替計算，有空間換取時間的做法，來增進效能。... 那個時候 個人電腦的 CPU 可以在一個時脈週期中讀取一筆資料，但是要做乘法計算則需要幾十個時脈週期，所以用查表的比較快。除法和超越函數更是如此，而現在還有一些低階的處理器，還在用這些技巧。
* 後來當 CPU 時脈提高，但記憶體存取相對變慢的時候，我們必須反過來減少記憶體存取的次數，所以高階處理器 cache 越來越大，做 data  prefetch 來提早取得資料、使用 multi-threaded  architecture 來容忍資料遲到的狀況、使用壓縮的方式傳送資料，甚至還會用 speculation 的方式來猜測資料是在哪裡和是什麼。
* 在多處理機和多核心電腦上，存取資料的問題更嚴重，除了時間延遲和頻寬之外，還要考慮到尖峰時刻塞車的問題，所以有時候簡單的工作，就可能就不分工了，要不就由一個 CPU 代表去做，做完把結果給大家，要不就大家都做同樣的事情。前者多半在有共享記憶體的多核心處理器上看到，後者多半在分散式的系統看到。
* 到了異質計算的年代，CPU 和 GPU 的分工，更需要好好地做效能分析。因為傳統 GPU 和 CPU 不共享記憶體，透過較慢的 PCIe  Bus 交換資料，所以有些工作 CPU 自己做比較快。另一方面，當 GPU 有超過 2000 個核心的時候，用重複的計算 (redundant  computation)取代資料交換，也是常見的事。
* [HSA](http://www.hsafoundation.com/)
* 更進一步談巨量資料，為了節省資料的取得時間，我們往往費盡心思。我們花時間將資料和計算擺在同一個地方，做所謂的 data computation  co-location，將重複出現的資料利用 data  deduplication 技術節省儲存空間和取得時間，用一堆目錄 (indexing) 讓資料可以快速被找到。
* 當計算機結構有所不同時，優化的策略可能會隨之而變，不能食古不化。但原理雖然簡單，系統和實作技巧卻越來越複雜，軟硬體優化的機會越來越多，可惜能夠真正連通理論和實務的人則越來越少。
* 以上這些技術，講起來很容易，但在實作上，必須先搞清楚運算和資料的相對位置、距離、時間先後、相依性、數量等等，才知道該如何取捨。但很多人根本不會用效能分析工具，就在那邊瞎子摸象，隨便亂講，這時候要解決問題，就需要瞎貓遇到死耗子的運氣。

* i586 和 i686 看起來指令相似，但本質不同！
* 從 i686 (Pentium Pro) 開始，底層已經是 RISC 架構
* 因為現在計算機結構改變很大，即便把程式用組合語言重寫，效能也不見得比 Compiler 產生的還好
* 效能的問題在存取資料本身
* 組合語言會快，是因為你分析過程式要怎樣寫才可以比較快
* 直接照著程式碼的邏輯改寫組合語言不見得比較好

* [hyperloglog](https://en.wikipedia.org/wiki/HyperLogLog)
* 使用 1.5k 表達 10 億筆資料
* [Python implementation of Hyperloglog, redis, fuzzy hashing for malware detection](https://bigsnarf.wordpress.com/2013/03/16/python-implementation-of-hyperloglog-redis-fuzzy-hashing-for-malware-detection/)

## Deep Learning 背後的資訊建設

* video: [GTC CHINA: AI, Deep Learning with Jen-Hsun Huang & Baidu's Andrew Ng](https://www.youtube.com/watch?v=mJvTAWsYiSI)
* Nvidia 將未來 GPU 的發展聚焦在 AI 上 (更確切地說, 聚焦在 Deep Learning 上), 影片中間也請到 Andrew Ng 介紹百度的 AI 研究
* [做別人不喜歡做的事，為 AI 革命鳴槍的 NVIDIA 創辦人黃仁勳](http://www.bnext.com.tw/article/view/id/41045)
* [Andrew Ng (吳恩達)](http://www.andrewng.org/)
* [Coursera: 機器學習](https://zh-tw.coursera.org/learn/machine-learning)
* [你以為NVIDIA只是畫了個餅，其實他早已布好了整個局](http://mp.weixin.qq.com/s?__biz=MzAwODY4Njg2OA%3D%3D&mid=2652006436&idx=1&sn=24f117b7bf0b0e186f210ffdf4160467)

## 不良的軟體導致家破人亡

* 美國 Carnegie Mellon 大學 Phil Koopman 教授在 2014 年製作一份簡報 「[A Case Study of Toyota Unintended Acceleration and Software Safety](http://users.ece.cmu.edu/~koopman/pubs/koopman14_toyota_ua_slides.pdf)」，探討豐田汽車(Toyota Motor)在美國捲進了一樁官司背後的工程議題，涵蓋 real-time scheduling 和軟體可靠性
* 豐田一款 2005 年份 Camry 車款在 2007 年，於美國奧克拉荷馬高速公路上發生的一場暴衝死亡車禍，肇因於該車款內的電子節流閥控制系統軟體發生錯誤，內部的錯誤碼就是造成車輛無預警暴衝的原因。
* [汽車電子缺陷導致事故？豐田在美惹官非](http://www.eettaiwan.com/ART_8800691341_622964_NT_9cc6a57b.HTM)
* [不良軟體碼可能殺人嗎？答案是肯定的，而且悲劇顯然已經發生](http://www.eettaiwan.com/ART_8800691385_480202_NT_bd47ba6a.HTM)
* 2011 年，包括 Barr Group 四位專家在內的一個七人小組接手先前 NASA 為期 10 個月的調查任務，深入分析了發生事故的豐田汽車，並做成了一份長達 800 頁的調查報告。首先，檢視車用系統的即時作業系統，找出未受保護的 critical variables，且發現了電子節流閥故障安全機制中的漏洞與缺陷。
* 該專家小組採用 Green Hills 模擬器進行了模擬，透過車輛測試，那些我們所發現的缺陷確實與無預警暴衝有關，對照檢視了汽車黑盒子內的軟體碼，發現它會錯誤記錄車輛意外前最後幾秒的駕駛人動作資訊。針對 2005 年份的 Camry L4 車款原始碼以及車內測試，證實其中有部分關鍵變數並未受軟體保護，記憶體崩潰的原始碼也顯現，stack overflow 與軟體錯誤導致記憶體崩潰，而問題的關鍵就在於那些記憶體崩潰，從而擦槍走火。
* 軟體缺失導致重大災難的例子比比皆是，像是：
* 1980 年 (冷戰時期)，北美防空聯合司令部曾告警，美國遭受導彈襲擊，差點釀成第三次世界大戰。後來證實，這是反饋系統的電路故障問題，但反饋系統軟體並未考慮故障問題引發的誤報
* 1996 年 6 月 4 日，Ariane 5 型運載火箭的首航，原計畫將四顆太陽風觀察衛星運送到預定軌道，但因軟體引發的問題，導致火箭在發射 39 秒後偏軌，從而觸發火箭的自我摧毀裝置。此事件肇因於一系列的 Ada 程式碼錯誤，造成高達 3.7 億美元的損失

延伸閱讀: [史上導致數百萬美元損失的10大計算機漏洞](http://www.readhouse.net/articles/183038190/)