Live data from Hacker News

How Stylo Brought Rust and Servo to Firefox

bholley.net

131–140 of 199 posts

Re: How Stylo Brought Rust and Servo to Firefox

#131
post #97

Earlier quoted context omitted.

Kind of OT, but I've noticed both latency and battery-life hits for compositing WMs in X (compared to traditional WMs). 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.

(Nitpick: Traditional WMs composite as well, they just do it on the CPU instead of the GPU.) 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.

I thought traditional WMs had the clients send the draw commands directly to the server, rather than doing any compositing themselves?

It's definitely true that different GPUs have different power profiles (and even the same GPU with different drivers).

Re: How Stylo Brought Rust and Servo to Firefox

#132

Earlier quoted context omitted.

What I wonder, and I do not mean this in negative way, is whether this would have happened in a more commercially oriented organisation. Mozilla remains a foundation, and I consider Rust a fruit of their labour in itself. 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…

Imagine if some company were to make a completely new language just for an IDE.

Is that a reference to JetBrains and Kotlin? :-)

Re: How Stylo Brought Rust and Servo to Firefox

#133
post #45

> For example, register allocation is a tedious process that bedeviled assembly programmers, whereas higher-level languages like C++ handle it automatically and get it right every single time. 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 actu…

Optimal register allocation has been polynomial time for more than 10 years - for some definition of optimal. IIRC it started with programs in SSA form and has dropped that requirement more recently. Modern GCC uses SSA form and I think LLVM might too.

GCC and LLVM do not retain SSA form by the time register allocation happens (they both convert to a non-SSA low-level IR before then).

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.

Re: How Stylo Brought Rust and Servo to Firefox

#134

> the breadth of the web platform is staggering. It grew organically over almost three decades, has no clear limits in scope, and has lots of tricky observables that thwart attempts to simplify. 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.

This is what XHTML2 attempted and failed, HTML5 is the opposite, most of the work was to specify what already existed.

Re: How Stylo Brought Rust and Servo to Firefox

#135
post #42

It's gratifying to see how successfully the same organization has learned from the debacle that was the rewrite from Netscape 4 to Mozilla in the first place. That time, they didn't release for years, losing market share and ceding the web to Internet Explorer for the next decade. Joel Spolsky wrote multiple articles[1][2] pointing out their folly. This time, their "multiple-moonshot effort" is paying off big-time be…

I'm curious - in both of those articles Joel uses the expression "software doesn't rust", to make fun of Netscape.. is that where the name for the Rust language came from?

Re: How Stylo Brought Rust and Servo to Firefox

#136
post #42

It's gratifying to see how successfully the same organization has learned from the debacle that was the rewrite from Netscape 4 to Mozilla in the first place. That time, they didn't release for years, losing market share and ceding the web to Internet Explorer for the next decade. Joel Spolsky wrote multiple articles[1][2] pointing out their folly. This time, their "multiple-moonshot effort" is paying off big-time be…

I'm curious - in both of those articles Joel uses the expression "software doesn't rust ", to make fun of Netscape.. is that where the name for the Rust language came from?

It’s not. There’s no canonical reasons, and there’s multiple non-canonical ones.

Re: How Stylo Brought Rust and Servo to Firefox

#137
post #42

It's gratifying to see how successfully the same organization has learned from the debacle that was the rewrite from Netscape 4 to Mozilla in the first place. That time, they didn't release for years, losing market share and ceding the web to Internet Explorer for the next decade. Joel Spolsky wrote multiple articles[1][2] pointing out their folly. This time, their "multiple-moonshot effort" is paying off big-time be…

I'm curious - in both of those articles Joel uses the expression "software doesn't rust ", to make fun of Netscape.. is that where the name for the Rust language came from?

I noticed that too and was curious. A quick search doesn't say that's where it came from, but I agree it would be ironic. Maybe that planted a seed in someone's mind.

Re: How Stylo Brought Rust and Servo to Firefox

#138
post #42

It's gratifying to see how successfully the same organization has learned from the debacle that was the rewrite from Netscape 4 to Mozilla in the first place. That time, they didn't release for years, losing market share and ceding the web to Internet Explorer for the next decade. Joel Spolsky wrote multiple articles[1][2] pointing out their folly. This time, their "multiple-moonshot effort" is paying off big-time be…

I'm curious - in both of those articles Joel uses the expression "software doesn't rust ", to make fun of Netscape.. is that where the name for the Rust language came from?

The name has multiple origins, Graydon notoriously gave a different story each time he was asked.

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.

Re: How Stylo Brought Rust and Servo to Firefox

#139

Earlier quoted context omitted.

> most benchmarks 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.…

Not sure if this is normal, but I have very noticeable lag in the search/address bar autocomplete which does make the whole browser feel a bit slow (MacOS Sierra, using Developer Edition). And since we are here, the prompt/dialog windows in FF are still not native looking too. These are my two major complaints :)

This isn't just a problem with the address bar, it also applies to HTML inputs and textareas.

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.

https://bugzilla.mozilla.org/show_bug.cgi?id=1408699

Re: How Stylo Brought Rust and Servo to Firefox

#140
post #2

One thing I've noticed about Firefox, especially on mobile, is that transform animations are pretty janky. Does anyone know if this is being worked on? Should I submit a bug report?

This blog has a good example of the jank you are reporting. I am observing noticeable jank on the "slideup" animation on #fixedcontent.firstvisit vs. Chrome (62.0.3202.94). (macOS/10.12.6 FF/57.0 late-2013 MBP)
Post reply on HN