
A Quantum Leap for the Web - Manishearth
https://medium.com/mozilla-tech/a-quantum-leap-for-the-web-a3b7174b3c12
======
dherman
[disclaimer: I co-founded Mozilla Research, which sponsors Servo]

It's awesome to see the Gecko team continue to tackle big, ambitious projects
now that electrolysis is rolling out. And I'm so excited that they're betting
big on Servo and Rust. Servo has really been taking advantage of one of Rust's
promises: that you can reach for more aggressive parallelism and actually
maintain it. I believe recent numbers showed that effectively all of Firefox's
users have at least two cores, and about half have at least 4. The more we
fully utilize those cores, the smoother we should be able to make the whole
web.

Over the last year, all three communities have been laying groundwork to be
able to land Rust components in Firefox and share components between Gecko and
Servo, and now it looks like that's teed the Gecko team up to commit to making
use of some big pieces of Servo in the coming year. Some of the initial builds
of Firefox with Stylo that Bobby Holley has showed me look really amazing, and
WebRender could be a game-changer.

And the Servo project is just getting warmed up. ;) If you're interested in
what they're up to next, check out Jack Moffitt's recent presentation from a
browser developer workshop last month:

[https://www.youtube.com/watch?list=PL4sEzdAGvRgCYXot-o5cVKOo...](https://www.youtube.com/watch?list=PL4sEzdAGvRgCYXot-o5cVKOobIXZI5iLF&v=UGl9VVIOo3E)

~~~
the8472
> The more we fully utilize those cores, the smoother we should be able to
> make the whole web.

I wonder why the GC/CC are not multithreaded though. It seems like those are
fairly isolated components, considering the entire application gets suspended
so they can do their job, i.e. prime candidates for parallelism.

When forcing a collection on a large firefox instance it can easily spend 20+
seconds collecting on a single thread while a java VM can munch churn through
something like 1 gigabyte per second per core.

In other words, from the outside it looks like a low-hanging fruit that has
not been plucked.

~~~
mccr8
Writing a parallel GC surely is not "low-hanging fruit" by any reasonable
measure. Java already has to deal with concurrency in their objects, and
throughput is more of a concern for server-like workloads, so they are dealing
with a different situation. In Firefox, most of our effort has focused on
improving responsiveness and eliminating work (through things like
compartmental GC). (Some GC sweeping is already done in parallel in Firefox.)

That said, I believe IE does some concurrent marking, so there is certainly
room for improvement.

~~~
the8472
> and throughput is more of a concern for server-like workloads

Many java applications also have to worry about latency, not just throughput.
Parallel collections cut down on pause times, too. Simply because they can get
about the same work (in terms of CPU cycles) done in less wall time. I.e.
parallelizing non-concurrent GC phases also improves responsiveness.

------
mtgx
> A first version of our new engine will ship on Android, Windows, Mac, and
> Linux. Someday we hope to offer this new engine for iOS, too.

More people need to put pressure on Apple to allow third-party browser engines
on iOS. Fortunately, they're already getting sued over this, but just in case
that doesn't succeed, there should also be bigger public pressure on Apple to
allow them.

[http://www.recode.net/2016/10/7/13201832/apple-sued-ios-
brow...](http://www.recode.net/2016/10/7/13201832/apple-sued-ios-browser-
limits)

~~~
tedmielczarek
I've had a Gecko port stood up and running on iPhone hardware several times in
the past 6 years but we've never sorted out a real path to shipping. The most
recent incarnation felt a lot nicer than Safari with our async pan/zoom
architecture. Maybe I should just get Servo running and we can ship it as a
tech demo. :-P

~~~
larsberg
I'll do the CI work to keep it building :-)

------
bobajeff
This sounds to me like Mozilla is getting impatient with Servo. Servo was more
than just a parallel browser engine it was the only new web engine not based
off of decade old codebase.

It was a statement that it's feasible to hold off on monoculture because
compatibility isn't impossible to achieve on new engines.

~~~
bzbarsky
Compatibility in new engines is ... hard. Servo is basically going to need to
spoof the WebKit UA and duplicate a bunch of WebKit bugs (the Edge approach)
or spoof the Gecko UA and duplicate a bunch of Gecko bugs. Some specs now have
an explicit "does your UA say you are Gecko, or does it say you are WebKit"
switch with behavior specified for both branches. :(

~~~
Aldo_MX
Considering that Servo is an embeddable engine, why not keep the scope of
Servo focused in building a standards-compliant engine?

Replicating other engine's bugs sounds like too much effort towards the wrong
direction :/

Although, after the -webkit-disaster I don't really expect anyone to like the
idea of a standards-compliant engine :(

~~~
pcwalton
> Considering that Servo is an embeddable engine, why not keep the scope of
> Servo focused in building a standards-compliant engine?

That's what we've done so far. We haven't exposed any Gecko- or WebKit-
specific stuff that I'm aware of. We have our hands full with the standard :)

(That said, we have implemented things that are unspecified but are _de facto_
standards implemented by _both_ Gecko and WebKit. That includes basic things
like <button> and tables…)

~~~
kibwen
Any efforts underway to turn those de facto standards into actual standards as
Servo encounters them?

~~~
pcwalton
Yes, when we have time. For example, notriddle has been going great work
trying to spec hypothetical boxes:
[https://github.com/notriddle/ServoHypothetical](https://github.com/notriddle/ServoHypothetical)

------
aantix
They should use Yahoo's front page as their performance baseline.

Whenever I load it, the favicon starts to flicker, multiple movies (ads) start
playing, and I can't tell whether scrolling has been badly hijacked by some
rogue js plugin or if the performance of their video playback is just _that
bad_.

~~~
mgalka
Yahoo's home page explains so much about the company -- unable to maintain
even the simplest and most basic features of their site. I'm still on Yahoo
mail, and there were a few months this year where the basic search
functionality didn't work.

Yahoo would probably make a great case study in corporate culture gone wrong.

~~~
AceJohnny2
> _Yahoo would probably make a great case study in corporate culture gone
> wrong._

"would probably"? :)

------
mnemonik
Quantum wiki page with info on how to get involved:
[https://wiki.mozilla.org/Quantum](https://wiki.mozilla.org/Quantum)

------
mthoms
I hope that low power usage remains a key priority. Surprisingly, I don't see
any mention of it in this article.

~~~
mnemonik
There is some discussion about power usage in this video by Jack Moffit:
[https://www.youtube.com/watch?list=PL4sEzdAGvRgCYXot-o5cVKOo...](https://www.youtube.com/watch?list=PL4sEzdAGvRgCYXot-o5cVKOobIXZI5iLF&v=UGl9VVIOo3E)

------
yalooze
Does anyone know how this compares to the current implementations of competing
browsers? ie. is Firefox still playing catch up in some respects or is this
leaps ahead of the competition too?

~~~
metajack
I think performance of the style systems in Blink and Firefox are similar.
Since Servo's style system is linearly scalable, we expect most users to get a
~4x speed improvement on styling.

Users's don't care specifically about style performance, though, but about
things like interactivity. We think Servo's style system will improve those
things, but don't have numbers for that on hand.

To give a concrete example, it takes Firefox ~1.2 seconds to restyle the
single page HTML5 spec with it's current non-parallel style system. Firefox
with Stylo can do this in ~300ms. That is close to a full second off of
initial page load.

~~~
gsnedders
How does WebKit's JITing style system compare? (As far as I'm aware, nobody
else has anything like it, though it is still single-threaded as far as I'm
aware.)

~~~
pcwalton
I would eventually like to look into a CSS JIT. But I would not like to just
copy WebKit—I would like to look into treating CSS as a global DFA and
compiling accordingly instead of looking at local optimizations only.

As always, the problem with JITs, especially on the Web, that it's hard to
beat the interpreter when you take compilation time into account, and most
selectors you see in the wild only apply to a small number of nodes.

~~~
notriddle
For context, [here's an IRC discussion about implementing style matching as a
single global DFA, and what it's tradeoffs would
be]([http://logs.glob.uno/?c=mozilla%23servo#c550146](http://logs.glob.uno/?c=mozilla%23servo#c550146)).

------
c-smile
"But nowadays we browse the web on ... that have much more sophisticated
processors, often with two, four or even more cores."

Having batched GPU rendering / rasterization makes real sense, yes. When it
shown, the browser is the largest screen space consumer.

4K displays (300ppi) increased number of pixels that need to be painted by 9
times. Thus CPU rendering / rasterization is not the option anymore, yes.

But browser is not the only process competing for those cores.

2 or even 4 cores ... You have more front running applications than that these
days. Some of them are invisible but still CPU intense.

In order to get significant benefits from parallelism in browsers the number
of cores shall be measured in tens at least I think. If not even more than
that. To run things in parallel like bunch of Cassowary solvers for each BFC
container.

I suspect that the main bottleneck at the moment is in existence of methods
[1] that force synchronous layout / reflow of the content. These are things
that kill parallel execution. DOM API shall change towards batch updates or
other more parallel friendly means.

[1]
[https://gist.github.com/paulirish/5d52fb081b3570c81e3a](https://gist.github.com/paulirish/5d52fb081b3570c81e3a)

~~~
pcwalton
> 2 or even 4 cores ... You have more front running applications than that
> these days. Some of them are invisible but still CPU intense.

Occasionally that's true, but users typically interact with just one app at a
time. Even if background tasks are running and taking up CPU time (which is
_not_ the common case—if it were then games wouldn't work!) the foreground app
should get priority in using the CPUs. So background apps aren't relevant
here, any more than background apps are relevant in a single-core scenario.

> In order to get significant benefits from parallelism in browsers the number
> of cores shall be measured in tens at least I think. If not even more that
> that. To run things in parallel like bunch of Cassowary solvers for each BFC
> container.

First of all, that's not true, based on our measurements. We've seen large
improvements with as few as two cores. Second, CSS parallelizes just as well
if not better than Cassowary: unless text actually has to wrap around floats
we can lay out _every block_ in parallel. Even when there's a lot of text
wrapping around floats, we can lay out all the floats in parallel.

> These are things that kill parallel execution.

Even if we had batch updating APIs, existing browser engines would be in no
position to offload layout and restyling to a separate thread. The DOM and
render tree are too intertwined in typical engines.

~~~
c-smile
"we can lay out every block in parallel"

I wouldn't be so optimistic, especially with flexboxes and grids.

    
    
          display:grid;
          grid-columns: 1fr max-content 1fr minmax(min-content, 1fr);
    

The above requires intrinsic min/max width calculations (full layouts de
facto) before you can even start doing layout of cells in parallel.

The same is about our old good friend <table> by the way where each cell is
BFC.

~~~
pcwalton
Intrinsic inline-sizes have been handled just fine in Servo from day one with
a parallel bottom-up traversal. This is well-known; the technique goes back to
the Meyerovich paper.

------
TeeWEE
You can make a super fast web browser, but that doesnt solve the fundamental
issue: The web is not designed for performant applications. Resources loading,
javascript, rendering... Solve that first before you build a fast engine...

Off course a fast engine is good. But dont forget the root problems with the
web.

~~~
amelius
Yes. The article speaks of "zero latency", but that is simply not achievable
with a network connection that has latency. My guess is that in current
browsers, on average 90% of the latency is in the network (as opposed to
rendering). So even if the render step was perfect, you would only get a
measly 10% performance gain.

------
TekMol

        we’ll be rolling out the first stage of Electrolysis to
        100% of Firefox desktop users over the next few months.
    

From my experiments with it, this _still_ does not fix the problem that the
javascript in all windows shares one core. A script running in one browser
window still slows down the other windows.

A problem that Chrome has solved years ago. So I think this is not really a
leap for the web. Just FireFox catching up a bit.

FireFox is my main browser. The way I deal with it is that I start multiple
instances as different users. So they run inside their own process. This way I
can have a resource hungry page open in one window (For example a dashboard
with realtime data visualization) and still work smoothly in another.

~~~
bholley
> So I think this is not really a leap for the web. Just FireFox catching up a
> bit.

To be clear, Project Quantum is the next phase of architecture, post-
Electrolysis. We're also simultaneously working on multiple content processes
(which is how Chrome often avoids inter-window jank), but not under the
Quantum umbrella.

We think we can do better though, which is where Quantum comes in. The Quantum
DOM project is designed to solve exactly the problem you're describing, while
using fewer resources and scaling to more tabs. Stay tuned!

~~~
Eridrus
This sounds like it directly conflicts with sandboxing tabs, either for
security or stability. Am I missing something?

------
runeks
I don't understand what the difference is between Quantum and Servo. To me it
sounds like a new name for the same thing. I recall Servo being promoted this
way three years ago.

~~~
Manishearth
Quantum is about new architectural advances within Gecko. These advances can
be achieved by taking code from Servo (Quantum Style), ideas from Servo
(Quantum DOM), or in general new ideas (not sure if any of the quantum
projects are of this form).

Servo is still its own thing. The timelines are radically different, Quantum
is something you should be able to directly benefit from a year from now;
Servo is something you should be able to directly benefit (as a product) from
in the far future. You of course may indirectly benefit from Servo when its
advances are applied to other browser engines (which is what quantum is).

------
bandrami
Pet peeve of mine: a "quantum leap" is literally the _smallest change of state
that is physically possible_ , but it's come to mean the opposite in popular
use.

~~~
TheRealPomax
Time to shelve that pet peeve, because any physicist should be able to tell
you that this claim is one of those hilarious "people keep pretending this is
true" when it has nothing to do with what a quantum leap actually is.

In physics, a "quantum leap" is a synonym for atomic electron state changes.
These don't take place as a continuous gradient change, they jump from one
state to the next, releasing or absorbing photons as they do so: the changes
are quantized, and any change from one state to another termed a quantum leap.
And it really is "any change": they're all quantum leaps.

There is also no stipulation on direction, state changes go both up and down.
So while there certainly is a lower bound to the value that we will find in
the set of all possible quantum leaps in atomic physics (because you can't go
"half distances", the whole point of quanta is that it's all or nothing). the
idea that a quantum leap is "one value" is patent nonsense; different state
transitions have different values, and can be anywhere between tiny and huge
jumps, and can release massively energetic photons in the process.

And if the term has been given a new meaning in everyday common language, then
cool. That's how language works. It doesn't need to be correct with respect to
its origin, people just need to all agree on what the terms used mean. In
every day language, understanding that "a quantum leap" means "a fundamental
change in how we do things" (which is implied always a big deal, even if the
change itself is small) demonstrates a basic understanding of conversational
English. So that's cool too.

~~~
bandrami
_In physics, a "quantum leap" is a synonym for atomic electron state changes.
_

Right. The smallest such change physically possible, which is exactly what I
said.

~~~
TheRealPomax
Again with the pretending there is only one possible change here: a state
change in high orbit excitation levels is nowhere near "the smallest such
changes", yet we still call them quantum leaps because that's what they are.
The distances and energies involved are HUGE at the atomic scale, which is the
scale we must necessarily stay grounded in when discussing what a quantum leap
"really" means. (where "really" is a misnomer because there is nothing that
requires a scientifically precise term to be reflected in common everyday
language. The only important part is that you don't use the meaning of the
latter in the context of the first)

------
k26dr
Doesn't Chrome/Chromium already run as multiple processes?

~~~
Roboprog
I believe it is "only" one process per tab on Chrome. This sounds like having
multiple processes per tab (or at least, active tab), splitting up different
kinds of work to "specialist" processes.

Clarification / refinement, anybody?

~~~
the8472
There is this concept called "threads" which can be found in most operating
systems.

~~~
Roboprog
Process, thread, task, whatever.

(I so remember the first time I was reading about threads in OS/2 and Novell
back in 1989 or 90 - no risk not worth taking to squeeze a little bit more out
of 10 MHz CPUs with OS's with crummy process management, I guess)

------
andrewstuart
I wish I could see how much processing power/memory was being taken by each
tab.

------
joshmarinacci
It's about damn time!

------
mxuribe
Looking forward to this!

------
ifhs
Sorry but posting this on medium is a quantum leap backwards. That too from
Mozilla.

------
criddell
Heh. It's interesting to me that in the vernacular a _quantum leap_ is a large
change while in physics it's a very quick, extremely tiny event.

~~~
krastanov
No! This meme is just wrong (and it does grind my gears to an unreasonable
amount as a physicist). In physics quantum means discrete, it does not mean
small. Hence the idiom "quantum leap" used as "a discontinuous abrupt jump in
quality" is perfectly in sync with the way physicists use the phrase.

~~~
criddell
I'm not saying it _means_ small, just that quantum leaps are nanoscale. And
also, the state after the leap isn't better or worse than the state before,
just different.

~~~
krastanov
I still disagree. Quantum does not imply nanoscale - we are building bigger
and bigger systems that exhibit inherently quantum behavior (for instance
superconducting cavities used in quantum computing research are centimeter
scale). Moreover, the jump is not necessarily in a spatial variable - it can
be a very big jump in energy levels for instance, which is the case with laser
emissions.

Sure, a (big or small) discrete jump does not necessarily imply a jump to
something better, but that has little to do with my complaint about the meme
that "quantum implies small".

~~~
criddell
I stand corrected. Thank you.

