“The colored boxes indicate which CPU core performed layout for each node” | Hacker News Reader

“The colored boxes indicate which CPU core performed layout for each node”

blog.servo.org

429 pointssteveklabnik57 comments

If you're curious why clustering of nearby nodes happens, it's a side effect of the work-stealing [1] strategy that Servo layout uses. This is actually beneficial for the cache, because adjacent layout objects tend to be located together in memory.

[1]: http://en.wikipedia.org/wiki/Work_stealing

Here's a PR showing off a different visualization, that of parallel painting of tiles: https://github.com/servo/servo/pull/4969

All of this work is really making Servo look more and more like it's going to be the future of browsers. I'm amazed that they're able to get the layout as parallelized as they are, and with the painting being like that I think it's got a great shot at being one of the more performant browsers on mobile.

I think all existing mobile browsers to tiled painting already.

They do, but not all of them parallelize it. (Chrome does, I believe.)

Are multiple cores being used to draw a webpage? If so, do typical webpages need this level of performance for a satisfactory user experience?

Yes multiple cores are being used. It's not that typical webpages need this level of performance, but by doing this you can actually save battery life and power usage on things like mobile devices and laptops. Since you can render the page 2-3x faster (numbers pulled out of donkey) you can use a burst of more cores at a lower speed to accomplish the same thing.

> Since you can render the page 2-3x faster (numbers pulled out of donkey)

2-3x faster seems about right for 4 cores:

http://www.phoronix.com/scan.php?page=news_item&px=MTgzNDA

I think that was on 4 ARM cores/threads, so the increase in performance may be even bigger for 4 cores/8 thread chips.

From the PDF link it also seems that if the 4 cores work "at the same performance" level as 1 core, power consumption can drop down to 40% (page 23).

https://events.linuxfoundation.org/sites/events/files/slides...

Perfect. I thought that's what I remembered reading but couldn't even come close to finding it when I wrote that. That's the kind of research they've been intending to do with it for a while now and it's honestly huge enough that I won't be too surprised if Servo starts replacing Gecko on Firefox OS and the Firefox Mobile browsers. All it's going to take is to really get it working on 90% of websites and then I think it'll be a clear contender for replacing Gecko in a lot of places. I'd love to also see a JS engine in Rust but I know with a JIT and all you end up with none of the safety you get from Rust anyway. With the browser chrome being done in HTML with the mozbrowser extensions it looks like it might be possible to start doing a lot of the same things that XUL does in firefox which opens the door to a lot of stuff being ported to the new browser.

> Are multiple cores being used to draw a webpage?

Yes. There is coarse-grained parallelism (e.g. script, layout, painting can all happen simultaneously) and fine-grained parallelism (e.g. every render object is restyled and laid out concurrently).

> If so, do typical webpages need this level of performance for a satisfactory user experience?

It depends on the site, of course, but preliminary results show that multicore style recalc and layout result in large improvements in many areas that feel slow today. Examples are loading new items on "infinite-scroll" pages and CSS transitions that require layout (e.g. "top", "left", "margin-right"). In particular, Web developers frequently write animations that require layout, so large improvements there have the potential to benefit apps a lot.

Do you know of any resources that go in depth into how different layouts affect parallelism?

I have a blog post from last year on the topic: http://pcwalton.github.io/blog/2014/02/25/revamped-parallel-...

It would be extremely interesting to see any numbers that compare single-core layout (in Servo) with multi-core layout (in Servo).

Here's a draft of an experience report regarding Servo that was submitted to this year's ICFP: http://kmcallister.github.io/papers/2015-servo-experience-re...

Table 1 seems to give some relevant data:

      Site | Gecko | Servo 1 thread | Servo 4 threads
    -------------------------------------------------
    Reddit |   250 |            100 |              55
       CNN |   105 |             50 |              35

  Table 1. Performance of Servo against Mozilla's Gecko
  rendering engine on the layout portion of some common
  sites. Times are in milliseconds, where lower numbers
  are better.

Given the promising numbers here, I feel like the following bold quote from a Servo-related job opening at Mozilla is relevant:

