Mozilla's Servo Engine Is Crazy Fast Compared To Gecko

Discussion about official Mozilla Firefox builds
Post Reply
User avatar
itisomegakai
Posts: 358
Joined: February 13th, 2014, 11:52 am

Re: Mozilla's Servo Engine Is Crazy Fast Compared To Gecko

Post by itisomegakai »

Our long-term plan is to:

Incrementally replace components in Gecko with ones written in Rust and shared with Servo.
Determine product opportunities for a standalone Servo browser or embeddable library (e.g., for Android).

Our 2016 goals for Servo are:

Explore new areas for performance improvements
e.g., GPU CSS, SIMD layout, DOM wrapper fusion
Fill in remaining placeholder subsystem implementations
e.g., I/O, caching
Continue adding web platform features
e.g., media, text input/editing, missing layout & JS features
Bring Windows port to Tier 1
Webrender: Move from prototype to production

Our completed goals for 2016 are:

Create an initial end-to-end browser tech demo that we can start iterating
browser.html frontend
Oxidation: Ship Rust/Servo components in Gecko
Track performance systematically
Allow comparisons with Gecko and Blink
Support more standard benchmarks

Q3 2016

Top priorities for this quarter are:

Finishing WebRender (on by default in master!) plus experiments around WebRender 2
Stylo (style system in Gecko integration work)
Servo Nightly builds support

High-level work plan for staff members:

simon & manish on stylo
glenn webrender2
diane working on devtools fetch for profiling, rust-nss with nss team, security stuff
patrick page load performance (for fresh page loads, target FF pre-caching) & layout bugs
alan on error reporting for constellation + script/layout concurrency
nox indexeddb, webfont loading
ms2ger spidermonkey upgrade, JS error reporting
jack windows installer, windows fonts (w/nox), intermittents
lars autoupdate, android, quantum/oxidation
shing testing into servo org, flexbox, stylo, QA rampup
emily Autolander migration, TaskCluster migration
jdm Promise API implementation

Internally committed 2016 goals

Implement production IO and caching subsystems
Polish and validate WebRender, a next-generation graphics subsystem
Layout maturity
Ship one Rust component in Firefox Nightly, riding the trains
Experiment with the uplift of a major piece of Servo into Gecko
iwod
Posts: 1033
Joined: July 18th, 2003, 10:09 pm

Re: Mozilla's Servo Engine Is Crazy Fast Compared To Gecko

Post by iwod »

avada wrote:
speciesx wrote:
Romani wrote: 2) They not yet build Servo for Windows. P
But you can build by yourself.
It's pretty simple, follow the build instruction from here: https://github.com/servo/servo

http://abload.de/image.php?img=s1b4szno2udm.png

I for one don't want to spend time with build at all. Just take peak at it to see how it works and what stat it's at.

Does anyone have windows builds lying around?
Romani wrote: In Mozilla they say about various bugs on Linux itself preventing them to implement that ant this, but its doesnt seem to bother them to do something about this.
Like hardware video acceleration. They say "they cannot use it on Linux due bugs". Fine, but why MPV can use it then? VDPAU, VAAPI - its all works. Even more, it was posible to use via GStreamer, but they was sooo smart so they removed GStreamer support.
WebSpeech component they work on is totally unusable on Linux because they doent bothered to actually get it really working and so on so on.
And there is a LOT more.
Sadly this shows mozilla's mentality in general. The browser is filled with buggy features, they just stop bothering to fix them if it's not too noticeable. It looks pretty anarchistic, where the devs keep working on things that interest them or are not to difficult/messy to deal with. And bugs just linger around for years, decades sometimes.
Sad but true.
User avatar
Grantius
Posts: 1545
Joined: June 28th, 2011, 4:14 pm
Contact:

Re: Mozilla's Servo Engine Is Crazy Fast Compared To Gecko

Post by Grantius »

itisomegakai wrote:
Our long-term plan is to:

Incrementally replace components in Gecko with ones written in Rust and shared with Servo.
Determine product opportunities for a standalone Servo browser or embeddable library (e.g., for Android).

