2025q1 Homework5 (assessment)

contributed by < weiso131 >

作業書寫規範:

• 無論標題和內文中，中文和英文字元之間要有空白字元 (對排版和文字搜尋有利)
• 文字訊息 (尤其是程式執行結果) 請避免用圖片來表示，否則不好搜尋和分類
• 共筆書寫請考慮到日後協作，避免過多的個人色彩，用詞儘量中性
• 不要在筆記內加入 [TOC] : 筆記左上方已有 Table of Contents (TOC) 功能，不需要畫蛇添足
• 不要變更預設的 CSS 也不要加入任何佈景主題: 這是「開發紀錄」，用於評分和接受同儕的檢閱
• 當在筆記中貼入程式碼時，避免非必要的行號，也就是該手動將 c= 或 cpp= 變更為 c 或 cpp。行號只在後續討論明確需要行號時，才要出現，否則維持精簡的展現。可留意「你所不知道的 C 語言: linked list 和非連續記憶體」裡頭程式碼展現的方式
• HackMD 不是讓你張貼完整程式碼的地方，GitHub 才是！因此你在開發紀錄只該列出關鍵程式碼 (善用 diff 標示)，可附上對應 GitHub commit 的超連結，列出程式碼是為了「檢討」和「便於他人參與討論」
• 留意科技詞彙的使用，請參見「資訊科技詞彙翻譯」及「詞彙對照表」
• 不要濫用 :::info, :::success, :::warning 等標示，儘量用清晰的文字書寫。:::danger 則僅限授課教師作為批注使用
• 避免過多的中英文混用，已有明確翻譯詞彙者，例如「鏈結串列」(linked list) 和「佇列」(queue)，就使用該中文詞彙，英文則留給變數名稱、人名，或者缺乏通用翻譯詞彙的場景
• 在中文敘述中，使用全形標點符號，例如該用「，」，而非 ","。注意書名號的使用，即 〈 和 〉，非「小於」和「大於」符號
• 避免使用不必要的 emoji 字元

因為自動飲料機而延畢的那一年

閱讀這篇文章時，讓我更加慶幸自己當初選擇了資訊工程系。撰寫程式最大的優勢之一，就是可以迅速獲得回饋，立刻發現錯誤並加以修正。相比之下，處理硬體問題往往需要漫長的等待才能看到結果，調整流程也更加費時。

然而，現實世界中的應用往往不僅限於純軟體開發，而是與各種領域密切結合。有些領域本身就具有長回饋週期，這是無法避免的。因此，除了持續鞏固自己的專業能力，更要培養與其他領域專家有效溝通與合作的能力，這對於實際解決跨領域問題至關重要。

大一的時候，我曾嘗試探索當時十分熱門的機器學習領域，學習各種套件的使用，也了解了深度學習的基本原理。然而，這些知識並未讓我成功訓練出實用的模型。網路上的教學多半強調：若要對模型做出有效的改進，必須深入理解資料本身。然而不同的資料往往涉及不同的領域知識，除了統計學，幾乎每一種資料都需要跨領域的背景才能真正掌握。

這讓我意識到，單純投入模型訓練本身並不會帶來知識的有效累積，因為每換一個資料集，就得從頭學起一個新領域。這樣的過程讓我感到挫折，也逐漸看清了一件事：也許「訓練模型」本身，並不是適合我長期投入的方向。

相較之下，修習「Linux 核心設計」這門課程，讓我第一次感受到資訊領域專業知識的厚實與連貫。這門課探討的雖然是資訊系必修課涵蓋的內容，卻更加強調對細節的掌握與整體系統的理解，並聚焦於解決真實世界的問題。從浮點數運算中 mantissa 溢出導致的精度損失、如何透過位元運算實現常數時間的操作，到深入理解 Linux 排程器的實作方式、處理亂序執行所帶來的挑戰，乃至於異質多核架構與 KVM 虛擬化技術的延伸……
我總算找到了一條能夠通往專業的道路。

前六週學習回顧

課堂討論

• 5/1 線上討論作業三

學習紀錄與提問

• Demystifying the Linux CPU Scheduler 閱讀筆記

程式碼貢獻

• 提交修改到 ksort 1153ae7

作業回顧

lab-0

完成事項

• 完成 queue.c 的函式功能實現
• 在 qtest 提供新的命令 shuffle
• 追蹤並修改 dudect 的程式，解決 make test 錯誤的將 insert_head/tail 認為是非常數時間的問題
• 追蹤 list_sort 的程式並與自己的實作比較效能，並且嘗試理解它更有效率的原因

遇到的問題

• 我的 remove head 與 remove tail 有相同的實作方法 queue.c，然而在 github 的 make test 中， remove tail 總是能通過測試， remove head 幾乎總是無法通過測試，然而，在本地端的測試中，它們兩個總能通過測試。
  這有可能是受到甚麼影響才會有這種結果?
• linux 的 merge (list_sort.c) 的合併效率會比起使用間接指標儲存比較結果的實作有更高的效率，使用 perf 觀察各個組合語言指令占用的 cycle ，可以看到 linux 的 merge 在將兩個字串指標傳入 strcmp 時花費較少時間( 相較另外一種方法 )，但我無法理解為甚麼相同的指令花費的時間不同，是因為間接指標的取值會有額外的開銷? 還是 perf 的觀測不夠準? (perf 實驗)

hw2

完成事項

• 完成自定義的 memory allocator ，並測試其效能
• 修正 random_shuffle_array 機率不公平的問題
• 解釋 sqrti 的運作原理

覺得很奇怪的部份

• memory-allocators 的 Free list allocator ，在實驗中宣稱使用鍊結串列實作，效能比 malloc 效能好了 3 倍，但稍微去追蹤它所測試的 Free list allocator ，每次都是直接選取第一個可用的記憶體空間，不管之後是否有更適合的空間，這可能會導致在多次分配之後更容易受到 memory fragmentation 影響。

kxo

完成事項

• 實現 ctrl+Q 停止並顯示對亦紀錄的功能
• 解決 使用者/核心 read_attr 不同步的問題
• 利用 bit 儲存棋盤資料
• 將 draw_board 移至 user space
• 實作快速判斷勝負的功能

問題

• 關於作業說明， fast_buf_get 的部份需要使用 smp_rmb() ，是因為要避免指令重排嗎？ (ring->buf 與 tail 沒有直接的相依性) ，這邊跟 rota1001 討論時得出不一樣的結論，想確認一下

想投入的專案

• 因為作業三修改過 kxo 程式碼，讓對投入與驅動程式裝置、核心模組有關的專案產生一些興趣。
• 跟 3D 遊戲效能提升有關的專案可能會有興趣
• 跟嵌入式裝置有關的專案可能會有興趣

藉由 WiFi 訊號達成動作追蹤

在看過 Through-Wall Human Pose Estimation Using Radio Signals 的 demo 影片後，讓我覺得這個專案成果會十分的有趣，而且執行人的主要工作會是 修改現有的Wi-Fi 裝置驅動程式，以達成動作追蹤的基礎建設 ，似乎符合其中一個我想投入的專案類型。