"Our goal is nothing less than building the fastest and most secure browser engine, and we aim to succeed by miles, not inches. We aim for double the performance of current engines, with no crashes."

http://careers.mozilla.org/en-US/position/ollA0fw0

It would be interesting if Servo could get layout time under the frame budget on mobile devices. Right now, the divide is basically "Do whatever you want on desktop, but don't touch the DOM or use any CSS property other than transform/opacity in a mobile animation" - and it misses the mark by a large margin, eg. layout on a reasonably complicated site like Google Search is on the order of 100-150ms while the frame budget is 17ms. If you could get layout on mobile to run in under, say, 10ms, it would dramatically change what web developers can do in an animation, which would potentially also change the native vs. web technology equation.

It's all about "butter" vs "stutter".

And as a Firefox fanboy, I'm sad to report that Firefox is on the latter end of the continuum. What you describe is my experience exactly -- except that it's not quite limited to mobile.

I do all my primary development against Firefox. I'm content to optimize for Gecko, and I've learned what it handles well and what it doesn't [0]. In cases where I've really doubled down to optimize some transitions, I can get almost-butter from Firefox, where Chrome and Safari are pure pleasure, seemingly no matter what I throw at them. Hell, even IE 11 is better when it comes to transitions.

That said, I think Gecko looks the most beautiful for static rendering. This is less true since Chrome 38, which supports proper web font rendering for Windows, but I'll maintain that Gecko's compositor output still has a certain je ne sais quoi compared to everything else.

Still, as a developer who "wants the web to win," [1] it's troubling to me that the vendors with native platforms are still outperforming in the browser space, and I hope that Servo is the dark horse that will change all that.

[0] For instance, I've read this thread one too many times: https://bugzilla.mozilla.org/show_bug.cgi?id=524925

[1] Quoting http://jlongster.com/Radical-Statements-about-the-Mobile-Web

I've noticed the Gecko vs WebKit rendering difference as well. I never bothered to look into exactly what it was.

According to some tests it does help. Since the page can only "start rendering" after it finishes calculating layout so a parallel layout algorithm lets you start showing the page sooner, which may feel snappier. This is even if the page ends up taking the same amount of time to render in the end (current browsers already try to parallelize some stuff).

do typical webpages need this level of performance for a satisfactory user experience?

It's needed because low-end phones have 8 slow cores instead of 2 fast cores.

Low end phones have 1 slow core, as far as I'm aware. I'm not aware of very many 8 core phones, let alone low end ones.

quad cores will be low end by the time servo is ready!

A few slow cores can do the work of one fast core in the same time with less energy. At least sometimes, depending on the parallelisation/synchronisation overhead. This is an important consideration for future mobile architectures.

GP meant low end smartphones. The first 64 bit android phone was one with 8 A53s coming out in China. Before that using 8 A7s was very popular. Small cores are very small compared to higher end cores. Part of this is 8 being a lucky number.

bought a knock-off Lenovo S850p (which is decidedly not lenovo) off Aliexpress a few months back [1]. unit legitimately has 8-cores (Mediatek 6595 Processor), and 4GB of ram. Other than the abysmal viewing angle, it's an incredible piece of hardware, especially for $100.

I install Xiaomi's latest MIUI on them (and Play Store), and then resell them locally for $300 each. and people tell me they're stealing them from me at that price.

1. http://www.aliexpress.com/item/Original-lenovo-s850c-Max-4G-...

  > If so, do typical webpages need this level of
  > performance for a satisfactory user experience?

Servo on desktop is certainly interesting, but a primary use case is mobile devices and other devices that have multiple CPU cores that aren't very powerful individually.

  > draw a webpage

Drawing a webpage on your screen entails a few different primary tasks.

Some things like alpha blending and animation can be offloaded to the GPU quite well and this is already being done extensively today on various mobile OSs.

Other things like layout, DOM manipulation, and scripting involve a lot of branching logic and need to be handled by the CPU. That's where Servo comes in - the goal is to better spread that stuff out across multiple CPU cores.

