
Servo Layout Engine: Parallelizing the Browser [video] - paulrouget
http://paulrouget.com/e/servopres/
======
tikhonj
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
> 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?

~~~
_delirium
One that comes to mind is ML, which was originally developed as a domain-
specific language for writing proof tactics in the LCF theorem prover, and was
only later broken out into a standalone programming language.

I can't think of one canonical companion project for them, but early Lisp,
COBOL, and FORTRAN were also pretty driven by external application concerns,
in AI, business logic, and numerical simulation, respectively.

~~~
lmkg
The original McCarthy LISP started even more abstract than ML: it was intended
as a logical thought exercise, and was only accidentally a programming
language at all.

COBOL (and Ada) were standards-first languages. The industry-driven standards
committees designed the languages first, and it was not until afterwards that
there were working implementations, much less working programs. Industry
experience guided them in later releases, but v1.0 (which Rust is still
working towards) were even more ivory-tower than languages whose only program
is their own compiler.

------
metajack
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
Mozilla is a place I would love to work at, beyond any other tech company. A
shame I live in Australia :(

~~~
gkanai
Living in Australia shouldn't stop you from applying. I think Mozilla has
people working remotely in Australia.

~~~
larsberg
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").

------
TacticalCoder
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
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
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
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.

~~~
pavpanchekha
Few languages have any formal verification work at all. There is a verified C
compiler (CompCert; it comes with a guarantee that the compiled assembly is a
correct compilation of the source, and it does some very basic verified
optimizations) and a verified ML compiler (CakeML, see this year's POPL
proceedings).

Few languages have verified anything—verification is still very challenging to
do.

~~~
mccr8
A proof of type safety of a language, which I think is what pcwalton is
talking about, is a different beast than the proof of the correctness of a
compiler, which is what you are talking about.

~~~
pavpanchekha
I actually cannot think of any languages except SML that have complete formal
proofs of type safety. Now, I may simply be forgetting something obvious. But
Haskell's type systems keeps growing by little features here and there, so no
full proof is anywhere; OCaml doesn't have a formal semantics, so it sure as
hell doesn't have a proof of type safety (in the usual "a well-typed program
doesn't go wrong" sense); Java is unsound (in a particular manner of speaking,
of course); C# seems too complicated to have such a proof. The Go authors
don't seem the type. Rust is the language in question. Those seem like the big
players.

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

~~~
larsberg
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...](https://github.com/mozilla/servo/wiki/General-
implementation-and-design-notes)

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

~~~
kibwen
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)

------
kibwen
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/)

------
sandGorgon
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.

~~~
wting
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
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
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.

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

~~~
jgraham
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.

------
higherpurpose
Will Servo take advantage of GPU compute, too?

~~~
larsberg
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
"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.

~~~
pcwalton
> 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.

We are actively looking into this.

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

~~~
paulrouget
Works with Firefox. Not sure why Chrome doesn't resize the video.

~~~
basugasubaku
It's because it sets max-width: 600px on the <video>.

Blink currently doesn't force fullscreen elements to width/height 100%/100%.

