Posts

2026 New Year

沒想到前一篇文章已經隔了一年多了。 2025 年對我來說，是充滿變化和挑戰的一年；除了 AI 所帶來的轉變之外，自己也嘗試不同的職涯發展。在 2025 年之前，基本上我還是著重於 individual contributor 角色，但是在 2025 年中，有蠻大的比例轉換成 team leader，因此除了技術精進之外，也努力觀察並學習如何帶領團隊。我覺得我是屬於很動態學習的類型，就是當下可能我因為能力或經驗關係沒辦法一次到位，但是我會快速地調整自己的步調和方式，讓自己下一次可以做得更好。另外，團隊中有些資深的管理職前輩，他們也給了我很多建議和指導，使得我可以在這個過程中更有脈絡地去增進管理技能，對我有蠻大幫助。

從行銷職位轉職成工程師，不知不覺也過了九年之久，當初有立下轉職後的職涯目標是要挑戰管理職位，因為除了技術實力之外，待人處事溝通的軟實力也是我很有興趣培養的方向。很高興在 2026 年有機會挑戰成為管理職，同時也在 AI 浪潮之中持續地觀察並調整身為工程師的定位，不可免俗地還是會有點工作危機感，不過既然都撐過了金融危機的領底薪時期、從頭打掉重練的轉職期，再來一個也是沒問題的！ 😂

最後，來談一下目前對於 AI 寫 code 的看法好了，個人還是很正向看待未來 AI 能夠全面協助編寫程式，不過正如同各位大佬提及的，AI 不會幫你負責，因此人為的 review 相信還是不可避免，一次產生上千行 code 並且只看 test report 結果就能快速上線的流程，這點我還是抱持保留態度。另外，產品最終還是回歸到是否能真正滿足用戶需求，現在產生程式碼的成本大幅降低，造成可能把各方需求或是想法都實作出來，進而增加無用程式碼的機率，同時對於後續上線維護也造成壓力。這部分還在嘗試如何調整需求規劃和 AI 協作的流程，期待未來能找到更合適的平衡點。

就這樣啦～祝大家新年快樂！

Golang Performance Optimization Report

Overview

This report summarizes three notable performance optimization pull requests merged in the past two weeks across popular open-source Golang projects. Each PR targets a specific bottleneck — ranging from algorithmic complexity reduction to in-memory caching — and delivers measurable, significant speedups.

從 Golang 1.22 routing enhancement 看專案開發

這次 Golang 1.22 版本針對內建的 http.ServeMux (HTTP request multiplexer) 進行改善，原本 http.ServeMux 的設計力求直覺單純，適用在架設簡單 HTTP server 的應用場景；但隨著 RESTful API 成為目前 HTTP-based interface 設計主流，而既有的 http.ServeMux 並沒有辦法實作 RESTful API，導致內建的 http.ServeMux 使用時機愈來愈少，Gopher 必須仰賴第三方套件才能實現 RESTful API。為了改善此問題，Golang 1.22 加強了 http.ServeMux 的 routing 設計，除了能夠辨別 HTTP method 之外，也增加了動態路徑 wildcard 的功能，使 http.ServeMux 能夠滿足實務上基本 HTTP server 的需求。

The issue of uploading a large-size file using HTTP formdata

接續前面文章提及到，在上傳檔案的使用情境之下，因為 user request 數量增多，造成 service lead time 大幅提升的問題；而導致 lead time 增加的因素，根據實驗數據，主要是因為：

• The different implementation methods of receiving the file
• The concurrency model of language runtime

若要從根本來改善此問題，需要從兩個層面來著手：

• Client side: user 如何傳送夾帶檔案內容的 request 到 server
• Server side: server 如何依據 client 發送 request 的流程來處理此檔案

透過使用者訪談後，我們預期的使用情境，包含：

Python FastAPI FormData 效能議題

在實作檔案上傳並加解密的服務時，遇到了 user request 數量增多，造成 lead time 大幅提升的問題。服務本身是使用 Python + FastAPI framework 實作，在排除了網路頻寬問題和 server 效能問題後，懷疑是 Python 或 framework 導致延遲時間拉長，所以就決定從此地方著手進行 benchmark 實驗，來觀察瓶頸是發生在何處。

由於最終目的還是希望能找出改善的方式，而既然認為問題是出在 Python 和 framework 上，這次實驗就會先使用 FastAPI 與 aiohttp 寫的 HTTP API service 進行效能比較；此外也使用 Golang 實作的版本來測量不同語言之間的效能落差會到多少。

While implementing a file upload service with encryption and decryption, we encountered an issue where an increase in user requests significantly increased the lead time. The service is built using Python and the FastAPI framework. After ruling out network bandwidth and server performance issues, we suspect that the delay may be due to Python or the framework. Therefore, we decided to start with a benchmarking experiment in this area to identify where the bottleneck occurs.

近況更新

自從 2022 年換了新工作，花了蠻多心力在適應工作環境和內容，就先停止更新了 blog。而新工作除了技術之外，我認為自我成長最多的部分應該是跨部門合作溝通、專案時程安排，以及簡報和語言能力等軟實力。其實當時在換工作的時候，就有預期在新的工作崗位上能夠獲得什麼，我想身為資深工程師，技術的持續精進已經是要能自我安排的日常任務，新職位的技術學習已經不是首要考量，反之希望自己能更加強於與人溝通和表達能力這部分。此外，技術學習也從不斷的跟進新技術，轉由能夠判斷當前的情境和預算資源應該要使用怎樣的架構，如何能在滿足使用者需求和時程的安排下將功能完成，並且考慮到不同錯誤和意外處理的情況。

