15 ms·

A Quantum Leap for the Web

495 points by Manishearth 10y ago

mnemonik 10y ago
Quantum wiki page with info on how to get involved: https://wiki.mozilla.org/Quantum https://wiki.mozilla.org/Quantum
deleted 10y ago
[deleted]
dherman 10y ago
[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 that effectively all of Firefox's users have at least two cores, and about half have at least 4. The more we fully utilize those cores, the smoother we should be able to make the whole web. Over the last year, all three communities have been laying groundwork to be able to land Rust components in Firefox and share components between Gecko and Servo, and now it looks like that's teed the Gecko team up to commit to making use of some big pieces of Servo in the coming year. Some of the initial builds of Firefox with Stylo that Bobby Holley has showed me look really amazing, and WebRender could be a game-changer. And the Servo project is just getting warmed up. ;) If you're interested in what they're up to next, check out Jack Moffitt's recent presentation from a browser developer workshop last month: https://www.youtube.com/watch?list=PL4sEzdAGvRgCYXot-o5cVKOobIXZI5iLF&v=UGl9VVIOo3E https://www.youtube.com/watch?list=PL4sEzdAGvRgCYXot-o5cVKOo...
- tomdale 10y ago
  I have to say, the work being done on Servo is really exciting—the first tectonic shift in browser engines to come along in years. pcwalton's talk about WebRender earlier this year[1] was one of those rare technical presentations that left my jaw on the floor. In particular, the insight that modern browsers are just AAA game engines with a security model, so they should be architected similarly, changed the way I think about browsers. That game developers and Mozilla are both so excited by Rust's ability to safely write parallel systems at scale makes a lot of sense. [1]: https://air.mozilla.org/bay-area-rust-meetup-february-2016/#@25m50s https://air.mozilla.org/bay-area-rust-meetup-february-2016/#... Previous HN discussion: https://news.ycombinator.com/item?id=11175258 https://news.ycombinator.com/item?id=11175258
- the8472 10y ago
  > 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 single thread while a java VM can munch churn through something like 1 gigabyte per second per core. In other words, from the outside it looks like a low-hanging fruit that has not been plucked.
  - johncolanduoni 10y ago
    That would be hard to do without writing a new javascript engine, which would expand Servo's current scope pretty dramatically. My guess would be that as long as there are big gains to be made that can be done without rewriting SpiderMonkey, the servo project would rather only tackle one massive project at a time :)
  - mccr8 10y ago
    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.
    - the8472 10y ago
      > 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.
  - pcwalton 10y ago
- armitron 10y ago
  It's telling that not one comment in this entire thread mentions security and exploitability, two areas where Firefox is not just terrible, but the worst choice amongst (Chrome, Safari, Firefox) (1) but also Edge and IE 11. Everyone is focusing on performance, as if that's the BIG issue these days. Talk about having your priorities screwed up. Reading your comment, and the linked post, I'm left with the impression that this will not change in the foreseeable future. Every exploit shop considers Spidermonkey a security clusterfuck yet it's still in use. Multiple processes do absolutely nothing for security unless combined with sandboxing ala-Chrome. Continuing to use C++ rather than fully embracing Rust (or something even better than Rust) also does nothing for security. Iteratively improving things on top of a Javascript engine that's a security disaster and a C++ core will not give us a secure browser, as one can not build castles on top of sand. At some point people need to realize that one has to scrap the pile of mud and start again, on solid foundations. Alas I feel that these lessons escape the Mozilla folks and thus their browser will remain low hanging fruit for adversaries. In an age where Nation States can MITM __the entire planet on demand__ [QUANTUM] and the FBI delivers Firefox 0day through TOR exit nodes, this blatant disregard for security should be entirely unacceptable. I don't really blame Mozilla, but those who use Firefox and give Mozilla their share in the browser market. If we don't demand better, we shall never have it. (1) http://cyber-itl.org/blog-1/2016/9/12/a-closer-look-at-the-osx-continuum http://cyber-itl.org/blog-1/2016/9/12/a-closer-look-at-the-o...
  - pcwalton 10y ago
    > Every exploit shop considers Spidermonkey to be a security clusterfuck yet it's still in use. Can you elaborate why SpiderMonkey is worse than Chakra, JavaScriptCore, and V8? SpiderMonkey has approximately the same security track record as all of them. I think you're conflating the lack of sandboxing and some mistaken security-related decisions in the Firefox chrome with some sort of intrinsic security problem in the JavaScript engine. > Multiple processes do absolutely nothing for security unless combined with sandboxing ala-Chrome. And sandboxing is being actively worked on right now. In fact, it's an utmost priority. Nobody is talking about doing Quantum instead of sandboxing. Rather, Quantum is being done alongside sandboxing. > Continuing to use C++ rather than fully embracing Rust (or something even better than Rust) also does nothing for security. I don't agree. Replacing C++ code with Rust code reduces the attack surface. The more of the browser you write in a memory safety language, the fewer opportunities for memory safety holes that attackers have. Do I want to shrink the trusted computing base as close to zero as possible? Absolutely! But that's a long-term journey, and I would love to see Servo components get some real-world production use along the way. > At some point people need to realize that one has to scrap the pile of mud and start again, on solid foundations. Alas I feel that these lessons escape the Mozilla folks and thus their browser will remain low hanging fruit for adversaries. There's only one browser vendor that is actively working on "scrapping the pile of mud and starting again", and it's the browser vendor you're complaining about. You claim that the lessons of security "escape" me, but I have been working day-in and day-out for years on a browser engine written from the ground up in a memory-safe language.