Our 2016 goals for Servo are:

Explore new areas for performance improvements
e.g., GPU CSS, SIMD layout, DOM wrapper fusion
Fill in remaining placeholder subsystem implementations
e.g., I/O, caching
Continue adding web platform features
e.g., media, text input/editing, missing layout & JS features
Bring Windows port to Tier 1
Webrender: Move from prototype to production

Our completed goals for 2016 are:

Create an initial end-to-end browser tech demo that we can start iterating
browser.html frontend
Oxidation: Ship Rust/Servo components in Gecko
Track performance systematically
Allow comparisons with Gecko and Blink
Support more standard benchmarks

Q3 2016

Top priorities for this quarter are:

Finishing WebRender (on by default in master!) plus experiments around WebRender 2
Stylo (style system in Gecko integration work)
Servo Nightly builds support

High-level work plan for staff members:

simon & manish on stylo
glenn webrender2
diane working on devtools fetch for profiling, rust-nss with nss team, security stuff
patrick page load performance (for fresh page loads, target FF pre-caching) & layout bugs
alan on error reporting for constellation + script/layout concurrency
nox indexeddb, webfont loading
ms2ger spidermonkey upgrade, JS error reporting
jack windows installer, windows fonts (w/nox), intermittents
lars autoupdate, android, quantum/oxidation
shing testing into servo org, flexbox, stylo, QA rampup
emily Autolander migration, TaskCluster migration
jdm Promise API implementation

Internally committed 2016 goals

Implement production IO and caching subsystems
Polish and validate WebRender, a next-generation graphics subsystem
Layout maturity
Ship one Rust component in Firefox Nightly, riding the trains
Experiment with the uplift of a major piece of Servo into Gecko
Thanks
Micro gaming box: AMD A10-7800 APU, 8gb RAM M350 ITX case (size of a book), Windows 10/Ubuntu
Tablet/Laptop: Asus Transformer T100, Intel Atom 2GB RAM, Windows 10 x86
Mobile:Xiaomi Redmi Note 3 Pro
avada
Posts: 1932
Joined: February 10th, 2008, 6:30 am
Location: Hungary

Re: Mozilla's Servo Engine Is Crazy Fast Compared To Gecko

Post by avada »

itisomegakai wrote:
Our long-term plan is to:

Incrementally replace components in Gecko with ones written in Rust and shared with Servo.
Sounds like a recipe for disaster. Or at least for conserving the flaws related to the structure of gecko.
User avatar
itisomegakai
Posts: 358
Joined: February 13th, 2014, 11:52 am

Re: Mozilla's Servo Engine Is Crazy Fast Compared To Gecko

Post by itisomegakai »

Hacking & Contributing to Servo On Windows

https://hacks.mozilla.org/2017/04/hacki ... n-windows/

Fix windows glutin keydown #16198


https://github.com/servo/servo/pull/16198
avada
Posts: 1932
Joined: February 10th, 2008, 6:30 am
Location: Hungary

Re: Mozilla's Servo Engine Is Crazy Fast Compared To Gecko

Post by avada »

Hi!

Does anyone know what's the point in having a multiprocess architecture? Couldn't multi-treading achieve the same thing with less overhead and problems?
Josa
Posts: 7360
Joined: July 28th, 2009, 4:52 pm

Re: Mozilla's Servo Engine Is Crazy Fast Compared To Gecko

Post by Josa »

If you have 1 process and 1000 threads you're locked to 1 logical cpu core.
If you have 2 process and 1000 threads you have 2 logical cpu cores to use.

My notebook have 2 physical cores (4 logical processors) while fast machines have 8/16... That's the future.
User avatar
trolly
Moderator
Posts: 39851
Joined: August 22nd, 2005, 7:25 am

Re: Mozilla's Servo Engine Is Crazy Fast Compared To Gecko

Post by trolly »

