User/Krixi0828
簡介
2026 Linux 核心實作 春季班 自我評量
成果發表與貢獻
並行程式設計: POSIX Thread
並行程式設計: 執行順序
目前還無法對 Linux 核心及其相關專案進行實質的貢獻，但我在閱讀課堂剃到的相關文章和文獻時有發現教材文章中的一些錯字及未更新到的內容。
評分 ： 5
作業與隨堂測驗
在閱讀作業提到的相關文章和問題時，我無法很好的跟上課堂進度，花上更多的時間去完成一篇的問答，並且沒有辦法提出實際的實作，偶爾即使看完文章，在面對問答時還是會因為沒有融會貫通難以回答。
隨堂測驗的部分，雖然可以在教材中找到資料並且填入答案，但是在後續的檢討有許多不足，應該要花上更多時間去搞懂每一週的隨堂測驗才能有所進步。
評分 ： 6
期末專題
本專題以 expm1(x) = e^x - 1
為主題進行相關探討，是因為數學上看似只要計算 \(e^x -
1\)，但因為電腦是離散系統，所以實際寫成程式碼後，會因為精度限制導致錯誤的結果，因此要進行相關的修正和調整。
透過閱讀 expm1
的原始碼，我學到實際數值函式必須依輸入範圍拆分不同 case，避免 rounding
error、overflow 與相近數相減造成的精度損失，而在不使用 FPU
的實作中，我一開始偏好 Q24.8 ，但在實際實作後，我才了解到如果使用 Q8.24
的定點數格式，因為擁有較高的 fractional bits
，因此在接近零更能留有效資訊，實際透過誤差圖與實驗資料進行視覺化比較，我可以清楚觀察到
Q8.24 在 near-zero range 的誤差顯著小於
Q24.8。這讓我理解，選擇定點數格式不能只看可表示範圍，也必須依照輸入資料的特性、所需解析度與可接受誤差做取捨，並以實驗驗證結果。
最後，透過 Btrfs compression.c 的案例探討，了解 Linux
核心一般不直接使用浮點運算，因為核心必須避免額外管理 FPU
狀態與浮點上下文切換成本，也需要維持不同執行環境下的可預測性，因此核心程式常會透過數學轉換、縮放與整數運算，保留原本可能被捨去的資訊，像是Btrfs
將對數值放大後再以整數方式近似處理的做法，和我的定點數實作有相同的思考方向，先分析資訊會在哪一步遺失，再設計適當的表示方式、縮放方法與範圍檢查，而不是只追求程式能夠執行。
目前我已完成 expm1 原始碼分析、不同定點數格式的實作與誤差視覺化，以及 Btrfs compression.c 的對應案例探討，未來要持續在 Linux 核心中尋找更多相關案例並完成分析。
評分：8
與授課教師的互動
一對一討論時間 2026.5.13
這次一對一討論以 expm1 為主軸，並延伸到如何以定點數實作
expm1，透過相關實作去理解為什麼 Linux 核心會避免直接使用
FPU
，讓我思考如何在核心或低階環境處理近似指數函式時，如何以整數、位元操作與縮放方式保留足夠精度。
討論後，我依照老師提出的方向完成相關教材與 expm1
原始碼的閱讀，實作 my_expm1f，比較 Q24.8 與 Q8.24
的定點數格式，並以圖表驗證不同格式在接近零時的誤差差異。我也完成 HackMD
的分析與解釋，整理直接計算 \(e^x - 1\)
為何會遺失低位資訊，以及定點數格式應如何在可表示範圍與小數精度之間取捨。
這次討論讓我理解，遇到看似單純的數學函式時，不能只確認公式是否正確，而要進一步分析實際執行環境、資料表示方式、精度限制與驗證方法。後續我需要補足 CPU book 的閱讀，目前僅完成一章，尚未持續以章節為單位整理問題並通知授課教師。
課堂問答
第一次課堂問答主要圍繞並行和多執行緒程式設計講座中的 condition
variable 與 futex ，讓我了解 condition variable
的目的是讓暫時無法繼續執行的 thread 在條件未成立時睡眠，並且共享
predicate 必須由 mutex 保護，因此 thread 被 signal 或
broadcast 喚醒後，仍必須重新取得 mutex，並以
while 再次確認條件。futex 的設計則是在沒有競爭時以
userspace atomic operation 完成同步，避免每次 lock、unlock 都進入
kernel，只有真的需要等待或喚醒時才進入 kernel，以減少不必要的 system
call、排程與 context-switch 成本。
第二次課堂問答以 SPSC lock-free FIFO 為主。ring buffer 的目的是在
Producer 與 Consumer
速度不同時，提供固定容量的暫存空間，使兩者不必每次交接資料都等待對方，同時避免頻繁
malloc()、free() 與 mutex
contention，讓高頻資料路徑的延遲較可預測。write_count 與
read_count 不只是位置資訊，也是資料所有權的交接點，Producer
完成資料寫入後才發布 write_count，Consumer 讀完後才發布
read_count。這讓我理解並行程式設計的重點不只是使用
atomic，而是先分析哪一方擁有資料、何時完成交接，以及如何避免不必要的等待與同步成本。
評分 ： 7
所見所聞
因為自動飲料機而延畢的那一年
在看文章時，作者本身經歷了非常多了挑戰才完成了最後陽春版的飲料製造機，對於飲料店來說這個陽春版的自動飲料機或許商業價值還沒有那麼高，但是對於看過整篇文章，知道作者為了完成心中所想，經歷了多少挫折和挑戰，他又是怎麼去不斷試錯、實踐不同的想法去跨過阻礙，特別是對於冰塊分配那裡，螺距的不夠、碎冰口感不佳、夥伴出國看來都令人挫敗不已，但作者最後還是找到了適合的機器，並且成功完成了冰塊分配的問題。在整篇文章中，我看到了 Jserv 教授在上課時提到解決問題的能力，雖然我已經在資工系讀了四年，但正如文章中提到「資工系的學生不會寫程式」，我的實作能力依舊匱乏，在嘗試開啟一個新專案時，總是因為過於難以實作而輕易降低難度，沒有跨出自己的舒適圈挑戰自己，而在看到作者文章中經歷了這麼多的挑戰，但是三折肱而成良醫，終於完成自己的目標，因此我也應該學習這樣的精神，在面對挑戰時去試錯、調整直到克服困難，在其中獲得成長。
回顧自身在本課程的投入狀況
回顧自己在這門課程中的投入狀況，我在每週都會花上少則 10 小時，多則 20 個小時來閱讀教材和進行相關的實作，我在理解觀念和完成實作任務的時候，很常都會陷入長時間的思考，或者是花大量的時間找尋相關資料，以讓我讀懂教授提到的觀念，在其中我注意到自己的基礎過於薄弱，因此著重於在看教授講的你所不知道的 C 語言系列講座，再來因為對於修習即時系統導論，因此對於排程器和並行設計較感興趣，但因為難度過大，在閱讀相關講座時遇到了很多問題，並且常常需要花上大量的時間去搞清楚觀念，雖然成效沒有達到預期，但我還是會持續在這方面精進，特別是去閱讀教授撰寫的 cpu book 並且完成相關的實作實驗。
評分 ： 8
自我評量總分
\[ \operatorname{GEOMEAN}=\sqrt[5]{5 \times 6 \times 8 \times 7 \times 8} ＝ \sqrt[5]{13440} \approx 6.69 \]
依方案 B 計算：
\[ 1 + \left\lfloor 6.69 \right\rfloor =1 + 6 = 7 \]
因此，自我評量總分為 7 分。
