Not usually; `float` is 32 bits and `double` is 64 bits on virtually every common platform (maybe not on some DSP chips or certain embedded chips?). But the C++ standard (and probably the C one) only requires that `double` have at least as much precision as a `float`, so it's conceivable you could have a C++ implementation with 32-bit `float` and `double` or 16-bit `float` and 32-bit `double.
Copyright assignment has long been used as an argument of why not to contribute to FSF projects, and is arguably one of the reasons that Clang/LLVM were able to garner contributions from a much broader set of folks.
What are you referring to by "a ton of toolchain-specific hackery" and "a portable way to get LTO working"? It seems like there are very specific things you have in mind, but I'm unclear what bits of work you're referencing. Unless you're thinking of the cross-language LTO work, which is still in progress and is of course clang/llvm-specific? I'd love to see that feature work with GCC, but it's simply not feasible at the present time.
Regardless, that feature being enabled when you're using suitable versions of clang/llvm/rustc doesn't preclude using LTO with other compilers.
We saw significant performance gains when moving from GCC (6) to clang (6). I don't think it'd be particularly hard to switch back at this point; this article provides some solid data for doing so.
You can look at https://data.firefox.com/dashboard/hardware for similar numbers. CPU models are not broken out, but you can get a sense of what sort of CPUs are in use by looking at the GPU model: Intel powers 60%+ of the sampled population.
"Jank" is our internal term for slow, non-responsive interaction with the browser (the capitalization of it in the original message is a little peculiar). If you click your mouse button, and then a second or more later, the item that you were clicking on the screen responds? That's jank. That input form that's not keeping up with your typing? That's jank. And so on.
We can (and do) collect statistics on how much jank people are experiencing, and we can look for ways to improve those statistics, but knowing what particular sites (not complete URLs, just eTLD+1 sites) jank occurs on is much more actionable. Browser developers can go visit particular sites to experience and analyze the jank for themselves, or we can see what janky sites are particularly popular in a given region and focus our efforts on improving those sites--either by doing things more efficiently in the browser, or reaching out to the site developers and asking them to consider changing things to make their site work better in Firefox. (Complete URLs would be even more actionable, but we don't want to collect your complete browser history.)
The argument for Flash is similar: we can get aggregate usage numbers for Flash, and perhaps see how that correlates to jankiness (or crashiness, or what have you), but having some information on what sites are using Flash makes the data even more actionable, for similar reasons as those given above.
The problem with our own browsing data--by which I'm assuming you mean the browsing habits of our ~1000 employees--is that it's wildly non-representative of the broader population. For instance, people here routinely have browser sessions with 10, 100, or even 1000+ tabs. These numbers also indicate that the browser is an application you start, and then you just leave up for a while, perhaps until you restart your computer or you have to update for whatever reason.
The latest statistics we collected on a broader sample of users indicates that the average number of tabs is...2. The average session length is on the order of minutes, not days. Such knowledge leads to very different choices when deciding what browser features to prioritize.
And it's not just browsing usage, either: most employees probably have a top-of-the line (or close to it) Mac laptop, Windows desktop, or Linux desktop; developers have a machine with four, eight, or even more cores. These machines are hardly representative of the wider Firefox user base: a significant majority of our users (~70%) has a machine with two cores, and users with a single core in their machines outnumber users with 8+ cores. We'll not even cover graphics hardware or screen resolution here; see https://hardware.metrics.mozilla.com/ for more examples.
Using our own browsing habits and our own machine specs for making decisions is not feasible.
Yes, across a public interface in a shared library. The SysV ABI just requires that the callee passes a pointer to the structure return value as a hidden parameter; there's nothing saying that pointer must point to different memory than the named object in the program. (Consider how you would implement the call to MyFunction and MyFunction itself at an assembly level that would absolutely require the compiler to allocate two different bigthing objects.)
> C has no choice but to have MyFunction allocate a couple kilobytes on the stack and have main copy the structure from the stack to where it should eventually go. The equivalent Rust code, however, can pass the address of the object x to MyFunction, as if it were actually void MyFunction(bigstruct &output).
What sort of C implementation (ABI, compiler, etc.) are you thinking of here? gcc (x86, x86-64, ARM) is perfectly capable of doing the exact optimization that you describe Rust being able to do.
GCC is very close to the 30-year mark (0.9 released 22 March 1987). Linux turned 25 this past year; Firefox (the C++ parts, at least) is very close to 25, depending on what code you want to count. Apache is 20ish years old. Even LLVM, which I think of as a relatively young project, is getting close to 15 years. Maybe (hopefully?) very little code survives from the initial versions, but they've all withstood the test of time.
It's certainly pleasing to be able to sit down and write something from scratch or nearly from scratch. But it can be equally pleasing to extend a multi-million line codebase to do something new, or to enable the codebase as a whole to do something new/better.