Hacker News Reader

Comment by supahfly_remix | Hacker News Reader

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

View on HN

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

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.

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.

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

Reply on news.ycombinator.com