froydnj

We do, yes.

I should also note that number is Ruby files only.

The most recent publicly available numbers (that I know of, maybe there's a talk available somewhere that's more recent) are from https://stripe.com/blog/sorbet-stripes-type-checker-for-ruby

currently amounting to over 15 million lines of code spread across 150,000 files

The monorepo has only gotten bigger over the last two years (source: I work at Stripe).

Stripe is a huge Sorbet user.

Just because indexing is bounds-checked by default doesn't mean that the bounds-checking is necessarily in your final code:

https://rust.godbolt.org/z/er9Phcr3c

Yes, you still have the bounds check when constructing the slice, but that's fine.

And since it's probably slightly more common to iterate over the length of the vector anyway:

https://rust.godbolt.org/z/e5sdTb7vK

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.

The WASI tutorial for compiling C/Rust to wasm and running it has some useful information on this front: https://github.com/bytecodealliance/wasmtime/blob/master/doc...

We wouldn't have been able to put wasm in Firefox like this if there wasn't decent compiler/runtime support via the clang ecosystem.

How big and/or complicated have your patches been? Copyright assignment is not necessary for not-legally significant changes: https://www.gnu.org/prep/maintain/maintain.html#Legally-Sign...

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.

Regression testing for performance is checked via several test suites (Talos, for instance, with numerous subtests: https://wiki.mozilla.org/Performance_sheriffing/Talos/Tests) and monitored by our ever-dutiful performance sheriffs (https://wiki.mozilla.org/Performance_sheriffing).

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.

GCC is written in C++ nowadays.

It is a real theory, and people have done the simulations to demonstrate its effects: https://www.space.com/31577-earth-life-jupiter-saturn-giant-...

(Disclaimer: I work for Mozilla.)

"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.

(Disclaimer: I work for Mozilla)

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.

All sorts of people do, since Mozilla's financials are publicly available. See the audited statement at the end of https://www.mozilla.org/en-US/foundation/annualreport/2015/

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.

You say "doesn't happen quite often", which I'm assuming means something like "doesn't happen quite often to me". But if you consider hundreds of millions of users using Firefox every day, then even a relatively rare event is happening to multiple users every single day. It is absolutely worth it to them that Firefox does its best to preserve their data.

Obviously it's helpful for printing things.

Less obviously, emacs has commands that navigate by logical pages (C-x [, C-x ]). And of course you can adjust the regex that denotes logical pages.

Microsoft's PGO/LTCG implementation does just this. GCC can do something similar as well.

Use --show-possibly-lost=no to avoid those "possibly lost" reports.

> You should be asked when you hit a web page if they can add a cookie. > > At the moment, this is done by the page by legislation, but the next step is to do this at the browser level. I'm quite happy as it's training users to do this nicely.

Firefox used have an option to ask you whether you wanted to receive cookies sent by websites. Turning it on made your browsing experience quite unpleasant. And that was several years ago; I imagine it'd be worse today.

> I was surprised that the vectorisation it mentions was not performed automatically.

The OP didn't mention what compiler was being used; GCC will certainly automatically vectorize this example (and ICC probably will as well). I used GCC 4.4 for x86 with -O3 -msse2.

Of course, there's a lot of compensation code inserted for unaligned pointers and aliased pointers and the like, but automatic vectorization is certainly doable.

-Wuninitialized in gcc depends on the optimization settings: http://gcc.gnu.org/onlinedocs/gcc-4.6.1/gcc/Warning-Options....

> The question to ask is: What are the economic and social forces keeping the COBOL code base alive?

Do you want to be the person who volunteers to rewrite those codebases into $HOT_NEW_LANGUAGE (or even $BORING_STABLE_LANGUAGE) and be on the hook for ensuring that your rewrite exactly replicates the behavior of the old system? Introducing bugs--or even inadvertently fixing bugs--during the rewrite is absolutely not allowed.

Let's say, for concreteness, that each one of those tasks above is a multi-million line codebase. Think about what that would cost, both in person-years and in monetary terms. (Sure, you can write 10x less code...but half a million to a million lines of Python is still a lot of Python.) Remember, you probably have to have a fairly exhaustive specification of how the original system worked before you embark on the rewrite; just getting that specification together is likely to be tilting toward person-years of work.

Do you want to be the manager who goes around to talk to all the involved stakeholders and explains to them why this is a worthwhile use of their systems, time, and money? ("We'll have an easier time recruiting people to work on the system," probably doesn't fly; neither does, "$LANGUAGE is cleaner/faster/more readable.") What do you tell them when they ask about possible issues during the transition? And so on and so forth.

> the FSF does not like allowing proprietary compiler plugins and (I guess) has to little manpower to work on gcc.

Fortunately, the FSF is not the entity driving development of GCC. In fact, I can't remember a commit in the last five years (there's been ~60k commits, so there'd be plenty to choose from) made by an FSF employee. So there are plenty of people and companies focused on moving GCC forward.

Ah, I see I missed that part of your comment. I think we are in agreement on that point, then.