BeeOnRope

> like who are we kidding, the type of nerds who were attracted to math and software were into it because we saw it as an art-form, it was a craft,

The "write" tools include the entire written content in the context, right? So I don't see the distinction.

Do you have any view on why the AI scrapers resulted in a heavier load than existing crawlers from eg search engines?

Where they more exhaustive or more frequent?

It can work when the marginal cost of new capacity is high, compared to existing capacity.

E.g., if the marginal cost of supporting 1 kW of new capacity may be X, while the current averaged cost of 1 kW provided to existing customers may be Y, with Y < X.

The customer will calculate their ROI on a battery purchase based on the cost Y of kW to them, which may be poor (4%), while on the government level of the ROI may is closer to that implied by the cost X (say 10%). However, the government cannot easily pass on the "marginal cost" to customers as there is no specific kWh which is that marginal one across all customers.

In this case a subsidy directly picks out customers who can reduce their demand by buying a battery (e.g., a subsidy which raises the ROI to somewhere between 4% and 10%).

Wafer area?

> The most insane part here is that the AMD EPYC 4565p can beat the turin's used on the cloud providers, by as much as 2x in the single core.

That is ... hard to believe for a CPU-bound task. Do you have any open benchmark which can reproduce that?

What I mean is that we look at a function in isolation and see that it doesn't have any "dead code", e.g.,:

  int factorial(int x) {
    if (x < 0) throw invalid_input();
    // compute factorial ...
  }

This doesn't have any dead code in a static examination: at compilation-time, however, this function may be compiled multiple times, e.g., as factorial(5) or factorial(x) where x is known to be non-negative by range analysis. In this case, the `if (x < 0)` is simply pruned away as "dead code", and you definitely want this! It's not a minor thing, it's a core component of an optimizing compiler.

This same pruning is also responsible for the objectionable pruning away of dead code in the examples of compilers working at cross-purposes to programmers, but it's not easy to have the former behavior without the latter, and that's also why something like -Wdead-code is hard to implement in a way which wouldn't give constant false-positives.

Why is that a problem? Inlining and optimization aren't minor aspects of compiling to native code, they are responsible for order-of-magnitude speedups.

My point is that it is easy to say "don't remove my code" while looking at a simple single-function example, but in actual compilation huge portions of a function are "dead" after inlining, constant propagation and other optimizations: not talking anything about C-specific UB or other shenanigans. You don't want to throw that out.

Dead code is extremely common in C or C++ after inlining, other optimizations.

Relevant section:

> Compiler controlled memory: There is a mechanism in the processor where frequently accessed memory locations can be as fast as registers. In Figure 2, if the address of u is the same as x, then the last load μ-op is a nop. The internal value in register r25 is forwarded to register r28, by a process called write-buffer feedforwarding. That is to say, provided the store is pending or the value to be stored is in the write-buffer, then loading form a memory location is as fast as accessing external registers.

I think it over-sells the benefit. Store forwarding is a thing, but it does not erase the cost of the load or store, at least certainly on the last ~20 years of chips and I don't think on the PII (the target of the paper) either.

The load and store still effectively occur in terms of port usage, so the usual throughput, etc, limits apply. There is a benefit in latency of a few cycles. Perhaps also the L1 cache access itself is omitted, which could help for bank conflicts, though on later uarches there were few to none of these so you're left with perhaps a small power benefit.

More registers leads to less spilling not more, unless the compiler is making some really bad choices.

Any easy way to see that is that the system with more registers can always use the same register allocation as the one with fewer, ignoring the extra registers, if that's profitable (i.e. it's not forced into using extra caller-saved registers if it doesn't want to).

User variance? Any evidence?

If you had a shell script hook, yes you would also run that in CI.

Are you asking what advantage pre-commit has over a shell script?

Mostly just functionality: running multiple hooks, running them in parallel, deciding which hooks to run based on the commit files, "decoding" the commit to a list of files, offering a bunch canned hooks, offering the ability to write and install non-shell hooks in a standard way.