Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A Quantum Leap for the Web

medium.com

Post reply on HN
Print view View original

81–90 of 141 posts

Re: A Quantum Leap for the Web

#81

Post by Manishearth »

Roboprog wrote: post #75
k26dr wrote: post #74

Doesn't Chrome/Chromium already run as multiple processes?

I believe it is "only" one process per tab on Chrome. This sounds like having multiple processes per tab (or at least, active tab), splitting up different kinds of work to "specialist" processes. Clarification / refinement, anybody?

Chrome is one process per tab (well, per origin, because same-origin JS), and within a tab is mostly single threaded (at least, this is my understanding).

Servo has a one process per tab mode (off by default), but regardless of that within a single tab both styling and layout can be parallelized across many threads, and rendering makes full use of the GPU.

This means that the active tab will be much faster. You don't care about rendering/layout speed for inactive tabs, and usually not styling speed either (restyles usually get triggered by interaction, though if you have a CSS game or something in a background tab that might matter). So process-per-tab doesn't make use of the resources it could, unless you're parallelizing within the tab. I suspect most background tab processes will be asleep or doing much less work; so while it helps for isolation (security, and less jank caused by one badly performing tab), it doesn't help as much for response time in a single tab.

Re: A Quantum Leap for the Web

#82

Post by mccr8 »

the8472 wrote: post #72
dherman wrote: post #4

[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…

Writing a parallel GC surely is not "low-hanging fruit" by any reasonable measure. Java already has to deal with concurrency in their objects, and throughput is more of a concern for server-like workloads, so they are dealing with a different situation. In Firefox, most of our effort has focused on improving responsiveness and eliminating work (through things like compartmental GC). (Some GC sweeping is already done in parallel in Firefox.)

That said, I believe IE does some concurrent marking, so there is certainly room for improvement.

Re: A Quantum Leap for the Web

#83

Post by Manishearth »

runeks wrote: post #51

I don't understand what the difference is between Quantum and Servo. To me it sounds like a new name for the same thing. I recall Servo being promoted this way three years ago.

Quantum is about new architectural advances within Gecko. These advances can be achieved by taking code from Servo (Quantum Style), ideas from Servo (Quantum DOM), or in general new ideas (not sure if any of the quantum projects are of this form).

Servo is still its own thing. The timelines are radically different, Quantum is something you should be able to directly benefit from a year from now; Servo is something you should be able to directly benefit (as a product) from in the far future. You of course may indirectly benefit from Servo when its advances are applied to other browser engines (which is what quantum is).

Re: A Quantum Leap for the Web

#84

Post by mgalka »

aantix wrote: post #35

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

Re: A Quantum Leap for the Web

#85

Post by Manishearth »

TheRealPomax wrote: post #54
bandrami wrote: post #49

Pet peeve of mine: a "quantum leap" is literally the smallest change of state that is physically possible , but it's come to mean the opposite in popular use.

Time to shelve that pet peeve, because any physicist should be able to tell you that this claim is one of those hilarious "people keep pretending this is true" when it has nothing to do with what a quantum leap actually is. In physics, a "quantum leap" is a synonym for atomic electron state changes. These don't take place as a continuous gradient change, they jump from one state to the next, releasing or absorbing ph…

I am both trained in physics and working on Project Quantum, and right now I am so annoyed by reading all the replies to the blog post on various forums going "quantum means tiny y'all played yourself". -_-

Re: A Quantum Leap for the Web

#86

Post by Manishearth »

Aldo_MX wrote: post #73
bzbarsky wrote: post #42

Earlier 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 :(

> Considering that Servo is an embeddable engine, why not keep the scope of Servo focused in building a standards-compliant engine?

So far, we are (as far as I know)! We try very hard to avoid nonstandard behavior, and if we can't avoid it, try to push for its inclusion in the standard. Given that there are no users that rely on Servo, we can even wait for the standard to be changed before implementing it.

We often try to implement the standard to the word, with code that closely matches up to the standard. This has helped find tons of bugs in the standard (or in the tests). Nonstandard behavior in components shared with Gecko are off in Servo mode.

But if Servo is to be a product we probably will have to change our stance here eventually.

Re: A Quantum Leap for the Web

#87

Post by mwcampbell »

zbraniecki wrote: post #46
Touche wrote: post #34

Earlier quoted context omitted.

Speaking for myself, I don't want "Servo components" in Firefox; I want Servo in Firefox. I want an engine as fast as the one they have shown of Servo as being; not pieces of it that make Firefox incrementally better; I want a browser that is miles ahead. That's always what I found interesting about Servo.

At the same time, you want a browser that keep working with the web at least on the same level as Firefox is right now. Servo is getting us 80% there, the remaining 20% of quirks, non-standardized behavior and web sites coded with only Chrome/Fx/IE in mind are going to be increasingly difficult to cover. On the other hand some pieces of servo are close to have "full" compatibility. That means that we can put them in…

It also wouldn't be good to have Servo in Firefox until unglamorous things like accessibility are implemented. There's a lot that goes into mature, production software that isn't there in a new research prototype. So incrementally introducing pieces of Servo into the production codebase is probably better.

Re: A Quantum Leap for the Web

#89

Post by tedmielczarek »

pcwalton wrote: post #31
dblohm7 wrote: post #26

Earlier quoted context omitted.

> That's not true. Servo is designed to be production-grade. I never said that it wasn't. I said that it wasn't going to be shipped as a production Mozilla product.

> 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

#90

Post by the8472 »

mccr8 wrote: post #82
the8472 wrote: post #72

Earlier quoted context omitted.

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

Writing a parallel GC surely is not "low-hanging fruit" by any reasonable measure. Java already has to deal with concurrency in their objects, and throughput is more of a concern for server-like workloads, so they are dealing with a different situation. In Firefox, most of our effort has focused on improving responsiveness and eliminating work (through things like compartmental GC). (Some GC sweeping is already done…

> and throughput is more of a concern for server-like workloads

Many java applications also have to worry about latency, not just throughput. Parallel collections cut down on pause times, too. Simply because they can get about the same work (in terms of CPU cycles) done in less wall time. I.e. parallelizing non-concurrent GC phases also improves responsiveness.

Post reply on HN