概要
Layered Machine Abstraction 是一種開發模式。它並不強調全端開發，而是透過 managed code + C ABI + kernel code 的分層結構來管理整個 codebase。
目的
雖然技術棧確實會影響效能，但效能的關鍵往往取決於以下因素：
- 正確的資料結構與演算法 — 選擇合適的算法能大幅提升效率。
- 合理安排記憶體階層 — 善用快取與不同層級的記憶體。
- 適當使用平行演算法 — 在需要時透過並行計算加速處理。
當這些努力都已經做到，卻仍然遇到效能瓶頸時，才值得考慮將 codebase 移植到另一個技術棧。
開發模式
1970 年代的軟體開發模式主要是 shell 腳本 + C 語言。除了用 shell 腳本串接既有指令外，新的指令通常以 C 撰寫。
然而，C 的抽象層次相對有限：記憶體管理、字串處理、檔案 I/O、模擬高階語法等情境，都需要大量樣板程式碼。能寫出這些樣板程式碼是一種知識，但每次都必須重複撰寫，則是一種勞動。
如今已有許多高階語言，不應再在 C 中重複這些操作。此外，理解記憶體階層後便會發現，效能瓶頸往往來自環境，而非程式本身。既然瓶頸不在程式本身，就更不需要堅持用 C 手刻。
若某段演算法確實成為效能瓶頸，仍可透過高階語言的 FFI，將該段操作移至 kernel code。Kernel code 不一定要用 C 撰寫，也可能使用 Fortran、C++、Rust，最後再包裝成 C ABI。
效能差異
在適當控制演算法、記憶體階層與平行運算的前提下，效能差距通常相當有限。然而，開發過程卻能大幅簡化。這樣的 trade-off 是值得的：以少量效能差異換取更高的開發效率與可維護性。
二進位大小
由於 managed code 需要 runtime，編譯後的二進位大小通常會比純 C / C++ codebase 大。這是合理的，因為等於把記憶體管理、字串處理、物件系統等高階抽象一併打包進去，二進位自然就膨脹了。
例如，一個空的 OCaml 程式：
let _ = ()
編譯後的二進位約為 1.1 MB，這基本上就是 runtime 的大小。
如果只看 runtime 的體積，可能會覺得不值得。但使用 managed code 的好處在於能撰寫更安全的程式碼，開發效率也更高。隨著專案規模擴大，這一點點額外的大小就變得微不足道了。
使用 OCaml
多數高階語言在搭配 Layered Machine Abstraction 時，通常透過動態函式庫來橋接 kernel code。然而，OCaml 具備更直接的能力：它可以直接引入目的檔（object file）。若再結合 Alpine Linux 編譯環境，甚至能做到全靜態編譯，使用上相當便利。
限制
Layered Machine Abstraction 並不適用於所有情境。像是系統程式、即時程式、嵌入式程式等應用，仍需以完整的 C / C++ codebase 來開發，才能確保效能與即時性需求。
結論
Layered Machine Abstraction 提供了一種兼顧效能與效率的開發模式。透過分層設計，開發者能在高階語言中專注於邏輯與抽象，同時保留以 C ABI 為橋接的低階最佳化空間。
雖然它並不適用於所有情境，但在大多數應用中，這種模式能有效降低開發成本，提升可維護性，並在必要時仍保有追求極致效能的彈性。
另見
- ocaml-ffi-demo：在 OCaml 中寫 stub 橋接 kernel code。