31–40 of 61 posts
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.
Sounds interesting. Do you have more information on that? Any links?
Are multiple cores being used to draw a webpage? If so, do typical webpages need this level of performance for a satisfactory user experience?
> If so, do typical webpages need this level of
> performance for a satisfactory user experience?
> draw a webpage
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.
Earlier quoted context omitted.
> 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 multic…
It would be extremely interesting to see any numbers that compare single-core layout (in Servo) with multi-core layout (in Servo).
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.
"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."
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…
Earlier quoted context omitted.
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…
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.
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.)
Earlier quoted context omitted.
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 dr…
Earlier quoted context omitted.
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 what about performance? Not compared to popular browsers, but compared to performance with single core mode.
Are multiple cores being used to draw a webpage? If so, do typical webpages need this level of performance for a satisfactory user experience?
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.