7 ms·

Servo Layout Engine: Parallelizing the Browser [video]

206 points by paulrouget 13y ago

deleted 13y ago
[deleted]
jbrooksuk 13y ago
If this is ever implemented into Firefox properly, will see the difference in speed or is this mainly focused on security?
- paraboul 13y ago
  It's a rewrite of the engine from scratch, focused on parallel computing. So yes, it's going to be a massive improvement of speed, security and overall revamping.
- jgraham 13y ago
  So, talking about Servo being "implemented into Firefox" might set the wrong expectations. At the moment it is very unclear if or how it will be turned into a consumer-facing product. That said, the goal of Servo is to improve both speed and safety. In terms of speed, part of the project is research into parallel algorithms for various parts of the web stack. For example Servo today has parallel implementations of various parts of CSS. The goal here is to make the sequential performance on par with the best implementations today and then get a further speedup by using multiple cores efficiently. In terms of safety, the choice of Rust over C++ provides substantially stronger compiler-enforced guarantees of memory safety that should help eliminate a large class of bugs that have caused numerous security issues in current browsers. If this sounds interesting there are plenty of ways to get involved; come chat on #servo on Mozilla IRC.
- beagle3 13y ago
  Responsiveness (commonly defined as time from start of operation to completion) might improve from parallelization. As for "speed" (commonly defined as operations/sec on a given hardware), it will likely be the same or a little lower (parallelism creates overheard). But it's responsiveness that most people measure, and they measure it on machines with CPU utilization in the single digits - in which case, it is likely to improve considerably.