老實說，新工作帶來蠻大的工作壓力，可能也是自我期許比較高，因此這一年花費了非常多的時間在了解公司內部狀況，和如何能將自己的能力正確地發揮在工作崗位。最終在績效表現上， 2022 和 2023 年有蠻不錯的正向回饋，希望新的一年 2024 年也可以繼續朝目標邁進。

2023 年回顧

語文能力

1. 講了一場全英文 tech sharing
2. 2 小時的全英文面試主考官
3. 每週持續唸英文和上英文課

技術精進

1. Python 從 0 經驗到 master (?)
2. 除了 performance，更加留意在意外處理和錯誤判斷
3. 不再只是專注開發，而是會考慮到後續的維運流程和 monitoring

其他

1. 矯正牙齒
2. 拿到汽車駕照
3. 學習投資和買房

2024 年展望

1. 希望能把握更多全英文的面談機會和場合
2. 更多架構設計和 operation 的實務經驗
3. 深入研究 K8s 底層原理和開發 k8s-native 的 application
4. 買特斯拉 🚗

Gem5 Simulator - Simulation Mechanism

Gem5 是針對電腦系統架構所設計的模擬器，目前主要用於系統層面相關的研究，可以模擬出執行所需的 cycle 數、記憶體 access 數、cache miss 等。其中 Gem5 將各組件模擬模組化，並透過 C++ 後端和 python 前端設置的方式來實作，除了可以快速地置換和配置想要的組件之外，也方便研究人員自行新增想要的新設計。這篇文章主要介紹 Gem5 模擬系統運行的機制和相關 configuration 初始化原理。

The gem5 simulator is a modular platform for computer-system architecture research, encompassing system-level architecture as well as processor microarchitecture.

Simulate Mechanism

Gem5 是一個 event-driven 模擬器，所以最主要是透過一個全域 (global) 的 mainEventQueue 和 main loop 來實現系統模擬，這也意味著所有的行為 (callback function) 都必須依照正確的順序加入到 event queue 中，最後的模擬結果才會如預期。

C volatile Keyword

我們在開發 device driver 或是 embedded system applications 時很常用到 volatile 來宣告定義變數，藉此提示 compiler 此變數可能會被硬體或是 interrupt function 修改，因此當 compiler 進行 code optimization 時，要確保涉及到 volatile 變數的操作不會被更動到。（舉例來說，當 compiler 在進行分析時，發現此變數涉及的操作只有讀取但沒有寫入時，就有可能調整執行順序，以改善程式效能）。雖然這對開發者來說可能是很基本的知識，但我們最近還是踩到了小坑，因此這篇再一次的透過 C11 標準來複習 volatile 定義，並且說明可能會有的疑問。

C11 標準下的 volatile

首先，先從 C11 標準來了解 volatile 修飾字 (Linux Kernel Moving Ahead With Going From C89 To C11 Code)。

Crypto Subsystem of Linux Kernel - Asynchronous Request Handling Mechanism

由於在 crypto subsystem 中預期多個 crypto request 可以同時向同一個 crypto engine 發出請求 ，因此 crypto engine driver 必須實作對應機制，使其有能力能應付此情況。此外，結合在前一節有提到 crypto subsystem 的 asynchronous crypto API 流程，較常見的實作方式就是 crypto queue 搭配 worker，額外開一個 kernel thread 來與 crypto engine 進行溝通，並讓 crypto request 按照 FIFO 順序處理，而本文主要針對此設計方式，說明整個運作流程和細節。

Overview

條件

1. 假設 hardware crypto engine 一次只能處理一個 request，將 request 根據需求設置好 register 之後，啟動 crypto engine 進行運算，運算完結果後才能換下一個 request。
2. 當運算出結果後，crypto engine 會舉起 status interrupt，通知外部已運算完成。
3. 多個 Request 有可能同時對 hardware crypto engine 發出請求。
4. 一個完整的 crypto request 流程包含三個 API call: Init → Update → Final， Final 結果回傳後，則此 crypto request 將會被釋放，不再使用。

想法

1. 建立一個全域的 crypto request list，將進來的 request 依序排到 list 當中。
2. 建立一個 worker (kernel thread) 和對應的 work queue 來與 hardware crypto engine 進行溝通。worker 的任務除了從 crypto request list 中取出 request 來處理之外，也可能會包含 crypto engine 的初始化和資源釋放等工作。
3. 註冊 interrupt handler，當 status interrupt 舉起時，呼叫 user 自定義的 completion callback function 來完成最後的流程。如果當前是執行最後的 final API call 且 request 有自定義的 resource 需要被釋放，則會在呼叫完 callback function 後執行。

實作

Linux kernel version: v5.17.3

GCC malloc + memset Optimization

最近踩到 compiler optimization 的一個小坑，gcc5 版本以上，開啟 optimization level 2 時，會將 malloc + memeset 轉換成 calloc。看起來似乎蠻有道理的改善，卻因為我在進行客製化 malloc 時，沒有這注意到這點，導致最後程式執行的是 libc 的 calloc 而不是我的 wrap_malloc。

起因

使用 void *__wrap_malloc(size_t size) 將 malloc function 進行額外的處理 (How to wrap a system call (libc function) in Linux)，其中一段 code 為: