> 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/132…
A Quantum Leap for the Web
91–100 of 141 posts
Re: A Quantum Leap for the Web
#92[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…
> 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 sin…
> 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.
Several reasons why this isn't low-hanging fruit and isn't as valuable as it may seem:
1. Servo runs separate origins as fully separated JS VMs on separate threads. Because they're separate runtimes, the collections can already happen concurrently.
2. The isolated JS runtimes imply isolated heaps, so there is no need for global collection (and in fact no way to do it even if we wanted to with the current SpiderMonkey architecture). Small individual per-origin heaps are much faster to collect than large global heaps.
3. While collection is happening, like in other modern browsers, the Servo chrome and scrolling are fully responsive. But Servo goes beyond that: animations, layout, and repainting can also happen while a GC is occurring. This means that CSS transitions/animations on the page (all animations, not just transform and opacity!) will still happen while the page is collecting, and you can switch tabs and resize the window while the GC is running. You can even interact with cross-origin iframes on the page, so GCs triggered by ads won't affect the content you're reading!
4. SpiderMonkey already has incremental and generational GC, so we've done most of the work necessary to reduce stop-the-world pauses already.
5. Making a single-threaded GC concurrent is a lot of work. It's not low-hanging fruit by any stretch of the imagination.
6. Furthermore, making a single-threaded GC concurrent usually involves a throughput loss, because now you need operations to be atomic that weren't atomic before.
That said, the GC is something that the SpiderMonkey team continues to make steady progress on, and that work directly benefits Servo. So fear not, we aren't neglecting the GC either :)
Re: A Quantum Leap for the Web
#93Having 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.
Re: A Quantum Leap for the Web
#94"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 brows…
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.
Re: A Quantum Leap for the Web
#95They 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 .
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.
"would probably"? :)
Re: A Quantum Leap for the Web
#96Earlier quoted context omitted.
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. :(
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 :(
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 and tables…)
Re: A Quantum Leap for the Web
#97Earlier quoted context omitted.
> I never said that it wasn't. I said that it wasn't going to be shipped as a production Mozilla product. That's also not true. Maybe it will, maybe it won't; that's a decision that has to incorporate many factors other than technical ones. From my point of view as an engineering lead, I'm designing the engine to ship.
One key difference here is that this keeps Servo open to continuing to be a research vehicle for new technologies without the exposure of compatibility for millions of users. If we ship Servo in a product that does change the equation a bit.
Re: A Quantum Leap for the Web
#98This 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.
Servo is still being developed with the same manpower. Quantum is not de-emphasizing Servo. It would make little sense to do so, since the lack of legacy in Servo is part of what has given us the freedom to experiment with things like parallel restyling in the first place. And Quantum helps Servo, too—by giving us real-world Web compatibility experience with portions of Servo's codebase sooner, it helps us shake out…
I hope that either mozilla is lying for political reasons about their lack of intent to use servo outright, or that the servo team forks from mozilla and takes funding from patreon (or snowdrift when it launches) and builds something great, without the burden of mozilla and firefox.
Re: A Quantum Leap for the Web
#99"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 brows…
> 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…
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 by the way where each cell is BFC.
Re: A Quantum Leap for the Web
#100Earlier quoted context omitted.
> 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…
"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 by the way where each cell is BFC.