iT邦幫忙

2018 iT 邦幫忙鐵人賽
DAY 30
1

本篇接續之前一篇


研究論文: 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 應用在這些研究上的點子,應該有機會真的讓這些研究成果變成產品。甚至我們還可以想,這些技術是否能轉移到行動裝置上?


希望有幫到大家,大家明天見!


關於作者

劉安齊

軟體工程師,熱愛寫程式,更喜歡推廣程式讓更多人學會


上一篇
掩卷沈思瀏覽器
下一篇
手機上網好耗電,不如讓雲端幫手機省電吧!
系列文
來做個網路瀏覽器吧!Let's build a web browser!35

尚未有邦友留言

立即登入留言