FWIW, as someone who has done exactly this in a megacorp (sloshing through homebrew technical debt with 32-bit assumptions baked in), the initial wave to get the most important systems working was measured in person-months. The long tail was a slog, of course, but it's not an all-or-nothing proposition.

(50TB+ on ext4 and xfs, and no, no bit rot. Yes, I've checked most of it against separate sha256sum files now and then. As long as you have ECC RAM, disks just magically corrupting your data is largely a myth.)

I remember moving there, hearing talks about how international Zurich was, and then realizing most of those foreigners were German. :-) It's diverse on paper (and probably to the Swiss), but it's not like it's a cosmopolitan melting pot.

You will still see plenty of e.g. SID covers of existing pop music, without anyone really batting an eyelid.

Not necessarily; before Kyle started this one-man crusade against data loss, database vendors would claim generally whatever and it would go unchallenged for decades. (You might get the occasional bug report, which you could handwave away as “hardware” or “you're holding it wrong” or just ignore it.) Now you're _slightly_ less likely to succeed, but only as long as e.g. your product is sufficiently uninteresting or hard enough to set up that he doesn't test it. :-)

This is incorrect, for exactly the reason you are citing: A * x * x * x * x = (((A * x) * x) * x) * x), which means that (x * x) is nowhere to be seen in the expression and cannot be factored out. Now, if you wrote x * x * x * x * A instead, _then_ the compiler could have done partial CSE against the term with B, although still not as much as you'd like.

_Can_ you even make a reasonable high-ILP scheme for a polynomial, unless it's of extremely high degree?

  A * x * x * x * x * x * x + B * x * x * x * x + C * x * x + D

instead of the faster

  tmp = x * x;
  ((A * tmp + B) * tmp + C) * tmp + D

Here's a dirty secret: It's just like IPv4, except with longer addresses and slightly different autoconfig. :-) (Well, you don't have the legacy of classful addressing and non-contiguous netmasks and stuff, but I don't really think most people care much about that in the IPv4 world either.) Getting up to speed is, thankfully, simple.

It seems most of it is AI-generated, without any real attempt at cleaning up errors.

Or wait for us to launch random() :-) (It's in development, available if you enable a flag)

I never implemented their hash table, but it opened my eyes to the technique of a tiny Bloom filter, which I've used now a couple of times to fairly good (if small) effect. :-)