Servo Layout Engine: Parallelizing the Browser [video]
paulrouget.com
paulrouget.com
And Rust isn't just another C clone with OOP or CSP bolted on: it's principled, relatively elegant and takes full advantage of the last few decades of PL research. All while being practical—it has to be, since it's evolved with a Servo as a concomitant project. A non-trivial companion project like that seems great for naturally guiding a language! Not many other languages can say any of this, much less ones actually poised to replace C++ or at least do actual systems programming.
And Mozilla is doing all this in a completely open and transparent way. I think this is incredibly important: anybody can get a glimpse into active development or even contribute. Just go to the relevant GitHub repo[1][2] and you're set. This is the way open source is supposed to work, rather than having companies develop behind close doors and dump source code occasionally (although that's also better than nothing).
I really wish more companies would take this sort of approach with their open source or basic research work. This gives me more confidence in Servo, Rust and Mozilla as a whole, especially compared to many of Mozilla's competitors (both in the browser space and in programming languages).
[1]: https://github.com/mozilla/servo/ [2]: https://github.com/mozilla/rust
It's definitely an interesting aspect. For most languages, the only substantial project during their early life is their own compiler. There is an intriguing theory (posted on HN a few weeks back?) that this results in languages that are optimised for writing compilers, at the expense of writing other things.
Are there other examples of languages that had this kind of companion project in their early life? Did UNIX do this for C? To what extent did Rails do it for Ruby? Is there something inside JetBrains that does it for Kotlin, or inside JBoss that does it for Ceylon?
- Packaging: This is probably where I think Rails contributed most - both rubygems.org and Bundler were created to make it easier to manage the creation and use of lots of large numbers of dependencies, which Rails projects tend to have. Also rvm and its descendants were created to handle Rails app deployments, and are especially useful for situations where you're switching between lots of projects with different ruby version and library dependencies, which is typical in Rails client work.
- Standard library: The `Object#tap` method came from ActiveSupport. Also, ActiveSupport had an OrderedHash, and now all hashes are ordered. I think there are some other examples of that sort of thing.
- Performance: I really don't know what has driven performance improvements have been made, but it doesn't seem outlandish to think that backlash against poor CPU and (especially) memory usage characteristics of Rails applications was a contributor.
rubygems the tool existed before Rails, as did multiple gem hosting mirrors. I believe rubygems.org sprang up because rubyforge.org was falling out of favor. And Bundler is not part of Ruby.
It's possible Wayne Seguin created rvm due Rails but I never got that impression from his talks (but it's been some time).
Pretty sure MenTaLguY created "tap"; Rails had "returning" (though they are similar and perhaps the usage in Rails made it popular enough to warrant inclusion in core).
http://moonbase.rydia.net/mental/blog/programming/eavesdropp...
Certainly if any library gets a lot of use then that will influence aspects of the base language, but matz and ko1 seem pretty deliberate about what gets added.
You're probably right about `.tap`, and I can't think of any other standard library stuff, so my speculation there is seeming pretty weak.
I didn't suggest that Rails invented rubygems and gem hosts, I suggested that rubygems.org and bundler were major improvements to the ruby packaging ecosystem that were driven by Rails. I'm not sure you actually disagreed with that point...
Rubygems.org was not driven by Rails. It doesn't offer much beyond what rubyforge was doing. Less, actually. RF was for code hosting, docs, and gem serving. Once people started moving to github RF lost favor. When Github decided to stop serving gems rubygems.org came about to fill the gap. It lists and serves gesm; code and docs live elsewhere.
Bundler, sure, came form the Rails community to apparently solve a problem for that community. It's not for everyone, though.
I don't use it (doesn't make life any better for me), but then I don't use Rails either.
There's lots that goes in Ruby that has nothing to do with Rails and the conflation of Rails and Ruby is a detriment to different Ruby communities out there.
I think lots of people find Bundler to be an improvement over straight rubygems outside of Rails projects (even if you don't), which I think fits the criteria of "an improvement driven by Rails".
I think your last sentence is the real argument you're trying to make here, and I agree with it wholeheartedly - it's incredibly frustrating that so many people seem to think Ruby is only good or useful because of Rails. I'm not one of those people!
I can't think of one canonical companion project for them, but early Lisp, COBOL, and FORTRAN were also pretty driven by external application concerns, in AI, business logic, and numerical simulation, respectively.
COBOL (and Ada) were standards-first languages. The industry-driven standards committees designed the languages first, and it was not until afterwards that there were working implementations, much less working programs. Industry experience guided them in later releases, but v1.0 (which Rust is still working towards) were even more ivory-tower than languages whose only program is their own compiler.
We're opening three full-time positions on the Servo team at Mozilla Research within the next couple of days; they should be up on the careers[2] page soon.
Also, if you're a graduate student, Mozilla Research is still looking for summer interns for Servo, Daala, Shumway, and other projects. Those positions are also on the careers page.
[1]: https://github.com/mozilla/servo/ [2]: https://careers.mozilla.org/en-US/
For example, on Servo we have about a third of the team in the SF area, but then I'm in Chicago and we have other staff in New Mexico, Toronto, and London. Our largest group of partners is in Korea, and we have several other regular contributors scattered across pretty much every timezone. The big engineering projects, such as FFOS and Gecko are even more distributed.
Quark is a formally verified kernel made of a few hundreds of lines of (C ? C++ ?) code. It's been verified using Coq and hence I take it it's guaranteed from a whole class of bugs typically leading to security exploits (buffer overrun/overflow/underrun, dangling pointer, null pointer, ...).
Is Servo using Quark? If not, is Servo formally verified using Coq?
To me formally verified software are one of the most interesting development we're seeing (that and deterministic builds seems to be huge steps forward towards more security), so I'd like to know more...
(gone building Servo on my Debian box)
Formal verification is cool, but speaking as somebody who worked out it for about 7 years, it is not really ready to be used in large software. Most people care much more about performance and features for their browser. Hopefully by writing a browser in Rust instead of C++, the result will be much more secure, but not have to make many compromises.
I like the idea of formal methods, but my familiarity with the subject is entry-level at best, so I don't even know what sort of details I should be asking about here =P.
Few languages have verified anything—verification is still very challenging to do.
Some additional interesting links to both publications and talks are available on our wiki below (though it's not comprehensive):
https://github.com/mozilla/servo/wiki/General-implementation...
I was hoping Rust could overtake Vala as the goto language for desktop software in the GTK world.
Jürg Billeter created Vala for the sole purpose of building GTK / GNOME applications and the two projects are tightly coupled.
It's not to say that Rust won't have GTK bindings in the future, but it's not a high priority for either Mozilla or GNOME devs and unlikely to displace Vala.
I would have thought that considering they are building a browser that was originally written in C-GTK, the first order of business would be to build GTK bindings.
I would say Vala and Rust do have fairly similar goals in general.
P.S. I know right now Servo != Firefox, but I suppose it will get there eventually.
Vala is only coupled with GLib for the object system and even that can be replaced by using another profile: https://wiki.gnome.org/Projects/Vala/Tutorial#Profiles
That said, the goal of Servo is to improve both speed and safety.
In terms of speed, part of the project is research into parallel algorithms for various parts of the web stack. For example Servo today has parallel implementations of various parts of CSS. The goal here is to make the sequential performance on par with the best implementations today and then get a further speedup by using multiple cores efficiently.
In terms of safety, the choice of Rust over C++ provides substantially stronger compiler-enforced guarantees of memory safety that should help eliminate a large class of bugs that have caused numerous security issues in current browsers.
If this sounds interesting there are plenty of ways to get involved; come chat on #servo on Mozilla IRC.
But it's responsiveness that most people measure, and they measure it on machines with CPU utilization in the single digits - in which case, it is likely to improve considerably.
We plan to explore this space quite a bit.
The other thing we're starting to think about is using SIMD ops for layout, which isn't a GPU but falls into a similar "taking advantage of modern hardware" bucket.
[1] Note that 2D rendering on the GPU is not currently a clear win. In theory you save a texture upload and get massively parallel drawing operations, but in practice there's a lot of overhead to deal with.
There are some very sequential and unfortunately common "corner cases" in layout (e.g., uncleared floats) that have lead us to currently prefer the higher clock-speed CPU for parallelizing phases. Even if we find a great way to work around floats, it's likely there will still be a lot of CPU/GPU chatter, which makes it difficult to use today's GPU cards when you're trying to keep total page load well under 200ms and incremental reflows < 15ms.
Have you looked into HSA architecture that helps to remove this latency? I think this is the direction Intel will move to in a few years.We are actively looking into this.
At least on today's consumer cards (admittedly I haven't tried anything really high-end), one issue I've had with this is that it gets even worse (by far) when more than one program is trying to use the GPU. If you're editing photos in Lightroom while alt-tabbing to a tutorial in the browser, and everything is trying to GPU-accelerate its operations, contention goes way up and things start blocking on GPU contexts and data transfers.
Blink currently doesn't force fullscreen elements to width/height 100%/100%.