Shell 排序效能實測：組合語言 vs C 語言，執行速度與代碼體積對比

測試背景

教程第一章第一節對 Shell 排序演算法分別用 C 語言與組合語言 (MASM) 實作，並對相同資料集進行效能測試。結果顯示組合語言在大量資料處理上具備壓倒性優勢。

測試結果對照表

深度解讀

1. 執行檔體積差異 (69KB vs 803 Bytes)

• C 編譯器 (早期 DOS 年代編譯器) 連結大量運行庫、啟動代碼、浮點模擬庫、標準 I/O 格式化代碼等。
• 組合語言僅包含演算法核心邏輯與極精簡的 DOS 系統呼叫 (INT 21h)，無運行庫負擔。

2. 執行速度差異 (30s vs 8s @ 8k ; 失敗 vs 70s @ 48k)

• 演算法相同 (Shell Sort)，差異源自指令層級優化：寄存器分配、迴圈展開、避免函式呼叫開銷、就地交換、旗標運算利用。
• 記憶體模型限制：C 程式可能使用 Small Model (單一資料段 64KB)，48,000 筆記錄超出單段容量導致連結/運行失敗。組合語言可靈活使用 Compact/Large Model 或手動管理遠指標/分段，突破 64KB 限制。

3. 開發效率權衡 (20h vs 80h)

• 組合語言開發耗時 4 倍，但換取 3.75 倍速度提升 (8k) 與 可行性突破 (48k)。
• 核心熱點路徑 (排序核心) 用組合語言，其餘 I/O、UI 用 C 語言，是當時最佳混合策略 (現代同理：C/C++ + SIMD 內聯組合語言 / Intrinsics)。

時代背景補充

測試環境約為 1990 年代初 (80386/486, DOS 6.x, 4-8MB RAM)。當時 64KB 段限制是硬性瓶頸，組合語言對分段記憶體的精確控制是關鍵優勢。現代 64-bit 作業系統、平坦記憶體模型、優化編譯器 (GCC/LLVM/MSVC -O2/-O3) 大幅縮小差距，但關鍵路徑手工優化 (SIMD, 緩存友好, 無分支) 仍是高效能計算 (HPC, 遊戲引擎, 視訊編解碼) 的核心競爭力。

結論

組合語言在大量資料處理時，應用靈活，而 C 語言因受到空間限制，以目前之系統空間，無法執行。—— 原文結語

這句話在當時是鐵律，今天則演變為：理解底層硬體特性 (快取行、分支預測、SIMD 寬度、記憶體頻寬) 的工程師，無論用何種語言，都能寫出高效能代碼。