?!
A process can use any number of cores for its threads. A process with e.g. two threads can (and will) use two cores.
Think for yourself. Otherwise you have to believe what other people tell you.
A society based on individualism is an oxymoron. || Freedom is at first the freedom to starve.
Constitution says: One man, one vote. Supreme court says: One dollar, one vote.
dsmith
Posts: 246
Joined: November 5th, 2002, 1:00 pm

Re: Mozilla's Servo Engine Is Crazy Fast Compared To Gecko

Post by dsmith »

avada wrote:Hi!

Does anyone know what's the point in having a multiprocess architecture? Couldn't multi-treading achieve the same thing with less overhead and problems?
If a thread hangs/crashes, it brings down its parent process with it. With single-process architecture, that means the entire program crashes if a single thread crashes. With multi-process architecture, it means only one out of N processes crashes, and you're more easily able to restart it.

If a thread locks up (such as when waiting on resources to load, or a network query to complete), it may prevent the parent process from continuing for a time. This is commonly seen as 'jank' — hiccups in the responsiveness of the program. With a single process, you will always notice that; with multi-process, you will only notice it sometimes, and it depends on how the processes are separated. If the UI process is separate from the processes that are loading and rendering web pages, there are far fewer ways for slow web pages to slow down the entire program.

Multi-process architecture forces you to think about and handle asynchronous communications. With a single process, you can use the 'easy' approach of direct (synchronous) calls, so coders will tend to take the simpler/lazy route instead. Forcing everything to be async drastically improves responsiveness across any function calls that can take any significant time to complete. That innately improves the perceived speed of the browser as a whole, and also improves the efficiency of handling much of the underlying code.

And I believe there's security benefits to process isolation as well.

There are other aspects, such as memory isolation, sandboxing, and likely a number of other factors that helped encourage the multi-process approach. Single-process/multi-threading has less overhead, and can be faster in certain simplistic measures, but that's fundamentally a more difficult design to do safely and correctly, so it's much more likely to break. The multi-process approach is more complicated to set up, but has a number of architectural advantages.
avada
Posts: 1932
Joined: February 10th, 2008, 6:30 am
Location: Hungary

Re: Mozilla's Servo Engine Is Crazy Fast Compared To Gecko

Post by avada »

Josa wrote: If you have 1 process and 1000 threads you're locked to 1 logical cpu core.
If you have 2 process and 1000 threads you have 2 logical cpu cores to use.
This can't be true.
trolly wrote:?!
A process can use any number of cores for its threads. A process with e.g. two threads can (and will) use two cores.
That's my understanding also.

For example ffmpeg runs in a single process, yet maxes out my 12 logical cores.
User avatar
GHM113
Posts: 707
Joined: December 16th, 2015, 3:59 am
Location: Moscow, Russia

Re: Mozilla's Servo Engine Is Crazy Fast Compared To Gecko

Post by GHM113 »

avada wrote:For example ffmpeg runs in a single process, yet maxes out my 12 logical cores.
Same with games: Watch Dogs 2, Battlefield One, Crysis 3 (with grass), etc.
Sorry for my poor English.
avada
Posts: 1932
Joined: February 10th, 2008, 6:30 am
Location: Hungary

Re: Mozilla's Servo Engine Is Crazy Fast Compared To Gecko

Post by avada »

@dsmith

Interesting.
dsmith wrote:If a thread hangs/crashes, it brings down its parent process with it. With single-process architecture, that means the entire program crashes if a single thread crashes. With multi-process architecture, it means only one out of N processes crashes, and you're more easily able to restart it.
dsmith wrote:If a thread locks up (such as when waiting on resources to load, or a network query to complete), it may prevent the parent process from continuing for a time. This is commonly seen as 'jank' — hiccups in the responsiveness of the program. With a single process, you will always notice that; with multi-process, you will only notice it sometimes, and it depends on how the processes are separated.
However, are you sure about this? It doesn't feel right. I can't see why couldn't it be possible for other threads to continue running when one is failing, and some management thread ending the problematic thread. Similarly, why couldn't a locked thread be handled the same way as a locked process?
dsmith
Posts: 246
Joined: November 5th, 2002, 1:00 pm

