Servo parallelism

2,241 views
2,205 views

Published on

ブラウザエンジン先端観測会#1での発表資料

0 Comments
5 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
2,241
On SlideShare
0
From Embeds
0
Number of Embeds
11
Actions
Shares
0
Downloads
8
Comments
0
Likes
5
Embeds 0
No embeds

No notes for slide

Servo parallelism

  1. 1. Servo Parallelism ! Tetsuharu OHZEKI
  2. 2. ABOUT ME • Tetsuharu OHZEKI! • @saneyuki_s! • Mozilla Committer! • Servo contributor (e.g. DOM binding)
  3. 3. モダンブラウザの
 アーキテクチャと抱える課題
  4. 4. 現代的なエンジンの処理フロー http://dbaron.org/talks/2014-06-04-cssday/master.xhtml
  5. 5. 現代のエンジンの基本 •DOMの構築∼レイアウト結果の描画(paint)
 ほぼシングルスレッド動作 •ネットワークは10年以上昔から非同期に
 動作している
  6. 6. 現行エンジンの速度向上指針 •とりあえず頑張って最適化をする •非同期に出来そうなところを頑張って非同期にする •HTML5 parser •描画のcomposition •エンジン側で効率的に制御できるAPIを準備する •Web Animations, CSS Transform
  7. 7. 現行エンジンの抱える課題 •レイアウトフローがシングルスレッド動作なので
 速度向上に限界がある •ハードウェアはマルチコア志向なので
 アーキテクチャ的に使い切れない •安易に破壊的な変更ができない •コードベースも巨大 •依存しているエコシステムも巨大 •Break the Webは何よりも忌避される
  8. 8. Servo
  9. 9. http://en.wikipedia.org/wiki/Tom_Servo
  10. 10. Servo • Mozillaによる、並列性にフォーカスしたブラウザエンジンの
 試験実装 • Rustによって記述されている • 標準化されたspec通りに実装 • tableのlayout方法など、存在しないspecの再検証 • 並列化に必要な機能の調査 • 並列化に限らず、既存エンジンに投入しにくい(大きな変更を 伴うがやっておきたい)アーキテクチャの変更も含む
  11. 11. Rust Language •Mozilla製の新言語 •システムプログラミング •並列性・安全性 •C++生まれHaskell育ち
 アクターモデルはだいたい友達
  12. 12. Servoのアーキテクチャ
  13. 13. Servoのアーキテクチャ •可能な限り非同期動作にする •役割に応じてタスクを分割 •スレッドではない(Rustのタスクモデル準拠) •マルチコアの使用を狙う •並列化・並行化をねらう
  14. 14. 全体の関係図(→の方向にメッセージ送信可)
  15. 15. iframe (cross origin) •Servoではクロスオリジンなiframeの中は
 非同期実行する •タスクの分割によるセキュリティモデル •根本的な影響の分離
  16. 16. iframe (cross origin)
  17. 17. Servoの並列化戦略
  18. 18. Copy-on-Write DOM
  19. 19. Copy-on-Write DOM •DOMの変更点を接ぎ木し、
 スナップショットを構築する •スクリプトの実行を妨げずに レイアウトを可能にする •ただし、やるかは未定 • 実装の複雑さに反して、メリット薄いのでは?と いう話が出ている
  20. 20. セレクタマッチングの並列化
  21. 21. セレクタマッチングの並列化 • CSSセレクタのマッチング処理は非常にコストが高い • 全てのノードに対する総当たり • レンダリング時間の約20%がこれに費やされているという
 調査報告も存在 • これの高速化は確実に高速化が見込める • Other approach: CSS JIT • Servoは、各ノード単位で並列してセレクタマッチングを行う
  22. 22. レイアウト処理の並列化
  23. 23. レイアウト処理の並列化 •何よりもこいつが遅い •シーケンシャルに処理している •既存実装では、並列化が困難 •そもそも並列化できるか不明?(e.g. float) •設計的に困難なケースもある
  24. 24. レイアウト計算: 3-PASS •bubble-width (bottom up) • 好ましい幅の割当 •assign-width (top down) • 実際の幅を割当 •assign-height (bottom up) • 幅を元に高さを割当 • それぞれを混ぜる事はできないが、
 それぞれの中を並列化は可能
  25. 25. •Bottom up • 子の結果に親が依存する •Top Down • 親の結果に子が依存する 依存先の計算が完了していれば並列化できる 並列化アプローチ
  26. 26. floatの計算をどうするか? •floatの場合、回り込みが発生する •floatの後続要素は、先行するfloatの結果を考慮する 必要が有る • 先行するfloatの高さ次第で回り込みの有無が決まる
  27. 27. •floatの影響を受ける要素に
 「影響を受ける」とフラグを立てる •影響を受けた要素(後続の要素)は, 
 floatの計算終了後に計算する •=assign height phaseまで実際の
 計算タイミングを先延ばしする
  28. 28. block format context •block format contextの場合,
 floatの幅計算の影響が減る(回り込む必要が無い) • 具体的にはoverflow:hiddenを用いてサイドバー的に使う
 レイアウトの場合 •その場合、assign-width時に、
 「親の幅」-「隣接するfloatの幅」により幅を
 仮定して処理を進行できる • ただし、今のコードはバグッてるぽい……
  29. 29. その他
  30. 30. その他試したこと •DOMのライフサイクル管理の一本化 •SpiderMonkey GCでRustオブジェクトの生存管理 •GPU上でのセレクタマッチ •実験のみ。masterへのマージはしていない
  31. 31. TBD •インクリメンタルレイアウト •CSS JIT •実用的なエンジンへの一歩 • 各プラットフォーム向けコードの開発 • 未実装機能の実装 •現実的なベンチマークでの比較 • ファンタジーかどうかが未確認
  32. 32. 現状 •全体のアーキテクチャは完成 •Acid 2は通った •エッジケースの実装がまだまだ •Web platform testを少しずつ走らせてる •Samsungチーム最近見かけない…… •たまーにpull request出す人がいるけど???
  33. 33. Servoの将来
  34. 34. No Plan…?
  35. 35. 将来 •繰り返しますが No Planな様子 • より正確には「メインラインへの統合・Geckoの置き換えな どは、まだ考えていない」が正しい •bleeding edgeのためにembedding頑張ってる • ChromiumのUI使うかも
 (Cで接合できるUIが欲しいので, Firefoxは不適) •実用化にはやることがたくさん

×