tikhonj 13y ago
Mozilla is one of my favorite tech companies. Servo is a great example: Mozilla is willing to engage in fundamental CS research. Not only are they trying to put together a parallel, secure browser engine from the ground up, but they even created Rust to do so. This is truly long-term work, which seems rare in an increasingly short-term world. And Rust isn't just another C clone with OOP or CSP bolted on: it's principled, relatively elegant and takes full advantage of the last few decades of PL research. All while being practical—it has to be, since it's evolved with a Servo as a concomitant project. A non-trivial companion project like that seems great for naturally guiding a language! Not many other languages can say any of this, much less ones actually poised to replace C++ or at least do actual systems programming. And Mozilla is doing all this in a completely open and transparent way. I think this is incredibly important: anybody can get a glimpse into active development or even contribute. Just go to the relevant GitHub repo[1][2] and you're set. This is the way open source is supposed to work, rather than having companies develop behind close doors and dump source code occasionally (although that's also better than nothing). I really wish more companies would take this sort of approach with their open source or basic research work. This gives me more confidence in Servo, Rust and Mozilla as a whole, especially compared to many of Mozilla's competitors (both in the browser space and in programming languages). [1]: https://github.com/mozilla/servo/ https://github.com/mozilla/servo/ [2]: https://github.com/mozilla/rust https://github.com/mozilla/rust
- twic 13y ago
  > A non-trivial companion project like that seems great for naturally guiding a language! It's definitely an interesting aspect. For most languages, the only substantial project during their early life is their own compiler. There is an intriguing theory (posted on HN a few weeks back?) that this results in languages that are optimised for writing compilers, at the expense of writing other things. Are there other examples of languages that had this kind of companion project in their early life? Did UNIX do this for C? To what extent did Rails do it for Ruby? Is there something inside JetBrains that does it for Kotlin, or inside JBoss that does it for Ceylon?
  - ahuth 13y ago
userbinator 13y ago
4 years ago: http://www.eecs.berkeley.edu/~lmeyerov/projects/pbrowser/pubfiles/playout.pdf http://www.eecs.berkeley.edu/~lmeyerov/projects/pbrowser/pub... http://www.usenix.org/event/hotpar10/tech/full_papers/Badea.pdf http://www.usenix.org/event/hotpar10/tech/full_papers/Badea....
- larsberg 13y ago
  Yes, we've been both following and collaborating with the rest of the people who do research in this space. In particular, Ras Bodik's group (first link) has been partially sponsored by Mozilla Research for several years. We've also leaned heavily on members of these groups as interns in the past, and they've written large portions of our parallelism-friendly layout code, etc. Some additional interesting links to both publications and talks are available on our wiki below (though it's not comprehensive): https://github.com/mozilla/servo/wiki/General-implementation-and-design-notes https://github.com/mozilla/servo/wiki/General-implementation...
TacticalCoder 13y ago
What's the relation between Servo and the Quark browser kernel mentioned on the Servo page? Quark is a formally verified kernel made of a few hundreds of lines of (C ? C++ ?) code. It's been verified using Coq and hence I take it it's guaranteed from a whole class of bugs typically leading to security exploits (buffer overrun/overflow/underrun, dangling pointer, null pointer, ...). Is Servo using Quark? If not, is Servo formally verified using Coq? To me formally verified software are one of the most interesting development we're seeing (that and deterministic builds seems to be huge steps forward towards more security), so I'd like to know more... (gone building Servo on my Debian box)
- mccr8 13y ago
  Servo is not using Quark, and is not formally verified. I assume the link on the Servo page is along the lines of pointing out another cool project in a similar space of writing safer browsers. Formal verification is cool, but speaking as somebody who worked out it for about 7 years, it is not really ready to be used in large software. Most people care much more about performance and features for their browser. Hopefully by writing a browser in Rust instead of C++, the result will be much more secure, but not have to make many compromises.
  - pcwalton 13y ago
    That said, we would like to at least formally verify that the core subset of Rust's type system is sound. That has important practical implications for Servo: it means that any (potentially exploitable) memory safety problems in the safe part of Servo will be of the "straightforward compiler bug" variety and not the "oh no, now we have to redesign the type system and break everyone's code" variety.
    - lmkg 13y ago
      What is the current state of formal verification in Rust (of the language, of compilers, of other programs)? I would assume that since parts of the language are still undergoing change there isn't much work towards super-rigorous proofs until that gets nailed down. Has there been any provisional work in this direction, and is there any work towards making formal methods practical for Rust? I like the idea of formal methods, but my familiarity with the subject is entry-level at best, so I don't even know what sort of details I should be asking about here =P.
sandGorgon 13y ago
Since Rust was born out of a vision to build the next-gen browser engine, does anyone know why Rust does not have bindings to GTK ? The only two projects (on github) are 1-2 years old. I was hoping Rust could overtake Vala as the goto language for desktop software in the GTK world.
- bjz_ 13y ago
  Servo is focusing on the layout engine. Think of it as an alternative to Gecko or Webkit, not Firefox or Chrome
- wting 13y ago
  It's highly likely that will happen anytime soon. Jürg Billeter created Vala for the sole purpose of building GTK / GNOME applications and the two projects are tightly coupled. It's not to say that Rust won't have GTK bindings in the future, but it's not a high priority for either Mozilla or GNOME devs and unlikely to displace Vala.
  - sandGorgon 13y ago
    is that so ? I would have thought that considering they are building a browser that was originally written in C-GTK, the first order of business would be to build GTK bindings. I would say Vala and Rust do have fairly similar goals in general. P.S. I know right now Servo != Firefox, but I suppose it will get there eventually.
    - pohl 13y ago
      Servo isn't even a project to build a browser. It's just a project to build the rendering engine. I'd guess that none of the interesting work they're focusing on overlaps with any of the user-interface chrome where GTK would become relevant.
  - stefantalpalaru 13y ago
    >the two projects are tightly coupled Vala is only coupled with GLib for the object system and even that can be replaced by using another profile: https://wiki.gnome.org/Projects/Vala/Tutorial#Profiles https://wiki.gnome.org/Projects/Vala/Tutorial#Profiles
higherpurpose 13y ago
Why doesn't that video expand to full screen? So annoying. I can't see what's on the slides.
- paulrouget 13y ago
  Works with Firefox. Not sure why Chrome doesn't resize the video.
  - basugasubaku 13y ago
    It's because it sets max-width: 600px on the <video>. Blink currently doesn't force fullscreen elements to width/height 100%/100%.
- ZeroGravitas 13y ago
  Works for me, both via right-click menu and expand icon in bottom right corner. (Firefox on Ubuntu).
higherpurpose 13y ago
Will Servo take advantage of GPU compute, too?
- kibwen 13y ago
  I believe that Samsung added some preliminary SIMD support to Rust in order to explore this possibility.
- metajack 13y ago
  We currently have GPU compositing and rendering[1]. Other browsers will get this eventually and some have it already. We plan to explore this space quite a bit. The other thing we're starting to think about is using SIMD ops for layout, which isn't a GPU but falls into a similar "taking advantage of modern hardware" bucket. [1] Note that 2D rendering on the GPU is not currently a clear win. In theory you save a texture upload and get massively parallel drawing operations, but in practice there's a lot of overhead to deal with.
- larsberg 13y ago
  We're certainly planning to investigate it, particularly with the advent of vector units that reduce the latency of data transfers, such as AMD's new Opterons and Intel's Knight's Landing. The challenge here is that while several of the stages (e.g. CSS selector matching) can be trivially sped up on a GPU, the CPU/GPU latency cost is going to be close to the original CPU evaluation time. There are some very sequential and unfortunately common "corner cases" in layout (e.g., uncleared floats) that have lead us to currently prefer the higher clock-speed CPU for parallelizing phases. Even if we find a great way to work around floats, it's likely there will still be a lot of CPU/GPU chatter, which makes it difficult to use today's GPU cards when you're trying to keep total page load well under 200ms and incremental reflows < 15ms.
  - metrix 13y ago
    "the CPU/GPU latency cost is going to be close to the original CPU evaluation time." Have you looked into HSA architecture that helps to remove this latency? I think this is the direction Intel will move to in a few years.
kibwen 13y ago
For those having trouble seeing the slides in the video, you can find them here: http://www.joshmatthews.net/fosdemservo/ http://www.joshmatthews.net/fosdemservo/
al2o3cr 13y ago
Am I the only one that hopes this has a companion technology called "Crooooow!" ;)
- larsberg 13y ago
  If you visit #servo on irc.mozilla.org, there is a "crowbot" that will dig up the github link if you reference a pr/issue number and will correct you if you link to an outdated web platform spec :-)
- kibwen 13y ago
  This doesn't deserve the downvotes, because "Crow" is in fact the name of Servo's proof-of-concept UI layer :P Not everyone spots the MST3K reference! https://github.com/mozilla/servo/issues/111 https://github.com/mozilla/servo/issues/111
metajack 13y ago
This is an amazing and challenging project to work on. If you'd like to join us, we hang out in #servo on irc.mozilla.org or just dive right into the code[1]. You don't need previous browser hacking experience, and we're happy to mentor you through a bug. We're opening three full-time positions on the Servo team at Mozilla Research within the next couple of days; they should be up on the careers[2] page soon. Also, if you're a graduate student, Mozilla Research is still looking for summer interns for Servo, Daala, Shumway, and other projects. Those positions are also on the careers page. [1]: https://github.com/mozilla/servo/ https://github.com/mozilla/servo/ [2]: https://careers.mozilla.org/en-US/ https://careers.mozilla.org/en-US/
- girvo 13y ago
  Mozilla is a place I would love to work at, beyond any other tech company. A shame I live in Australia :(
  - gkanai 13y ago
    Living in Australia shouldn't stop you from applying. I think Mozilla has people working remotely in Australia.
    - larsberg 13y ago
      True. There are a few each in Australia and New Zealand, including some very senior contributors working in core engineering roles (i.e., it's not just "marketing for SE Asia").
  - larsberg 13y ago
    Mozilla is _incredibly_ remote-friendly. I believe that less than 40% of our paid staff is in the traditional "US West Coast" timezone. For example, on Servo we have about a third of the team in the SF area, but then I'm in Chicago and we have other staff in New Mexico, Toronto, and London. Our largest group of partners is in Korea, and we have several other regular contributors scattered across pretty much every timezone. The big engineering projects, such as FFOS and Gecko are even more distributed.

206 points by paulrouget 13y ago

deleted 13y ago

[deleted]

If this is ever implemented into Firefox properly, will see the difference in speed or is this mainly focused on security?

paraboul 13y ago
It's a rewrite of the engine from scratch, focused on parallel computing. So yes, it's going to be a massive improvement of speed, security and overall revamping.
jgraham 13y ago
So, talking about Servo being "implemented into Firefox" might set the wrong expectations. At the moment it is very unclear if or how it will be turned into a consumer-facing product. That said, the goal of Servo is to improve both speed and safety. In terms of speed, part of the project is research into parallel algorithms for various parts of the web stack. For example Servo today has parallel implementations of various parts of CSS. The goal here is to make the sequential performance on par with the best implementations today and then get a further speedup by using multiple cores efficiently. In terms of safety, the choice of Rust over C++ provides substantially stronger compiler-enforced guarantees of memory safety that should help eliminate a large class of bugs that have caused numerous security issues in current browsers. If this sounds interesting there are plenty of ways to get involved; come chat on #servo on Mozilla IRC.
beagle3 13y ago
Responsiveness (commonly defined as time from start of operation to completion) might improve from parallelization. As for "speed" (commonly defined as operations/sec on a given hardware), it will likely be the same or a little lower (parallelism creates overheard). But it's responsiveness that most people measure, and they measure it on machines with CPU utilization in the single digits - in which case, it is likely to improve considerably.

tikhonj 13y ago

Mozilla is one of my favorite tech companies. Servo is a great example: Mozilla is willing to engage in fundamental CS research. Not only are they trying to put together a parallel, secure browser engine from the ground up, but they even created Rust to do so. This is truly long-term work, which seems rare in an increasingly short-term world. And Rust isn't just another C clone with OOP or CSP bolted on: it's principled, relatively elegant and takes full advantage of the last few decades of PL research. All while being practical—it has to be, since it's evolved with a Servo as a concomitant project. A non-trivial companion project like that seems great for naturally guiding a language! Not many other languages can say any of this, much less ones actually poised to replace C++ or at least do actual systems programming. And Mozilla is doing all this in a completely open and transparent way. I think this is incredibly important: anybody can get a glimpse into active development or even contribute. Just go to the relevant GitHub repo[1][2] and you're set. This is the way open source is supposed to work, rather than having companies develop behind close doors and dump source code occasionally (although that's also better than nothing). I really wish more companies would take this sort of approach with their open source or basic research work. This gives me more confidence in Servo, Rust and Mozilla as a whole, especially compared to many of Mozilla's competitors (both in the browser space and in programming languages). [1]: https://github.com/mozilla/servo/ https://github.com/mozilla/servo/ [2]: https://github.com/mozilla/rust https://github.com/mozilla/rust

twic 13y ago
> A non-trivial companion project like that seems great for naturally guiding a language! It's definitely an interesting aspect. For most languages, the only substantial project during their early life is their own compiler. There is an intriguing theory (posted on HN a few weeks back?) that this results in languages that are optimised for writing compilers, at the expense of writing other things. Are there other examples of languages that had this kind of companion project in their early life? Did UNIX do this for C? To what extent did Rails do it for Ruby? Is there something inside JetBrains that does it for Kotlin, or inside JBoss that does it for Ceylon?
- ahuth 13y ago

userbinator 13y ago

4 years ago: http://www.eecs.berkeley.edu/~lmeyerov/projects/pbrowser/pubfiles/playout.pdf http://www.eecs.berkeley.edu/~lmeyerov/projects/pbrowser/pub... http://www.usenix.org/event/hotpar10/tech/full_papers/Badea.pdf http://www.usenix.org/event/hotpar10/tech/full_papers/Badea....

larsberg 13y ago
Yes, we've been both following and collaborating with the rest of the people who do research in this space. In particular, Ras Bodik's group (first link) has been partially sponsored by Mozilla Research for several years. We've also leaned heavily on members of these groups as interns in the past, and they've written large portions of our parallelism-friendly layout code, etc. Some additional interesting links to both publications and talks are available on our wiki below (though it's not comprehensive): https://github.com/mozilla/servo/wiki/General-implementation-and-design-notes https://github.com/mozilla/servo/wiki/General-implementation...

TacticalCoder 13y ago

What's the relation between Servo and the Quark browser kernel mentioned on the Servo page? Quark is a formally verified kernel made of a few hundreds of lines of (C ? C++ ?) code. It's been verified using Coq and hence I take it it's guaranteed from a whole class of bugs typically leading to security exploits (buffer overrun/overflow/underrun, dangling pointer, null pointer, ...). Is Servo using Quark? If not, is Servo formally verified using Coq? To me formally verified software are one of the most interesting development we're seeing (that and deterministic builds seems to be huge steps forward towards more security), so I'd like to know more... (gone building Servo on my Debian box)

mccr8 13y ago
Servo is not using Quark, and is not formally verified. I assume the link on the Servo page is along the lines of pointing out another cool project in a similar space of writing safer browsers. Formal verification is cool, but speaking as somebody who worked out it for about 7 years, it is not really ready to be used in large software. Most people care much more about performance and features for their browser. Hopefully by writing a browser in Rust instead of C++, the result will be much more secure, but not have to make many compromises.
- pcwalton 13y ago
  That said, we would like to at least formally verify that the core subset of Rust's type system is sound. That has important practical implications for Servo: it means that any (potentially exploitable) memory safety problems in the safe part of Servo will be of the "straightforward compiler bug" variety and not the "oh no, now we have to redesign the type system and break everyone's code" variety.
  - lmkg 13y ago
    What is the current state of formal verification in Rust (of the language, of compilers, of other programs)? I would assume that since parts of the language are still undergoing change there isn't much work towards super-rigorous proofs until that gets nailed down. Has there been any provisional work in this direction, and is there any work towards making formal methods practical for Rust? I like the idea of formal methods, but my familiarity with the subject is entry-level at best, so I don't even know what sort of details I should be asking about here =P.

sandGorgon 13y ago

Since Rust was born out of a vision to build the next-gen browser engine, does anyone know why Rust does not have bindings to GTK ? The only two projects (on github) are 1-2 years old. I was hoping Rust could overtake Vala as the goto language for desktop software in the GTK world.

bjz_ 13y ago
Servo is focusing on the layout engine. Think of it as an alternative to Gecko or Webkit, not Firefox or Chrome
wting 13y ago
It's highly likely that will happen anytime soon. Jürg Billeter created Vala for the sole purpose of building GTK / GNOME applications and the two projects are tightly coupled. It's not to say that Rust won't have GTK bindings in the future, but it's not a high priority for either Mozilla or GNOME devs and unlikely to displace Vala.
- sandGorgon 13y ago
  is that so ? I would have thought that considering they are building a browser that was originally written in C-GTK, the first order of business would be to build GTK bindings. I would say Vala and Rust do have fairly similar goals in general. P.S. I know right now Servo != Firefox, but I suppose it will get there eventually.
  - pohl 13y ago
    Servo isn't even a project to build a browser. It's just a project to build the rendering engine. I'd guess that none of the interesting work they're focusing on overlaps with any of the user-interface chrome where GTK would become relevant.
- stefantalpalaru 13y ago
  >the two projects are tightly coupled Vala is only coupled with GLib for the object system and even that can be replaced by using another profile: https://wiki.gnome.org/Projects/Vala/Tutorial#Profiles https://wiki.gnome.org/Projects/Vala/Tutorial#Profiles

higherpurpose 13y ago

Why doesn't that video expand to full screen? So annoying. I can't see what's on the slides.

paulrouget 13y ago
Works with Firefox. Not sure why Chrome doesn't resize the video.
- basugasubaku 13y ago
  It's because it sets max-width: 600px on the <video>. Blink currently doesn't force fullscreen elements to width/height 100%/100%.
ZeroGravitas 13y ago
Works for me, both via right-click menu and expand icon in bottom right corner. (Firefox on Ubuntu).

higherpurpose 13y ago

Will Servo take advantage of GPU compute, too?

kibwen 13y ago
I believe that Samsung added some preliminary SIMD support to Rust in order to explore this possibility.
metajack 13y ago
We currently have GPU compositing and rendering[1]. Other browsers will get this eventually and some have it already. We plan to explore this space quite a bit. The other thing we're starting to think about is using SIMD ops for layout, which isn't a GPU but falls into a similar "taking advantage of modern hardware" bucket. [1] Note that 2D rendering on the GPU is not currently a clear win. In theory you save a texture upload and get massively parallel drawing operations, but in practice there's a lot of overhead to deal with.
larsberg 13y ago
We're certainly planning to investigate it, particularly with the advent of vector units that reduce the latency of data transfers, such as AMD's new Opterons and Intel's Knight's Landing. The challenge here is that while several of the stages (e.g. CSS selector matching) can be trivially sped up on a GPU, the CPU/GPU latency cost is going to be close to the original CPU evaluation time. There are some very sequential and unfortunately common "corner cases" in layout (e.g., uncleared floats) that have lead us to currently prefer the higher clock-speed CPU for parallelizing phases. Even if we find a great way to work around floats, it's likely there will still be a lot of CPU/GPU chatter, which makes it difficult to use today's GPU cards when you're trying to keep total page load well under 200ms and incremental reflows < 15ms.
- metrix 13y ago
  "the CPU/GPU latency cost is going to be close to the original CPU evaluation time." Have you looked into HSA architecture that helps to remove this latency? I think this is the direction Intel will move to in a few years.

kibwen 13y ago

For those having trouble seeing the slides in the video, you can find them here: http://www.joshmatthews.net/fosdemservo/ http://www.joshmatthews.net/fosdemservo/

al2o3cr 13y ago

Am I the only one that hopes this has a companion technology called "Crooooow!" ;)

larsberg 13y ago
If you visit #servo on irc.mozilla.org, there is a "crowbot" that will dig up the github link if you reference a pr/issue number and will correct you if you link to an outdated web platform spec :-)
kibwen 13y ago
This doesn't deserve the downvotes, because "Crow" is in fact the name of Servo's proof-of-concept UI layer :P Not everyone spots the MST3K reference! https://github.com/mozilla/servo/issues/111 https://github.com/mozilla/servo/issues/111

metajack 13y ago

This is an amazing and challenging project to work on. If you'd like to join us, we hang out in #servo on irc.mozilla.org or just dive right into the code[1]. You don't need previous browser hacking experience, and we're happy to mentor you through a bug. We're opening three full-time positions on the Servo team at Mozilla Research within the next couple of days; they should be up on the careers[2] page soon. Also, if you're a graduate student, Mozilla Research is still looking for summer interns for Servo, Daala, Shumway, and other projects. Those positions are also on the careers page. [1]: https://github.com/mozilla/servo/ https://github.com/mozilla/servo/ [2]: https://careers.mozilla.org/en-US/ https://careers.mozilla.org/en-US/

girvo 13y ago
Mozilla is a place I would love to work at, beyond any other tech company. A shame I live in Australia :(
- gkanai 13y ago
  Living in Australia shouldn't stop you from applying. I think Mozilla has people working remotely in Australia.
  - larsberg 13y ago
    True. There are a few each in Australia and New Zealand, including some very senior contributors working in core engineering roles (i.e., it's not just "marketing for SE Asia").
- larsberg 13y ago
  Mozilla is _incredibly_ remote-friendly. I believe that less than 40% of our paid staff is in the traditional "US West Coast" timezone. For example, on Servo we have about a third of the team in the SF area, but then I'm in Chicago and we have other staff in New Mexico, Toronto, and London. Our largest group of partners is in Korea, and we have several other regular contributors scattered across pretty much every timezone. The big engineering projects, such as FFOS and Gecko are even more distributed.