How Stylo Brought Rust and Servo to Firefox(bholley.net) |
How Stylo Brought Rust and Servo to Firefox(bholley.net) |
This time, their "multiple-moonshot effort" is paying off big-time because they're doing it incrementally. Kudos!
[1] https://www.joelonsoftware.com/2000/04/06/things-you-should-...
[2] https://www.joelonsoftware.com/2000/11/20/netscape-goes-bonk...
One is that rewriting from scratch is going to give you a worse result than incremental change from a technical point of view (the « absolutely no reason to believe that you are going to do a better job than you did the first time » bit).
The second is that independent of the technical merits, rewriting from scratch will be a bad commercial decision (the « throwing away your market leadership » bit).
We now know much more about how this turned out for his chosen example, and I think it's clear he was entirely wrong about the first claim (which he spends most of his time discussing). Gecko was a great technical success, and the cross-platform XUL stuff he complains about turned out to have many advantages (supporting plenty of innovation in addons which I don't think we'd have seen otherwise).
It's less clear whether he's right about the second: certainly Netscape did cede the field to IE for several years, but maybe that would have happened anyway: Netscape 4 wasn't much of a platform to build on. I think mozilla.org considered as a business has done better than most people would have expected in 2000.
One of the big issues with software engineering advice is that it is really hard to find apples-to-apples comparisons for outcomes.
The promise of a rewrite institutionalized accumulating technical debt. When it comes time to do the rewrite, everyone starts out on the wrong foot. The big rewrite is a lot like New Years resolutions. They don’t stick, they cost money and time, create negative reinforcement and sometimes people get hurt.
Refactoring institutionalizes continuous improvement, thinking about code quality, and yet discourages perfectionism because you can always fix it later when you have more info. My theory is that people good at refactoring can handle a rewrite well. Maybe are the only people that can handle a rewrite well. But if you can refactor like that you don’t need a rewrite (or rather, you’ve already done it and nobody noticed).
That is, some of my projects (personal & professional) have benefited enormously from designating the old version as a “prototype”, creating a “new” project with slightly different architectural decisions based on the deficiencies of the old version, copying most of the code from the old version to the new, and filling in the details.
https://github.com/servo/servo/wiki/Roadmap/_compare/47f490b...
As someone who was involved with Servo during that time period, I was disappointed at the time that it was quite obviously not going to happen. However, looking at what has happened since then, the change of focus towards Firefox integration was definitely a good move.
Chrome on the other hand is not stagnant, far from it. And Google is not letting Chrome stagnate.
Never mind that Google is using their marketing muscle to push Chrome every chance they get.
Just try downloading some shareware on Windows, and you are bound to get Chrome along for the ride. Hell, even Adobe offers Chrome as a Flash bundle even though Google is using Chrome to effectively kill Flash...
One of the origins mentioned is that Graydon thought that rusts (a kind of mushroom) were pretty cool (they are! they have a super complex lifecycle and it's pretty interesting).
Another is that Rust is actually not something with new concepts in it, everything in Rust is a very well established concept from earlier PL research, Rust just packages them nicely.
This is the most impressive, and useful aspect of all the recent work in Firefox. Rust is an amazing language. It really brings something new to the table with its borrow checker.
The fact that rust was created as part of a greater effort to work on a web browser is amazing.
This was a pretty smart move by the Rust team, and this gave them a rock solid platform to go cross-platform. In words of Newton, "If I have seen further it is by standing on the shoulders of giants". Kudos team Rust, and let's hope they eat C++'s lunch soon.
Apple "just uses LLVM" in the same way Apple "just uses Webkit".
Apple hired Chris Lattner back in 2005, just as he completed his PhD. At the time, LLVM could just barely compile Qt4[0] (the result didn't quite actually work yet) and was still hosted on CVS.
Lattner had to make LLVM production-ready (rather than a research project), add a bunch of major features, start a C/C++/ObjC frontend (Clang) and create a team of LLVM developers in the company.
Apple shipped their first bits of LLVM-based tooling in Leopard in 2007.
[0] https://web.archive.org/web/20111004073001/http://lists.trol...
For servo we've had long periods of time where no two employees are in the same office (it helps that most folks are remote).
In both teams we found it impossible to pick meeting times that work for everyone so we instead scheduled two sessions for the recurring meetings, and you can show up for one of them (the team lead / etc are usually at both so they're scheduled such that it is possible for them to attend both). Though for Servo we eventually stopped the meeting since we're pretty good at async communication through all the other channels and the meeting wasn't very useful anymore.
Also, to clarify, while that was the initial team, shortly after getting Wikipedia working the team grew with folks from the Servo and Gecko teams. Eventually we had folks living in the US, Paris, Spain, Australia, Japan, Taiwan, and Turkey working on it. As well as volunteer contributors from all over the place.
That said, why does it perform slower than Chrome on most benchmarks? Is it due to the Chrome team doing much more grunt work regarding parallelism and asynchronous I/O? Or are there still features in the current Firefox build that still call the original engine?
Does Rust have a runtime penalty as Golang does?
Which benchmarks are you talking about? It depends on what those benchmarks measure.
For example, a lot of the Quantum work was in user-percieved UI latency; unless the benchmark is measuring that, and I imagine that's a hard thing to measure, it's not going to show up.
> Does Rust have a runtime penalty as Golang does?
Rust has the same amount of runtime as C does: very very little. https://github.com/rust-lang/rust/blob/master/src/libstd/rt....
sys::stack_overflow::init();
I'm embarrassed to say that I just blindly trusted a couple of websites' claims that they ran benchmarks, without verifying they're even industry-standard. The articles were on Mashable and AppleInsider.
Mashable tested webpage load times, which only one dimension of many to optimize for. AppleInsider looked at speed, CPU usage, and memory consumption.
And since we are here, the prompt/dialog windows in FF are still not native looking too. These are my two major complaints :)
This is more generally known as Constant Flawless Vigilance: https://capability.party/memes/2017/09/11/constant-flawless-...
Is parallel layout something which can only be done through a full rewrite, hence with Servo, and bringing Servo up to full web compatibility, or can this be handled through the Project Quantum process, of hiving off components from Servo into Firefox?
Now, once stylo and webrender are in play, ideally layout can just fit in between. All the interfacing already exists from Servo.
However, there are a lot more things in Firefox that talk to layout. This would need work, more work than Stylo.
But this isn't the major issue. The major issue is that Servo's layout has a lot of missing pieces, a lot more than was the case with its style system. It's hard to incrementally replace layout the way webrender did with rendering (fall back when you can't render, render to texture, include it).
So it's doable, but a lot more work.
That said, we are absolutely going to explore opportunities for more Rust/Servo in layout, so we just need to find the right strategy. One incremental step I'm interested in exploring is to rewrite Gecko's frame constructor in Rust using the servo model, but have it continue to generate frames in the Gecko C++ format. This would give us rayon-driven parallelism in frame construction (which is a big performance bottleneck), while being a lot more tractable than swapping out all of layout at once. Another thing to explore would be borrowing Servo's tech for certain subtypes of layout (i.e. block reflow) and shipping it incrementally.
Each of these may or may not share code with Servo proper, depending on the tradeoffs. But Servo has a lot of neat innovation in that part of the pipeline (like bottom-up frame construction and parallel reflow) that I'm very interested in integrating into Firefox somehow.
We're going to meet in Austin in a few weeks and discuss this. Stay tuned!
I updated my developer version yesterday and it was as if Firefox - already ludicrously fast compared to before - turned on the turbo booster.
Obviously, I'm not complaining ;)
Of course it could be any incremental improvement instead of some big named feature.
Does anyone know if this is being worked on? Should I submit a bug report?
The medium-term effort to revamp the graphics stack is WebRender. Note that, like Stylo, WebRender is not just meant to achieve parity with other browsers. It's a different architecture entirely that is more similar to what games do than what current browsers do.
Are those things being measured at all in FF? It may be that the tradeoff is worth it (and I have no doubt it can be done better than the median compositing WM on linux), but it would be good to have that data.
On the other hand, it may be moot if Wayland does end up taking over from X.
Ideal register allocation is NP-complete, so a compiler can't get it right every single time.
I'm not sure how good in practice modern compilers are at this, but would be curious to know if there's some asm writers who can actually consistently outperform them.
This needs to be emphasized more
What also is interesting for me to realise, though, is that a lot of this was happening at the same time as Mozilla was largely focused on Firefox OS, and receiving a lot of flak for that.
It's a shame that Firefox OS failed, but it was clear that they had to try many different things to remain relevant, and it's excellent to see that one of those is very likely to pay off. Even though Rust might've been dismissed for the same reasons Firefox OS was.
And then there's the disappearing dev tools - that's fun.
EDIT: I hope that there is something weird with my systems. But I fear that the rush to push this out might have been a little hasty.
EDIT EDIT Apart from the crashes the new FF has been nice. I've been able to largely stop using chromium for dev work - so not all is bad.
It's definitely something weird to do with your systems, meaning it's a real bug that you are experiencing, and I am not.
So please share crash reports, and file bug reports. Different hardware/software quirks may reveal bugs in Firefox/Linux/drivers/window managers/anything. By submitting a bug report for Firefox, you may be able to help find a video driver bug, etc.
Yet more propaganda. I’ve been part of the cracking and demo scene since my early childhood. If you didn’t code in assembler you might as well not have taken part in it at all, because small fast code was everything. None of us ever had an issue with register allocation, nor do we face such issues today. Not 30+ years ago, not now.
It would be great to create the html/css/javascript stack from scratch, or at least make a non-backwards-compatible version that is simpler and can perform better. HTML5 showed us that can work.
The whole Mozilla strategy of corroding Firefox piece by piece is actually very professional. Big backwards-incompatible transitions in technology almost always fail.
FWIW this is usually due to folks doing performance work in only one browser or not really testing well and slapping that label on after the fact.
Or stuff like Hangouts and Allo where they use nonstandard features.
The major things Firefox doesn't support that Chrome does are U2F (it does support it now, but flipped off, will flip on soon I think) and web components (support should be available next year I guess; this kinda stalled because of lots of spec churn and Google implementing an earlier incompatible spec early or something.)
Edit: I don't intend for this to sound like I'm complaining, just interested.
https://wiki.mozilla.org/Oxidation#Rust_components_in_Firefo...
Completed:
MP4 metadata parser (Firefox 48)
Replace uconv with encoding-rs (Firefox 56)
U2F HID backend (Firefox 57)
URL parser
WebM demuxer
WebRender (from Servo)
Audio remoting for Linux
SDP parsing in WebRTC (aiming for Firefox 59)
Linebreaking with xi-unicode
Optimizing WebVM compiler backend: cretonneI would find frequent cases where my system would stall for 10-20s (could not caps lock toggle, pointer stopped moving). I almost always have just Chrome and gnome-terminal open (Ubuntu 16.04). I had attributed it to either a hardware or BIOS/firmware defect.
Now, after switching to Firefox I have gone a week without seeing those stalls.
YMMV -- I never bothered to investigate, it could be something as simple as slightly-less-memory-consumption from FF, or still a hardware defect that FF doesn't happen to trigger.
If that ever happens again, you can run "free" on the terminal to see whether this is the case.
That said, even if the poster is correct, it isn't necessarily wrong either. AFAICT, nothing stops JS on a page from allocating that much memory, and "leaking" it (e.g., holding on to the JS object, maybe accidentally in a giant list, and not making use of it). It isn't the browser's fault if JS is actually "using" that much RAM.
To put it another way, I find it hard to justify developing Rust just for a web browser. But if you consider it from the perspective of a foundation developing tools for the developer community as a whole, it makes much more sense.
These projects were valuable to Apple and Microsoft for a variety of reasons:
* promoting their IDE: XCode builds faster, and has better error messages. You can use any .NET language with Visual Studio in the same project.
* promoting their platform: Objective-C and Cocoa let you create fast GUI apps in a standard way, and we don't need GCC anymore. .NET provides a useful feature-complete standard library over a variety of languages.
To contrast, Rust was made with the intention of simply making a better systems language. Rust doesn't have a standard library or environment tied to a specific OS or proprietary dependencies. Rust itself doesn't promote Windows, OS X, ASP.NET, Cocoa, IOS, Android, etc. That is what makes it seem much less likely that rust would be created by a corporation.
"just for", our browsers are already very complex.
The browser is responsible for sandboxing and in effect taming the wild web.. and the web is not looking to become less wild :)
in the future browsers will have to prioritize CPU time between tabs seeking to mine bitcoin, crazy ad schemes, and battery power.
In terms of security, browser bugs scares me a lot more than some privilege escalation bug in the kernel. Because they can quickly be deployed widely.
Obviously, commercial organisations have a long track record of developing and supporting programming languages.
Calling it "Apple's" threw me off too, but it's not entirely misleading because without Apple, it might not have become a production-ready compiler. At the least, I would say Apple did more than "just use it".
It's equally weird to describe Android as "Google's".
https://play.google.com/store/apps/details?id=org.mozilla.fe...
It's also worth pointing out that "optimal" in theory doesn't necessarily correspond to optimal in practice. The hard problem of register allocation isn't coloring the interference graph (since there's not enough registers most of the time), it's deciding how best to spill (or split live ranges, or insert copies, or rematerialize, or ...) the excess registers. Plus, real-world architectures also have issues like requiring specific physical registers for certain instructions and subregister aliasing which are hard to model.
In practice, the most important criterion tends to be to avoid spilling inside loops. This means that rather simple heuristics are generally sufficient to optimally achieve that criterion, and in those cases, excessive spilling outside the loops isn't really going to show up in performance numbers. Thus heuristics are close enough to optimal that it's not worth the compiler time or maintenance to achieve optimality.
No, it's only SSA form that has optimal register allocation in polynomial time, otherwise someone would've proved that P=NP (as its proven to NP-Hard). :)
That said, finding minimal SSA from arbitrary SSA is NP-Hard.
> Modern GCC uses SSA form and I think LLVM might too.
LLVM has always used SSA (this is relatively unsurprising given its origins in research and so much research of the period being on SSA).
https://github.com/rust-lang/rust/blob/71340ca4e181b824bcefa...
While Google has not let Chrome stagnate, the Chrome today is no longer the Chrome when it was released. Chrome has definitely felt slower and heavier over the years. Google today is no longer the Google it once was*, and it is getting lots of sticks over privacy problem. Firefox happens to be in the right place at the right time.
That's not Brendan Eich's point of view as part of the tc39 (the standardization body for JavaScript) :
It also true that sometimes it's slow! There's always more to do.
If you want to read the latest info, there is a good status post from a couple of days ago:
https://mozillagfx.wordpress.com/2017/11/27/webrender-newsle...
Guess it must be a specific bug that affected my hardware more than the average person then.
I should note that the bouncing ball test is the kind of thing that WebRender is designed to improve—painting-intensive animations—so it's obviously untrue that there's no interest in improving this sort of workload. When running your bouncing ball test in Servo with master WebRender, I observed CPU usage of no higher than 15% (as well as 60 FPS)…
> I would probably close this as invalid, as it's not something new or specific to Quantum or Servo, or as a duplicate of one of the older bugs, though I'm not sure which.
That likely points as to why there's little movement on this bug. It's title can be interpreted to indicate a Quantum regression, but it's a general issue that's longstanding, so it may be the people that are seeing it are not focused on it (they're likely tracking down and fixing actual regressions, not known problems).
I know that doesn't help your issue, but it may help you locate the relevant bug report and lend your weight there, if you feel so inclined.
I guess putting effort in Stylo diverted some resources from Servo - I feel it didn't progress much the last year in terms of "sites I can browse for more than 5 minutes". At this point it's clear that Mozilla is unlikely to staff Servo to fill the gap (although cpearce and others are working on getting the gecko media stack in Servo), but I wonder what will happen once WebRender makes its way in Gecko; are there any other pieces of Servo that can be useful?
I definitely think Servo layout can be made useful. There have been no indications that parallel layout doesn't work in practice. Our performance tests have had good results, comparable to the results we saw in Stylo.
I would like to redo the way Servo layout scheduling works, possibly when async/await lands in Rust. I believe that will not only improve performance but also fix a whole bunch of random bugs relating to floats where our scheduler currently just does the wrong thing. (That doesn't mean we have to throw out all of that code or anything like that; it just means I'd like to redo how that works.)
Once you have layout, style, and graphics out of the way, what remains—really, at that point, the difference between Gecko and Servo, aside from embeddability—will mostly be DOM APIs and relatively isolated components such as image decoders. It's an open question how to use Servo DOM API implementations in Gecko. In any case, though, Servo's DOM story may change with the arrival of Alan Jeffrey's Josephine or something like it, and it probably makes sense to revisit this question once we decide how all of that will shake out.
And, personally, I don't know if you consider Pathfinder part of Servo or not, but I'm certainly aiming to get that in.
One thing's for sure: we won't be running out of things to do in Research any time soon. :)
The URL parser integration was a proof of concept. It doesn't really improve stuff (aside from a slight security benefit from using Rust) so there wasn't pressure to land it; it was just a way of trying out the then-new Rust integration infra, and inspiring better Rust integration infra.
One of the folks on the network team started it, and I joined in later. But that person got busy and I started working on Stylo. So that code exists, and it works, but there's still work to be done to enable it, and not much impetus to do this work.
This work is mostly:
- Ferreting out where Gecko and Servo don't match so that we can pass all tests. We've done most of this already, whatever's left is Gecko not matching the spec, and we need to figure out how we want to fix that.
- Performance -- In the integration we currently do some stupid stuff wrt serialization and other things; because it was a proof of concept. This will need to be polished up so we don't regress
- Telemetry -- before shipping we need to ship it to nightly in parallel with the existing one and figure out how often there's a mismatch with the normal parser
It's not much work, but everyone is busy.
It's complex because URLs are complex; I believe this is the correct RFC: https://tools.ietf.org/html/rfc3986 It's 60 pages long.
(That said, page length is only a proxy for complexity, of course)
Never again, it's not just that the spec is 60 pages long but that the actual behaviour out in the real world is miles away from the spec, the web is a complex place where standards are...rarely standard.
Old IE versions had a hard URL length limit and were very picky with the characters in domain names, both limitations included as "security fixes" (which broke the standards).
That's interesting. I remember the developer of KWin (KDE's window manager) saying that he considered disabling GPU compositing when the battery runs low, but he couldn't prove that this actually saves energy. In fact, on some configurations, GPU compositing was less power-intensive than CPU compositing.
It's definitely true that different GPUs have different power profiles (and even the same GPU with different drivers).
From my understanding it stems from how Firefox renders and synchronizes frames.
I've filed a bug two months ago, but really unsure when it will get resolved.
On the other hand, if the disk is idle it is blazing fast.
Like I was suggesting early -- my habits haven't changed. It's started doing this quite recently. It wasn't like this a few weeks ago.
One deep problem is that there is no good optimization goal. Today's CPUs are too complex and unpredictable performance-wise.
Another problem is: Register pressure is one of the most important things to minimize, but how can the phases before register allocation do that? They use a surrogate, like virtual registers, and thus become heuristics even if they solve their theoretical problem optimally.
There have been soundness bugs during development and I think we have some really amazing people behind the core language that have been able to refine and adapt rust as it grows.
I can look at the Linux source and figure out what is going on. There are some hard parts (synchronisation stuff and virtual memory is quite opaque on the first look) The code to handle layout and document processing in libreoffice is hairy, but I think I could manage.
A browser on the other hand. Layout and years of accumulated corner cases (handling the infinite variety of bad code out there) proper CSS rendering, multiple JITs, a shit-tonne of state and sandboxing of things that weren't meant to be sandboxed in the first place. Most, or maybe even all at the very bleeding edge of CS research.
(In fact, I might up being the one writing it.) ;)
Wow to me this is big news! I have long wanted the GFX part to be CPU backend instead of the trend of Hardware Acceleration on GPU.
Cant wait to see the results.
Same applies to LLVM. The only reason it might not seem a fair comparison is that Apple has run LLVM as a truly open source endeavour, whereas Android (which marketed itself to geeks as the more open platform) has, as you rightly point out, been run as a closed-source project with occasional begrudging nods to its ever-shrinking open source subset.
When was the last time someone invented a programming language in order to make a thing, and succeeded? Was it C/Unix?
It's widely understood that you're referring to JetBrains' Kotlin. In such case, really industry-famous-IDE support for a 'new language', is some sort of a gift!
Besides, why would a company want to invest in R&D to create a language and just give it for FREE, without any tangible business benefits.
Remember, Sun did so... giving away Java for free. Eventually - under stress - they themselves were sold (and bought by Oracle).
To be specific, LLVM started as an academic project by Vikram Adve and Chris Lattner in 2000. Apple hired Chris Lattner in 2005 to work on LLVM for Apple. Clang, though, does appear to have been an Apple project, being introduced by Steve Naroff of Apple in 2007 as an open-source project.
LLVM is one of the main things Apple gets to claim credit for, yet they aren't the only ones who deserve it.
LLVM is one of the reasons rust is so great, and the world is better because of it.
1.) GCC was designed for command line use, not to provide integration (for instance, debugging info) into a modern IDE.
2.) Objective-C was not a priority for those who maintained GCC, but was for Apple.
Debugging info works similarly in all compilers (GCC, MSVC etc) - it's saved in the compiler output and read by the tools like IDEs.
I think we can say that Gecko ended up technically better than incremental changes to Internet Explorer, which I think was starting off from a more maintainable codebase than Netscape 4. That's hardly conclusive but it's some evidence.
Simply shifting the burden of proof to the "rewrite" side is usually sufficient. Where I currently work a rewrite request is not answered with "no" but "show me the data." 90% of the time the requester doesn't even try to gather data, the other 10% of the time results in some useful metrics about a component that everyone agrees needs some TLC, whatever the final decision.
> ...
> That's hardly conclusive but it's some evidence.
Given Internet Explorer's monopoly position, and consequent disincentive to compete, it's not really the best comparison.
Compare to something like Opera Presto, a codebase that - while younger than Netscape - predates Internet Explorer, which underwent incremental changes while remaining in a minority market position. It was killed by market forces, but I doubt anyone would contest it was a badly put together piece of software in the end.
Konqueror is another example. It's not quite as compelling, as KHTML itself has fared less well than its forks, Safari WebKit has never exactly been a leader in engine advancement, and Chrome's innovations, while incremental, were largely built on a scratch-rewrite-and-launch-all-at-once of one component (V8). However KHTML/Webkit/Blink is still pretty much an incremental rewrite success story.
I would say Joels point still holds in the general case where you you can't count on competitors to just stop developing their product until you have achieved parity again.
Certainly it had better CSS support, and on my machine it crashed less.
The important difference was a matter of support for "official" standards against support for "best viewed in Internet Explorer" sites.
Yes, we do, as does anyone who was following browsers at the time. They tried to incrementally improve Netscape 4 and it was a disaster.
Enterprises tend to invest in <5 year projects, I've noted, and 5 years is a hell of a long time for an extended investment.
This is inaccurate, the URL parser never was and still isn't in a released Firefox.
The first Rust in a released firefox was the mp4 metadata code.
It's worth noting that in those 7 years Servo advanced a lot, which meant that the Stylo project didn't have to rewrite a style system, just take an existing one and polish it. (This is still a lot of work, but not as much)
A good job. Most commercial PL efforts kind of suck. There are a small number of exceptions, and Rust is one of them.
You could argue survivorship bias but that applies to Rust as well.
And probably, Kotlin has made it even simpler than Java.
So, it's an evolving process.
On the other hand, JavaScript - though still painful - has no alternatives... hence, JavaScript is still OK - without any close competitor!