I am ignorant on nearly all compiler related issues, but there was an article on here not too long ago that was arguing that nearly all os development required old C because choices of the committee would break use cases required under the guise of undefined behavior.

is the benefits of "modern C" worth compile times 2-3x times longer?

Times like these I wish I were allowed to say exactly how much money big companies save by using the newest versions of GCC and Clang. The economic value of modern compiler optimizations is staggering.

I hereby give you permission to say exactly how much money big companies save by using the newest versions of GCC and Clang.

Thanks, but it's my employer's permission I'm concerned with. :)

> wish I were allowed to say exactly how much money big companies save[...]

Are you able to give hints that would guide us in thought exercises?

Facebook has hinted that they employ smart C++ people because some core optimizations can save on the order of several hundred thousand dollars per year (possibly in the millions). Most of that is off because they don't have to buy as much power to cool the server rooms, some of it is buying less servers as what they have can do more. Facebook doesn't actually say what they save, but they have said they measure it, and we know how much it costs to employ an engineer full time working only on optimization, and we know who some of those engineers are.

You have to be very large to notice it, but the likes of Facebook, amazon, and Google have massive warehouses almost entirely filled with computers. It doesn't take much to see how their power bill can add up.

Years ago Alexandrescu said that Facebook estimated a .1% speedup to HHVM would save them $100k/year. It's presumably only gone up since then, but he's stopped giving an actual number in talks.

I would argue that he is bragging, and that the amount of code optimization is minimal. Large companies love to brag about how many servers they have, and optimizing compilation is just a buzz word. Go ahead, buy another servers. $100k is nothing. Its less than 1 engineer year vs 24,000 engineer years.

The Distribution collectors, they brag about speed, and optimization is very important to them. They want to be able to test changes very quickly.

The parent works at Facebook/Meta leading their Rust team, focusing on compiler and ecosystem improvements. So that in and of itself is a sort of hint into what that info could be like, even if it's not actual details of the order of magnitude or anything.

The Google Search optimization team measures changes in terms of millions of CPUs. So if upgrading your compiler saves even 0.1%, well, that's a lot of servers you don't have to buy next year.

Apple went out and bought a CRAY.

"Jun 30, 1987 — The Cray is part of a $20m installation used by Apple's Advanced Technology group and consists of four CPUs operating at 9.5nS per cycle,"

Now we have distcc, that can both massively parallelize compilation, and optimization.

Googles team probably shows some slight improvement, just to justify their work, but in the long run, its just as sloppy as industry wide coding is.

Microsoft is the absolute worst, along with Apple.

One avenue is to think about it in terms of datacenter compute. If modern compiler optimizations improve performance by 10%, aggregate the perf improvements across the entire world's compute and you get a huge saving.

> but there was an article on here not too long ago that was arguing that nearly all os development required old C because choices of the committee would break use cases required under the guise of undefined behavior.

I would guess that you're referring to either "How ISO C became unusable for operating systems development" ([0]) or "How One Word Broke C" ([1]).

[0]: https://arxiv.org/abs/2201.07845 , most recent HN discussion at https://news.ycombinator.com/item?id=30022022

[1]: https://web.archive.org/web/20210307213745/https://news.quel... , HN discussion at https://news.ycombinator.com/item?id=22589657

Most of the really annoying UB is technically in C89 though, it’s just that compilers haven’t really treated it with such contempt for the first two decades or so. I can’t even recall any new kinds of (non-library) UB in C99 or C11 (though there have to be some).

So “old C” in such a case would need to mean “an old C implementation” (or possibly a new one, but simple or configured to behave like an old one), something like GCC 2.8 maybe, and nobody’s using that on desktop. So the language standard version should be mostly immaterial, and it’s not like the C89-to-C17 difference is anything like the yawning C++98-to-C++20 chasm. (This is a carefully phrased statement: C99 had complex numbers, which are annoying, and variable-length arrays, which are a significant change, but C11 demoted both to optional features.)

> is the benefits of "modern C" worth compile times 2-3x times longer?

I mean, you get more security by default and security is pretty darn important for kernels...

I think you're mixing up two different things. Newer standard versus newer compiler. All versions of the C standard have lots of undefined behavior. Newer compilers contain optimizers that are just better at leveraging it.

Why would a different standard cause longer compile times?

If the spec requires that the compiler look for a certain error and produce a diagnostic, then the compiler has to spend time doing that. The more complicated the spec is, the more work the compiler has to do to find the errors.

For example, Rust is frequently said to have long compile times. There are a number of interesting reasons why that is often true, but if we ignore the pathological cases then what we find is that borrow checking takes a significant fraction of that compile time. This is a big trade–off between features and complexity that the Rust language made very deliberately: the advantages of the borrowing rules are what makes Rust such a great language. The cpu time spent checking that those rules have been followed are a small price to pay, but not a negligible one.

Is there a single such which you cannot disable by compiler flags?

You cannot disable the borrow checker in Rust with a compiler flag. You might as well try to turn off the type checker, or ask it to ignore syntax errors.