- xorcist 10y ago
  > all of Firefox's users have at least two cores, As an end user, it concerns me slightly that the visible change will be that Firefox pegs two cores instead of just one. An absolute explosion in Javascript usage on the web together, of low quality haphazardly put together at runtime, together with the convenience of tabs makes this a problem. Mozilla may do everything right but that doesn't necessarily help the end user. Is there anything I could do easily to remedy this, without bothering with white listing Javascript? And is there any activities at Mozilla concerning this, perhaps with identifying the most trivial cases of scripts spinning without doing useful work? Maybe pausing DOM changes for documents that aren't visible?
  - mdahlstrand 10y ago
    Disable javascript? Not that it's massively fun for you without javascript on the web, but it sounds like you have a very performance dependent workload on your computer. I don't think it's anything most people will have to worry about though, cpu scheduling is pretty good most of the time, and people's javascript suck less and less.
  - pcwalton 10y ago
    > Maybe pausing DOM changes for documents that aren't visible? We already throttle background tabs heavily in various ways.
- oldmanjay 10y ago
  I would personally not be so eager to disclaim such impressive credentials, but I suppose you have your reasons.
joshmarinacci 10y ago
It's about damn time!
mxuribe 10y ago
Looking forward to this!
mthoms 10y ago
I hope that low power usage remains a key priority. Surprisingly, I don't see any mention of it in this article.
- mnemonik 10y ago
  There is some discussion about power usage in this video by Jack Moffit: https://www.youtube.com/watch?list=PL4sEzdAGvRgCYXot-o5cVKOobIXZI5iLF&v=UGl9VVIOo3E https://www.youtube.com/watch?list=PL4sEzdAGvRgCYXot-o5cVKOo...