Re: Mozilla's Servo Engine Is Crazy Fast Compared To Gecko

Post by dsmith »

avada wrote:I can't see why couldn't it be possible for other threads to continue running when one is failing, and some management thread ending the problematic thread.
And at that point you've reintroduced all the overhead of processes, so you might as well use the components that have been designed to do it correctly, rather than ad-hoc it by yourself.
avada wrote:Similarly, why couldn't a locked thread be handled the same way as a locked process?
Because threads cannot be guaranteed to be isolated from all other threads in the same process. There's shared memory (and figuring out who owns what when a thread is killed), resources, data structures, etc. That is, all the things that make using threads "low overhead" instead of "high overhead". It's impossible to kill a thread safely without analyzing every single reference on every other thread in the process, plus all the resources the failed thread was holding, unless you have absolute knowledge about what that thread can do, and that it is properly isolated (which is unlikely to be the case the vast majority of the time). And even if you have all that, there's almost no way to 'fix' things in any meaningful sense of the word. Approaching things this way is fundamentally wrong-headed, because you'll have a never-ending list of things that will be broken.

Processes, on the other hand, are explicitly isolated from each other by design. If a process has a crash, you can kill it and restart it knowing that you won't be breaking other processes, because processes cannot have access to the internals of other processes (barring some debugging methodologies, but you won't be using that in a normal program).
Lurtz
Posts: 359
Joined: June 12th, 2016, 12:25 pm

Re: Mozilla's Servo Engine Is Crazy Fast Compared To Gecko

Post by Lurtz »

avada wrote:That's my understanding also.

For example ffmpeg runs in a single process, yet maxes out my 12 logical cores.
Lin Clark explains it very well.

Have a look at coarse-grained and fine-grained parallelism: https://hacks.mozilla.org/2017/11/enter ... et-faster/

It's very difficult to parallelise a browser engine (while it is relatively simple with an encoder like ffmpeg). That's why Google and now Mozilla chose coarse-grained parallelism as a first step (multi-process model). The next step for Mozilla is fine-grained parallelism, so using more cores within a process.
User avatar
Mark12547
Posts: 327
Joined: May 13th, 2017, 11:36 am
Location: Oregon, United States, Earth

Re: Mozilla's Servo Engine Is Crazy Fast Compared To Gecko

Post by Mark12547 »

avada wrote:Does anyone know what's the point in having a multiprocess architecture? Couldn't multi-treading achieve the same thing with less overhead and problems?
Sandbox!

Resources (e. g., memory, file handles), security and access rights are assigned to the process. If a thread is in a memory allocation loop, it can potentially consume all the memory available for the process and crash the process. If a thread has a wild pointer, it can directly affect only that process, from wiping out various values to destroying part of the code and cause the process to crash, but not directly affecting other processes.

For example, by having the gui process separate from the other processes, if something happens that ends up crashing the gui process (which happens with some gui/driver combinations), the other processes can continue running. Likewise, the main process can have access to the local file system but not allow a child process to access the file system. Or by having a separate content process spawned by the main/UI process, if the content process hits an out-of-memory condition and ends up crashing, the main/UI process continues running, as well as other content processes (if any).

There is another reason for multiple content processes: the original design of the gecko web browser engine was back when PCs had single-core CPUs, so much of the code was written without concern about simultaneous access to the same block of code. Until that code could be modified to handle multiple simultaneous access to that block of code, only one thread at a time can be allowed to access that block of code. That effectively means that only one web page can be rendered at a time, web pages in other tabs are stuck until the first finishes rendering. But by having multiple content processes, each with its own copy of the gecko web rendering code, multiple pages (tabs) can be rendered at the same time. If there are enough CPU cores, all processes could be rendering at the same time, but if there are more content processes attempting to render than there are cores, the operating system will take care of time slicing the cores among the content processes that are ready to run.

Part of the project to rewrite parts of gecko in Rust is to allow multiple threads to run simultaneously, so a content process cold render multiple web pages at the same time without the extra memory required for multiple content processes.
Post Reply