If layout is going to be so parallelized does that mean we're going to need better asynchronous DOM APIs and possibly better Javascript threading support?

Ensuring that those APIs will exist and that other APIs don't block parallel layout is one of the goals of Servo, as a project. It's already informed several emerging standards.

> It's already informed several emerging standards.

Sounds interesting. Do you have more information on that? Any links?

I don't remember the specifics, but pcwalton should be able to tell you more.

From a previous story: getting element width/height https://news.ycombinator.com/item?id=9011767

What is Servo?

Wikipedia's explanation is pretty good: http://en.wikipedia.org/wiki/Servo_%28layout_engine%29

New browser engine from Mozilla. One of its prime objectives is to build an engine that can leverage the multiples cores we have to day and work stuff in parallel. It still not ready for prime use but its growing really well.

IIRC its built with Rust and maybe some unsafe C/C++ code (unsafe in terms of Rust) for things such as the JS engine.

More info about Rust at http://www.rust-lang.org/

More info about Servo at https://github.com/servo/servo#the-servo-parallel-browser-pr...

C++ used for graphics also.

Thanks! Didn't knew that :D

speaking from a similar perspective here, I'm jealous of your long list of contributors

Piggybacking off of this, if anyone would like to try their hand at contributing to Servo I recommend checking out the "E-Easy" bugs on the issue tracker ( https://github.com/servo/servo/labels/E-easy ) and hitting up #servo on irc.mozilla.org ( http://chat.mibbit.com/?server=irc.mozilla.org&channel=%23se... ). It's not often that you get to be a part of rewriting a browser engine from scratch. :)

And you don't need to be a Rust expert to contribute (not least because essentially nobody in the world fits that description)! It's totally common for initial commits to be the first serious lines of Rust a contributor has ever written ( https://twitter.com/chimeracoder/status/583755185899626496 ).

I think this is a great advantage of Rust. Even with code review, you won't want to contribute your first C++ code to WebKit. But it's totally possible to contribute your first Rust code to Servo (I witnessed this multiple times), and damage you can cause is quite limited.

WebKit actually has quite a lot of fairly nice, simple easy-to-read C++, especially around the DOM. Or at least did a few years ago, and I believe it's still mostly the case.

I remember asking for advice years ago where to cut my teeth on C++ and getting suggested WebKit by several — and people who weren't trying to lead me massively into a pit of doom. (Admittedly, I've still practically never contributed to WebKit, and I ended up doing my first larger bits of C++ on Presto. But hey, I've still read plenty of WebKit code over the years.)

One nice—and, I think, underappreciated—thing about Servo layout is that the parallelism forces you to organize your algorithms cleanly. Unlike every other engine, render objects in Servo are not responsible for laying out their children recursively; the higher-level parallel traversal driver does that. That means that you must write your layout code in such a way that the right information is available at the time the traversal invokes your layout method. You are also limited in what you can access: your render object can't access your parent (because that would be racy), nor can it access the DOM (because we can run layout off the main thread). This requires a fair bit of up-front thought, but once that's finished it's easy to read the resulting code, because the layout code is grouped into specific functions ("assign-inline-sizes", "assign-block-sizes", and so forth) that do just one thing. This goes a long way toward making layout easier to understand, especially when it comes to complex situations like tables.

Right — and it's hardly surprising that Servo's codebase is in many ways nicer than existing browsers (both because of the inherent separation parallelization causes, and the lessons learnt from existing browsers). And given layout has always been arguably the worst part, it's hardly surprising that Servo shows good gains there.

Note that the contributors are from a period of three weeks (due to other commitments I ended up postponing/procrastinating this blog post for two weeks). But yeah, we usually get a lot of new contributors -- around 4 a week, with around ... 20% retention? (mostly guessing from observations). Still pretty nice given our size.

I'll attribute this to a couple of things:

We actively maintain a list of [easy bugs](https://github.com/servo/servo/labels/E-easy). This also means holding off on fixing minor things. For example, if I'm working on a feature I might notice some things which can be fixed, or have some portions of the feature that are easy to implement but can be excluded from the main pull request without losing out on much. I'll file E-Easy issues and land the basic pr, and those small changes will be something a hopeful new contributor can pick up and work on. Resisting that itch to fix all the things gets us a good crop of easy bugs. We don't have many string substitution easy bugs[1] unlike projects like Firefox, but most of the easy bugs can be worked on in an hour or two given a Servo build and basic Rust knowledge. Usually less than that.

Additionally, we do easy bugs right. There's almost always enough information to help a newbie get started; with links to the relevant code and/or spec. Of course, there's a lot we can improve on here, but we're still ahead of the curve on this.

We also mentor newbies -- if you leave a comment on an issue asking for help (or drop in on IRC), someone's bound to help you.

We consciously consider newbie onboarding, too -- "will this affect newbies?" is a common issue that springs up in discussions. It helps that many of the core contributors (including me) are volunteers themselves.

Our code generally isn't too complicated. Most of the areas which newbies flock to (eg the DOM) are well documented and we don't have much usage of advanced, confusing looking Rust features. I've seen open source code heavy with template metaprogramming and all sorts of strange macros --- whilst our code does use macros and syntax extensions, it looks pretty clean and to the most part the strangeness is innocuous (eg the annotations and other strangeness look ignorable). To be fair, this is probably highly subjective, but to me Rust code is generally quite readable, even when it uses advanced features -- it was this way when I started, too.

Also, we have Josh[2] :) He is behind most of the mentoring system in Firefox and is in general very interested in easing the way for new contributors -- most of the stuff above probably was largely his initiative. If you want ideas on how to improve newbie onboarding on a project you're interesting, you might want to have a discussion with him (or Ms2ger) in IRC.

[1]: I'm really fond of such bugs because they make for a very smooth transition for those trying out open source. For the first bug you do some easy thing like editing a string or deleting a comment or renaming a function, and get used to the version control system, issue tracker, and the workflow. For the second bug, try something more substantial; you can focus on the code this time without worrying about other things. [2]: http://github.com/jdm

And what about performance? Not compared to popular browsers, but compared to performance with single core mode.

Approximately 2x for 4 threads. See https://news.ycombinator.com/item?id=9313929.

Added the servo blog to my rss reader, waiting for the article that announce a compiled release.

Thanks for following it!

There's probably still time for this. We could create a nightly distribution of Servo in a day or so; but at the moment I don't think we see a need of this, especially given that there are still a couple of things (like everything needed for jQuery support) which we should get working first so that sites actually work in Servo. Perhaps this quarter we'll get all these features done.

(FWIW we have a nightly android apk distribution, but at the moment it's broken due to openssl strangeness)

Now thats a big font ;)

'Servo has another browser chrome!"

I like these competition jokes :)

Actually chrome always referred to the non-content parts of the UI. Or at least it already did back in the Mozilla Seamonkey days. Chrome the browser was named as such because it removed a lot of the chrome and focused mostly on the content.

It's obvious, but I still think it's not just boring word in this case.

Heh.

That wasn't intentionally a joke (I wrote that bit), but I can see how it sounds like one. "chrome" is a term for the stuff that's part of a browser but not the browser engine (the rest of the UI).

I did realize that that term could be misinterpreted (damn you Google) and thoought of alternative ways of putting it, but I couldn't come up with anything. "GUI" and "shell" both sounded wrong.

When I said "another" I was referring to MiniServo[1][2] and the CEF port.

[1]: https://github.com/pcwalton/miniservo-mac [2]: https://github.com/metajack/miniservo-gtk

I don't think it's a thing you should replace. Remember these stories about Netscape and MS? Funny time :) I'm sure people from both sides feel nothing except smiles in their souls, remembering these "wars".

Props for using the word "askew".

Why?

Didn't ask you. (amirite?)

I don't really understand your response. I was just curious what was special about the word "askew" from BasDirks' point of view.

"ask you" sounds a bit like "askew", for what it's worth.

Reply on news.ycombinator.com