yalooze 10y ago
Does anyone know how this compares to the current implementations of competing browsers? ie. is Firefox still playing catch up in some respects or is this leaps ahead of the competition too?
- azakai 10y ago
  Currently no major browser has significant components implemented in a safe language like Rust. And while there are some efforts towards granular parallelism in existing major browsers, none really took a "start from scratch and get it right" approach like the Servo components that Quantum intends to adopt (and that's very noticeable in Servo perf). So on both of those aspects, the plan here is to go significantly further than any existing major browser.
- metajack 10y ago
  I think performance of the style systems in Blink and Firefox are similar. Since Servo's style system is linearly scalable, we expect most users to get a ~4x speed improvement on styling. Users's don't care specifically about style performance, though, but about things like interactivity. We think Servo's style system will improve those things, but don't have numbers for that on hand. To give a concrete example, it takes Firefox ~1.2 seconds to restyle the single page HTML5 spec with it's current non-parallel style system. Firefox with Stylo can do this in ~300ms. That is close to a full second off of initial page load.
  - gsnedders 10y ago
    How does WebKit's JITing style system compare? (As far as I'm aware, nobody else has anything like it, though it is still single-threaded as far as I'm aware.)
    - pcwalton 10y ago
      I would eventually like to look into a CSS JIT. But I would not like to just copy WebKit—I would like to look into treating CSS as a global DFA and compiling accordingly instead of looking at local optimizations only. As always, the problem with JITs, especially on the Web, that it's hard to beat the interpreter when you take compilation time into account, and most selectors you see in the wild only apply to a small number of nodes.
bobajeff 10y ago
This 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.
- larsberg 10y ago
  Project Quantum is an opportunity to ship some of the Servo components in Firefox and gain millions of users, real-world tests of the technology, and hopefully dramatically expand our contributor base. As we mention in a post to the Servo mailing list (https://groups.google.com/forum/#!topic/mozilla.dev.servo/3bH1KaqJq0s https://groups.google.com/forum/#!topic/mozilla.dev.servo/3b... ), Servo has a lot coming in 2017 unrelated to Project Quantum or Firefox.
  - Touche 10y ago
    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.
    - zbraniecki 10y ago
      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 Firefox already. The result is that web coverage alignment between Servo and Firefox increases which is great for Servo, and the performance and safety between them improves as well which will benefit Firefox.
      - 10y ago
mtgx 10y ago
> 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/13201832/apple-sued-ios-browser-limits http://www.recode.net/2016/10/7/13201832/apple-sued-ios-brow...
- markdog12 10y ago
  I did a sad LOL at that line
- tedmielczarek 10y ago
  I've had a Gecko port stood up and running on iPhone hardware several times in the past 6 years but we've never sorted out a real path to shipping. The most recent incarnation felt a lot nicer than Safari with our async pan/zoom architecture. Maybe I should just get Servo running and we can ship it as a tech demo. :-P
  - larsberg 10y ago
    I'll do the CI work to keep it building :-)
criddell 10y ago
Heh. It's interesting to me that in the vernacular a quantum leap is a large change while in physics it's a very quick, extremely tiny event.
- Manishearth 10y ago
  No, in both it's a discrete change. It just happens to be that in physics most discrete changes are at a small scale.
- dherman 10y ago
  Maybe it's a clue that Mozillians are secretly building a handlink: http://quantumleap.wikia.com/wiki/Handlink http://quantumleap.wikia.com/wiki/Handlink
- krastanov 10y ago
  No! This meme is just wrong (and it does grind my gears to an unreasonable amount as a physicist). In physics quantum means discrete, it does not mean small. Hence the idiom "quantum leap" used as "a discontinuous abrupt jump in quality" is perfectly in sync with the way physicists use the phrase.
  - deleted 10y ago
    [deleted]
  - criddell 10y ago
    I'm not saying it means small, just that quantum leaps are nanoscale. And also, the state after the leap isn't better or worse than the state before, just different.
    - krastanov 10y ago
      I still disagree. Quantum does not imply nanoscale - we are building bigger and bigger systems that exhibit inherently quantum behavior (for instance superconducting cavities used in quantum computing research are centimeter scale). Moreover, the jump is not necessarily in a spatial variable - it can be a very big jump in energy levels for instance, which is the case with laser emissions. Sure, a (big or small) discrete jump does not necessarily imply a jump to something better, but that has little to do with my complaint about the meme that "quantum implies small".
deleted 10y ago
[deleted]
aantix 10y ago
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.
- mgalka 10y ago
  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.
  - AceJohnny2 10y ago
    > Yahoo would probably make a great case study in corporate culture gone wrong. "would probably"? :)
  - fuck_google 10y ago
    Ex-googler as the CEO didn't seem to help either.
- anigbrowl 10y ago
  There are so many major brand websites that are so awful that I want to grab anyone who admits to working there and yell 'have you tried using your own damn product lately because it sucks' but I'd rather not be returned to prison for my unique form of UI feedback.
  - fuck_google 10y ago
    Using Google services led you to prison?
TekMol 10y ago
we’ll be rolling out the first stage of Electrolysis to 100% of Firefox desktop users over the next few months. From my experiments with it, this still does not fix the problem that the javascript in all windows shares one core. A script running in one browser window still slows down the other windows. A problem that Chrome has solved years ago. So I think this is not really a leap for the web. Just FireFox catching up a bit. FireFox is my main browser. The way I deal with it is that I start multiple instances as different users. So they run inside their own process. This way I can have a resource hungry page open in one window (For example a dashboard with realtime data visualization) and still work smoothly in another.
- metajack 10y ago
  Parts of Quantum are addressing this, and also Electrolysis will also probably grow to fix this as well. You can already turn on multiple content processes in Firefox to get Chrome-like behavior (at the cost of some rough edges; there's a reason it's not currently the default). I think the setting is dom.ipc.process-count in about:config. I have mine set at 10.
  - TekMol 10y ago
    Yes, I heard about it. For now, I disabled Electrolysis completely again, because I had pages freeze sometimes when I had it on. Maybe because it is incompatible with some plugin I use. My current solution to tun multiple instances as different users works best for me so far.
- bholley 10y ago
  > So I think this is not really a leap for the web. Just FireFox catching up a bit. To be clear, Project Quantum is the next phase of architecture, post-Electrolysis. We're also simultaneously working on multiple content processes (which is how Chrome often avoids inter-window jank), but not under the Quantum umbrella. We think we can do better though, which is where Quantum comes in. The Quantum DOM project is designed to solve exactly the problem you're describing, while using fewer resources and scaling to more tabs. Stay tuned!
pg_is_a_butt 10y ago
how about less about what you're going to do, and more actually doing it. you're all idiots.
bandrami 10y ago
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.
- justusthane 10y ago
  This was refuted by a physicist elsewhere in this thread: https://news.ycombinator.com/item?id=12807384 https://news.ycombinator.com/item?id=12807384)
- white-flame 10y ago
  It's a barrier that can't be smoothly crossed, so it implies revolution over evolution. I think you're accidentally mixing in some Planck with your quantum.
- TheRealPomax 10y ago
  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 photons as they do so: the changes are quantized, and any change from one state to another termed a quantum leap. And it really is "any change": they're all quantum leaps. There is also no stipulation on direction, state changes go both up and down. So while there certainly is a lower bound to the value that we will find in the set of all possible quantum leaps in atomic physics (because you can't go "half distances", the whole point of quanta is that it's all or nothing). the idea that a quantum leap is "one value" is patent nonsense; different state transitions have different values, and can be anywhere between tiny and huge jumps, and can release massively energetic photons in the process. And if the term has been given a new meaning in everyday common language, then cool. That's how language works. It doesn't need to be correct with respect to its origin, people just need to all agree on what the terms used mean. In every day language, understanding that "a quantum leap" means "a fundamental change in how we do things" (which is implied always a big deal, even if the change itself is small) demonstrates a basic understanding of conversational English. So that's cool too.
runeks 10y ago
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.
- bzbarsky 10y ago
  Servo is a project to build a new rendering engine in Rust, taking advantage of its security properties and ease of doing parallelism to do things that other rendering engines are not willing or are not able to do in terms of parallel execution. Quantum is a project to significantly change some of the core parts of Gecko. Some of this will involve sharing some code with Servo, some will involve changing the Gecko code directly. There is overlap between the two in the form of some shared components, which may be causing your confusion.
- Manishearth 10y 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).
ifhs 10y ago
Sorry but posting this on medium is a quantum leap backwards. That too from Mozilla.
k26dr 10y ago
Doesn't Chrome/Chromium already run as multiple processes?
- Roboprog 10y ago
  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?
  - the8472 10y ago
    There is this concept called "threads" which can be found in most operating systems.
    - Roboprog 10y ago
      Process, thread, task, whatever. (I so remember the first time I was reading about threads in OS/2 and Novell back in 1989 or 90 - no risk not worth taking to squeeze a little bit more out of 10 MHz CPUs with OS's with crummy process management, I guess)
  - Manishearth 10y ago
    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.
andrewstuart 10y ago
I wish I could see how much processing power/memory was being taken by each tab.
c-smile 10y ago
"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 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. [1] https://gist.github.com/paulirish/5d52fb081b3570c81e3a https://gist.github.com/paulirish/5d52fb081b3570c81e3a
- pcwalton 10y ago
  > 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 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.
TeeWEE 10y ago
You can make a super fast web browser, but that doesnt solve the fundamental issue: The web is not designed for performant applications. Resources loading, javascript, rendering... Solve that first before you build a fast engine... Off course a fast engine is good. But dont forget the root problems with the web.
- amelius 10y ago
  Yes. The article speaks of "zero latency", but that is simply not achievable with a network connection that has latency. My guess is that in current browsers, on average 90% of the latency is in the network (as opposed to rendering). So even if the render step was perfect, you would only get a measly 10% performance gain.

495 points by Manishearth 10y ago

mnemonik 10y ago

Quantum wiki page with info on how to get involved: https://wiki.mozilla.org/Quantum https://wiki.mozilla.org/Quantum

deleted 10y ago

[deleted]

dherman 10y ago

[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 that effectively all of Firefox's users have at least two cores, and about half have at least 4. The more we fully utilize those cores, the smoother we should be able to make the whole web. Over the last year, all three communities have been laying groundwork to be able to land Rust components in Firefox and share components between Gecko and Servo, and now it looks like that's teed the Gecko team up to commit to making use of some big pieces of Servo in the coming year. Some of the initial builds of Firefox with Stylo that Bobby Holley has showed me look really amazing, and WebRender could be a game-changer. And the Servo project is just getting warmed up. ;) If you're interested in what they're up to next, check out Jack Moffitt's recent presentation from a browser developer workshop last month: https://www.youtube.com/watch?list=PL4sEzdAGvRgCYXot-o5cVKOobIXZI5iLF&v=UGl9VVIOo3E https://www.youtube.com/watch?list=PL4sEzdAGvRgCYXot-o5cVKOo...

tomdale 10y ago
I have to say, the work being done on Servo is really exciting—the first tectonic shift in browser engines to come along in years. pcwalton's talk about WebRender earlier this year[1] was one of those rare technical presentations that left my jaw on the floor. In particular, the insight that modern browsers are just AAA game engines with a security model, so they should be architected similarly, changed the way I think about browsers. That game developers and Mozilla are both so excited by Rust's ability to safely write parallel systems at scale makes a lot of sense. [1]: https://air.mozilla.org/bay-area-rust-meetup-february-2016/#@25m50s https://air.mozilla.org/bay-area-rust-meetup-february-2016/#... Previous HN discussion: https://news.ycombinator.com/item?id=11175258 https://news.ycombinator.com/item?id=11175258
the8472 10y ago
> 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 single thread while a java VM can munch churn through something like 1 gigabyte per second per core. In other words, from the outside it looks like a low-hanging fruit that has not been plucked.
- johncolanduoni 10y ago
  That would be hard to do without writing a new javascript engine, which would expand Servo's current scope pretty dramatically. My guess would be that as long as there are big gains to be made that can be done without rewriting SpiderMonkey, the servo project would rather only tackle one massive project at a time :)
- mccr8 10y ago
  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.
  - the8472 10y ago
    > 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.
- pcwalton 10y ago
armitron 10y ago
It's telling that not one comment in this entire thread mentions security and exploitability, two areas where Firefox is not just terrible, but the worst choice amongst (Chrome, Safari, Firefox) (1) but also Edge and IE 11. Everyone is focusing on performance, as if that's the BIG issue these days. Talk about having your priorities screwed up. Reading your comment, and the linked post, I'm left with the impression that this will not change in the foreseeable future. Every exploit shop considers Spidermonkey a security clusterfuck yet it's still in use. Multiple processes do absolutely nothing for security unless combined with sandboxing ala-Chrome. Continuing to use C++ rather than fully embracing Rust (or something even better than Rust) also does nothing for security. Iteratively improving things on top of a Javascript engine that's a security disaster and a C++ core will not give us a secure browser, as one can not build castles on top of sand. At some point people need to realize that one has to scrap the pile of mud and start again, on solid foundations. Alas I feel that these lessons escape the Mozilla folks and thus their browser will remain low hanging fruit for adversaries. In an age where Nation States can MITM __the entire planet on demand__ [QUANTUM] and the FBI delivers Firefox 0day through TOR exit nodes, this blatant disregard for security should be entirely unacceptable. I don't really blame Mozilla, but those who use Firefox and give Mozilla their share in the browser market. If we don't demand better, we shall never have it. (1) http://cyber-itl.org/blog-1/2016/9/12/a-closer-look-at-the-osx-continuum http://cyber-itl.org/blog-1/2016/9/12/a-closer-look-at-the-o...
- pcwalton 10y ago
  > Every exploit shop considers Spidermonkey to be a security clusterfuck yet it's still in use. Can you elaborate why SpiderMonkey is worse than Chakra, JavaScriptCore, and V8? SpiderMonkey has approximately the same security track record as all of them. I think you're conflating the lack of sandboxing and some mistaken security-related decisions in the Firefox chrome with some sort of intrinsic security problem in the JavaScript engine. > Multiple processes do absolutely nothing for security unless combined with sandboxing ala-Chrome. And sandboxing is being actively worked on right now. In fact, it's an utmost priority. Nobody is talking about doing Quantum instead of sandboxing. Rather, Quantum is being done alongside sandboxing. > Continuing to use C++ rather than fully embracing Rust (or something even better than Rust) also does nothing for security. I don't agree. Replacing C++ code with Rust code reduces the attack surface. The more of the browser you write in a memory safety language, the fewer opportunities for memory safety holes that attackers have. Do I want to shrink the trusted computing base as close to zero as possible? Absolutely! But that's a long-term journey, and I would love to see Servo components get some real-world production use along the way. > At some point people need to realize that one has to scrap the pile of mud and start again, on solid foundations. Alas I feel that these lessons escape the Mozilla folks and thus their browser will remain low hanging fruit for adversaries. There's only one browser vendor that is actively working on "scrapping the pile of mud and starting again", and it's the browser vendor you're complaining about. You claim that the lessons of security "escape" me, but I have been working day-in and day-out for years on a browser engine written from the ground up in a memory-safe language.
xorcist 10y ago
> all of Firefox's users have at least two cores, As an end user, it concerns me slightly that the visible change will be that Firefox pegs two cores instead of just one. An absolute explosion in Javascript usage on the web together, of low quality haphazardly put together at runtime, together with the convenience of tabs makes this a problem. Mozilla may do everything right but that doesn't necessarily help the end user. Is there anything I could do easily to remedy this, without bothering with white listing Javascript? And is there any activities at Mozilla concerning this, perhaps with identifying the most trivial cases of scripts spinning without doing useful work? Maybe pausing DOM changes for documents that aren't visible?
- mdahlstrand 10y ago
  Disable javascript? Not that it's massively fun for you without javascript on the web, but it sounds like you have a very performance dependent workload on your computer. I don't think it's anything most people will have to worry about though, cpu scheduling is pretty good most of the time, and people's javascript suck less and less.
- pcwalton 10y ago
  > Maybe pausing DOM changes for documents that aren't visible? We already throttle background tabs heavily in various ways.
oldmanjay 10y ago
I would personally not be so eager to disclaim such impressive credentials, but I suppose you have your reasons.

joshmarinacci 10y ago

It's about damn time!

mxuribe 10y ago

Looking forward to this!

mthoms 10y ago

I hope that low power usage remains a key priority. Surprisingly, I don't see any mention of it in this article.

mnemonik 10y ago
There is some discussion about power usage in this video by Jack Moffit: https://www.youtube.com/watch?list=PL4sEzdAGvRgCYXot-o5cVKOobIXZI5iLF&v=UGl9VVIOo3E https://www.youtube.com/watch?list=PL4sEzdAGvRgCYXot-o5cVKOo...

yalooze 10y ago

Does anyone know how this compares to the current implementations of competing browsers? ie. is Firefox still playing catch up in some respects or is this leaps ahead of the competition too?

azakai 10y ago
Currently no major browser has significant components implemented in a safe language like Rust. And while there are some efforts towards granular parallelism in existing major browsers, none really took a "start from scratch and get it right" approach like the Servo components that Quantum intends to adopt (and that's very noticeable in Servo perf). So on both of those aspects, the plan here is to go significantly further than any existing major browser.
metajack 10y ago
I think performance of the style systems in Blink and Firefox are similar. Since Servo's style system is linearly scalable, we expect most users to get a ~4x speed improvement on styling. Users's don't care specifically about style performance, though, but about things like interactivity. We think Servo's style system will improve those things, but don't have numbers for that on hand. To give a concrete example, it takes Firefox ~1.2 seconds to restyle the single page HTML5 spec with it's current non-parallel style system. Firefox with Stylo can do this in ~300ms. That is close to a full second off of initial page load.
- gsnedders 10y ago
  How does WebKit's JITing style system compare? (As far as I'm aware, nobody else has anything like it, though it is still single-threaded as far as I'm aware.)
  - pcwalton 10y ago
    I would eventually like to look into a CSS JIT. But I would not like to just copy WebKit—I would like to look into treating CSS as a global DFA and compiling accordingly instead of looking at local optimizations only. As always, the problem with JITs, especially on the Web, that it's hard to beat the interpreter when you take compilation time into account, and most selectors you see in the wild only apply to a small number of nodes.

bobajeff 10y ago

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

larsberg 10y ago
Project Quantum is an opportunity to ship some of the Servo components in Firefox and gain millions of users, real-world tests of the technology, and hopefully dramatically expand our contributor base. As we mention in a post to the Servo mailing list (https://groups.google.com/forum/#!topic/mozilla.dev.servo/3bH1KaqJq0s https://groups.google.com/forum/#!topic/mozilla.dev.servo/3b... ), Servo has a lot coming in 2017 unrelated to Project Quantum or Firefox.
- Touche 10y ago
  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.
  - zbraniecki 10y ago
    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 Firefox already. The result is that web coverage alignment between Servo and Firefox increases which is great for Servo, and the performance and safety between them improves as well which will benefit Firefox.
    - 10y ago

mtgx 10y ago

> 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/13201832/apple-sued-ios-browser-limits http://www.recode.net/2016/10/7/13201832/apple-sued-ios-brow...

markdog12 10y ago
I did a sad LOL at that line
tedmielczarek 10y ago
I've had a Gecko port stood up and running on iPhone hardware several times in the past 6 years but we've never sorted out a real path to shipping. The most recent incarnation felt a lot nicer than Safari with our async pan/zoom architecture. Maybe I should just get Servo running and we can ship it as a tech demo. :-P
- larsberg 10y ago
  I'll do the CI work to keep it building :-)

criddell 10y ago

Heh. It's interesting to me that in the vernacular a quantum leap is a large change while in physics it's a very quick, extremely tiny event.

Manishearth 10y ago
No, in both it's a discrete change. It just happens to be that in physics most discrete changes are at a small scale.
dherman 10y ago
Maybe it's a clue that Mozillians are secretly building a handlink: http://quantumleap.wikia.com/wiki/Handlink http://quantumleap.wikia.com/wiki/Handlink
krastanov 10y ago
No! This meme is just wrong (and it does grind my gears to an unreasonable amount as a physicist). In physics quantum means discrete, it does not mean small. Hence the idiom "quantum leap" used as "a discontinuous abrupt jump in quality" is perfectly in sync with the way physicists use the phrase.
- deleted 10y ago
  [deleted]
- criddell 10y ago
  I'm not saying it means small, just that quantum leaps are nanoscale. And also, the state after the leap isn't better or worse than the state before, just different.
  - krastanov 10y ago
    I still disagree. Quantum does not imply nanoscale - we are building bigger and bigger systems that exhibit inherently quantum behavior (for instance superconducting cavities used in quantum computing research are centimeter scale). Moreover, the jump is not necessarily in a spatial variable - it can be a very big jump in energy levels for instance, which is the case with laser emissions. Sure, a (big or small) discrete jump does not necessarily imply a jump to something better, but that has little to do with my complaint about the meme that "quantum implies small".

deleted 10y ago

[deleted]

aantix 10y ago

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.

mgalka 10y ago
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.
- AceJohnny2 10y ago
  > Yahoo would probably make a great case study in corporate culture gone wrong. "would probably"? :)
- fuck_google 10y ago
  Ex-googler as the CEO didn't seem to help either.
anigbrowl 10y ago
There are so many major brand websites that are so awful that I want to grab anyone who admits to working there and yell 'have you tried using your own damn product lately because it sucks' but I'd rather not be returned to prison for my unique form of UI feedback.
- fuck_google 10y ago
  Using Google services led you to prison?

TekMol 10y ago

we’ll be rolling out the first stage of Electrolysis to 100% of Firefox desktop users over the next few months. From my experiments with it, this still does not fix the problem that the javascript in all windows shares one core. A script running in one browser window still slows down the other windows. A problem that Chrome has solved years ago. So I think this is not really a leap for the web. Just FireFox catching up a bit. FireFox is my main browser. The way I deal with it is that I start multiple instances as different users. So they run inside their own process. This way I can have a resource hungry page open in one window (For example a dashboard with realtime data visualization) and still work smoothly in another.

metajack 10y ago
Parts of Quantum are addressing this, and also Electrolysis will also probably grow to fix this as well. You can already turn on multiple content processes in Firefox to get Chrome-like behavior (at the cost of some rough edges; there's a reason it's not currently the default). I think the setting is dom.ipc.process-count in about:config. I have mine set at 10.
- TekMol 10y ago
  Yes, I heard about it. For now, I disabled Electrolysis completely again, because I had pages freeze sometimes when I had it on. Maybe because it is incompatible with some plugin I use. My current solution to tun multiple instances as different users works best for me so far.
bholley 10y ago
> So I think this is not really a leap for the web. Just FireFox catching up a bit. To be clear, Project Quantum is the next phase of architecture, post-Electrolysis. We're also simultaneously working on multiple content processes (which is how Chrome often avoids inter-window jank), but not under the Quantum umbrella. We think we can do better though, which is where Quantum comes in. The Quantum DOM project is designed to solve exactly the problem you're describing, while using fewer resources and scaling to more tabs. Stay tuned!

pg_is_a_butt 10y ago

how about less about what you're going to do, and more actually doing it. you're all idiots.

bandrami 10y ago

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.

justusthane 10y ago
This was refuted by a physicist elsewhere in this thread: https://news.ycombinator.com/item?id=12807384 https://news.ycombinator.com/item?id=12807384)
white-flame 10y ago
It's a barrier that can't be smoothly crossed, so it implies revolution over evolution. I think you're accidentally mixing in some Planck with your quantum.
TheRealPomax 10y ago
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 photons as they do so: the changes are quantized, and any change from one state to another termed a quantum leap. And it really is "any change": they're all quantum leaps. There is also no stipulation on direction, state changes go both up and down. So while there certainly is a lower bound to the value that we will find in the set of all possible quantum leaps in atomic physics (because you can't go "half distances", the whole point of quanta is that it's all or nothing). the idea that a quantum leap is "one value" is patent nonsense; different state transitions have different values, and can be anywhere between tiny and huge jumps, and can release massively energetic photons in the process. And if the term has been given a new meaning in everyday common language, then cool. That's how language works. It doesn't need to be correct with respect to its origin, people just need to all agree on what the terms used mean. In every day language, understanding that "a quantum leap" means "a fundamental change in how we do things" (which is implied always a big deal, even if the change itself is small) demonstrates a basic understanding of conversational English. So that's cool too.

runeks 10y ago

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.

bzbarsky 10y ago
Servo is a project to build a new rendering engine in Rust, taking advantage of its security properties and ease of doing parallelism to do things that other rendering engines are not willing or are not able to do in terms of parallel execution. Quantum is a project to significantly change some of the core parts of Gecko. Some of this will involve sharing some code with Servo, some will involve changing the Gecko code directly. There is overlap between the two in the form of some shared components, which may be causing your confusion.
Manishearth 10y 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).

ifhs 10y ago

Sorry but posting this on medium is a quantum leap backwards. That too from Mozilla.

k26dr 10y ago

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

Roboprog 10y ago
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?
- the8472 10y ago
  There is this concept called "threads" which can be found in most operating systems.
  - Roboprog 10y ago
    Process, thread, task, whatever. (I so remember the first time I was reading about threads in OS/2 and Novell back in 1989 or 90 - no risk not worth taking to squeeze a little bit more out of 10 MHz CPUs with OS's with crummy process management, I guess)
- Manishearth 10y ago
  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.

andrewstuart 10y ago

I wish I could see how much processing power/memory was being taken by each tab.

c-smile 10y ago

"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 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. [1] https://gist.github.com/paulirish/5d52fb081b3570c81e3a https://gist.github.com/paulirish/5d52fb081b3570c81e3a

pcwalton 10y ago
> 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 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.

TeeWEE 10y ago

You can make a super fast web browser, but that doesnt solve the fundamental issue: The web is not designed for performant applications. Resources loading, javascript, rendering... Solve that first before you build a fast engine... Off course a fast engine is good. But dont forget the root problems with the web.

amelius 10y ago
Yes. The article speaks of "zero latency", but that is simply not achievable with a network connection that has latency. My guess is that in current browsers, on average 90% of the latency is in the network (as opposed to rendering). So even if the render step was perfect, you would only get a measly 10% performance gain.