本系列目錄 《來做個網路瀏覽器吧！》文章列表

本篇接續之前一篇

研究論文： Fast and Parallel Webpage Layout

論文作者為 Leo A. Meyerovich 和 Rastislav Bodík，於 2010 年發表。
本篇文章圖片來自原始論文

回顧一下核心概念：

好的接著講第二部分，也就是處理 tree 的平行化

這邊提到一個概念，因為 child 繼承的屬性會直接蓋掉 parent，所以在算屬性的時候，因為上下彼此獨立，也就有機會平行化。此外同個 node 的多個屬性同時也可以分開算。上面就是她的概念的虛擬碼，不過這樣看下來其實滿抽象的，平行化實際執行會碰到很多困難，但是論文通常只說他怎做，至於這樣做會發生怎樣的困難不親自試試看也不知道。

總之他有畫出他的結果

看起來可以快 2~4 倍。

再來是處理字型：

這邊論文沒有講很詳細的操作步驟，但概念就是得到 layout tree 的時候，其實我們就知道每個字元的各種特性（大小、顏色、字體等等），在渲染這些字型的時候我們會需要做計算，這時候就把相同種類的字元丟在一起，只要算一遍就好，接下來碰到就拿快取，而不同種類的字元則可以平行化計算。

一樣作者也得到一個結果：

速度上一樣有進步。

雖然這邊研究結果看起來都很厲害，不過令人質疑的是，也許他實驗環境可以達到這樣的優化速度，但 crash 的機會多高？實驗的時候我們可以忽略掉那些崩潰的情況，但如果是一個實際的產品，良率沒有 99.99%我相信就不能用。平行運算很容易碰到錯誤，然而我們並不知道這份研究實際運作的情況。由於網頁容錯能力很高，但相對的在處理上風險也就變高，一般的時候就可能會發生很多預期外的狀況，在平行化的時候更加危險，合格的產品必須要能完全掌握各種突發狀況。

平行化很容易出錯，尤其是在記憶體管理的部分，所以雖然我們很容易可以提出一些讓效能改善的方案，但是如果沒辦法做到絕對的穩定，那麼就無法真正變成一個產品。C++ 沒辦法處理平行化的一些困境，意思是我們沒辦法預期哪邊會出錯，只能碰到錯誤之後寫應對方式，但這樣會耗費大量人力維護、除錯，產品本身依舊具有不確定性（萬一哪個錯誤沒有事先偵測到）。所以後來才有 Rust 語言的誕生，透過語言本身設計的特性，避免平行化的時候出錯。我還不是平行化專家我也不能肯定，但我相信如果把 Rust 應用在這些研究上的點子，應該有機會真的讓這些研究成果變成產品。甚至我們還可以想，這些技術是否能轉移到行動裝置上？

希望有幫到大家，大家明天見！