Live data from Hacker News

Servo’s new home

blog.servo.org

271–280 of 326 posts

Re: Servo’s new home

#271

Earlier quoted context omitted.

I'm not personally a rust zealot, but I know that rust builds on LLVM and therefore benefits from some of that very same engineering effort that was built to optimize C and C++.

Clang usually has worse performance than GCC.

Is there anything specific GCC does for performance that Clang/LLVM could adopt? How is this race expected to evolve over time?

Re: Servo’s new home

#272

Earlier quoted context omitted.

Servo last time I checked used the same if not more memory (100MB) for basic pages. There doesn't appear to be major differences for that application yet.

Why should there be any great difference? Firefox is already written in a language where compilers have been optimized since decades. Rust will not bring that magic.

Rust makes it much easier to do complex performance optimizations safely, particularly those involving concurrency. The canonical example is the multi-threading of Servo’s CSS processor.

It’s not an automatic magic bullet, but in a world where humans are still writing the code, Rust’s feature set makes many performance optimizations much more practical.

Re: Servo’s new home

#273
post #33
post #18

Wow, this is awesome. - Mozilla engineering finally gets the green light to beat Chrome through a from-scratch rendering stack - This skunkworks initative popularizes the world's first viable C++ contender and interesting "mainstreamable" programming language - Manglement suddenly lays off the teams responsible for both projects (Rust and Servo) - Some awesome person from the trenches convinces said manglement to rel…

Why is Mozilla not betting on Rust anymore?

IDK they put a lot of resources into the quantum project and it didn't really increase their market share, in fact in Germany it dwindled more quickly. Now it's stabilized again IIRC but which signal does that send to management? The market didn't reward Rust adoption, as successful as the language is outside of the browser.

Re: Servo’s new home

#274
post #87
post #36

Earlier quoted context omitted.

What's the plan exactly? Will there be a Servo browser that integrates the servo rendering engine with some open source components (for instance from Firefox, WebKit or Chromium) that will let us use the engine stand-alone, or is it "just" going to be an engine for embedding in third-party programs? The former seems like it would be a huge amount of work, but if it's the latter I fear for the long term survival of th…

A third-option that I would like to see is extending the latter to an Electron alternative (aka using Servo as a cross-platform GUI). There's definitely positives to Electron, but it would be nice to see a more performant, less memory hungry, and more battery friendly alternative.

I’ve posed this question several times online and in the Servo repo and the response was always, “Umm, no, not interested.”

Re: Servo’s new home

#275
post #271

Earlier quoted context omitted.

Clang usually has worse performance than GCC.

Is there anything specific GCC does for performance that Clang/LLVM could adopt? How is this race expected to evolve over time?

Not answering your question but in my experience reading assembly output of the two compilers the unoptimized output of Clang is atrocious while GCC is closer of what a human could have wrote. Clang seems to have to do better in optimization passes to archive similar results. Usually Clang was a faster compiler in O1 but I don’t think it’s true anymore.

Re: Servo’s new home

#276
post #212

I am confused. I thought it is the raison d'être of Mozilla to develop a browser. So how does it come that the brand new browser engine they developed is being given away? I mean, even if they need to cut costs, isn't Servo part of the team they should keep until the end?

>I am confused. I thought it is the raison d'être of Mozilla to develop a browser. To put it bluntly: Mozilla is no longer a browser company. It is a patsy for google to point to and say "See we're not a monopoly.". Secondary goals are increasing the supply of devs for big tech and lowering wages.

oof

Re: Servo’s new home

#277

I am confused. I thought it is the raison d'être of Mozilla to develop a browser. So how does it come that the brand new browser engine they developed is being given away? I mean, even if they need to cut costs, isn't Servo part of the team they should keep until the end?

A lot of people misunderstand what Servo was. It was for developing components that could be integrated into a browser. Firefox integrated most of those and continues to develop more code in Rust. Servo lost it's use.

Damn, so Mozilla just threw away Servo.

Re: Servo’s new home

#278
post #275
post #271

Earlier quoted context omitted.

Is there anything specific GCC does for performance that Clang/LLVM could adopt? How is this race expected to evolve over time?

Not answering your question but in my experience reading assembly output of the two compilers the unoptimized output of Clang is atrocious while GCC is closer of what a human could have wrote. Clang seems to have to do better in optimization passes to archive similar results. Usually Clang was a faster compiler in O1 but I don’t think it’s true anymore.

that's just because gcc has certain optimization passes that can't be disabled

(that said gcc -O0 is still absolutely nothing like what a human would write)

Re: Servo’s new home

#279
post #271

Earlier quoted context omitted.

Clang usually has worse performance than GCC.

Is there anything specific GCC does for performance that Clang/LLVM could adopt? How is this race expected to evolve over time?

it's not so much that gcc does anything specific so much as LLVM is just really really inefficient—they don't track compilation time at all so it's easy for releases to regress, half the stuff in there is academics implementing their PhD thesis aiming for algorithmic accuracy with little regard for efficiency, and LLVM's design itself is somewhat inefficient (multiple IRs, lots and lots of pointers in IR representation, etc)

that said this makes it an excellent testbed but compilation time will keep getting slower every release until they start caring about it

Re: Servo’s new home

#280
post #36

Earlier quoted context omitted.

What's the plan exactly? Will there be a Servo browser that integrates the servo rendering engine with some open source components (for instance from Firefox, WebKit or Chromium) that will let us use the engine stand-alone, or is it "just" going to be an engine for embedding in third-party programs? The former seems like it would be a huge amount of work, but if it's the latter I fear for the long term survival of th…

The latter would be better, imo. Chromium won because it introduced a sane API before Mozilla's Gecko. That's why you see so many Electron apps. Seriously, we don't need to wrap a whole browser. Just the engine and a debugger would've been fine. The engine could be distributed as a lib and other frameworks could just bind it. Apps could be distributed without an 150MB behemoth just to have a chat client. Making the e…

I'm not sure what you mean by 'an engine', but people who choose Electron typically don't want a rendering engine like Servo, they want to write a web app and have it installed locally. They need a rendering engine, a JS runtime, a DOM handler, an HTTP client library, WebSockets support etc - they want a whole browser.

Also, 150MB is not really that scary of a size in today's world. Also, a huge part of it is simply because of static linking - if they split it into dynamic libraries, the actual content of any individual Electron-based app would be reduced significantly. But people are mostly allergic to dynamic libraries, so we pay the cost in larger binaries. Also note that vim with all its dependencies is ~40 MB, without a GUI.

Post reply on HN