BeeOnRope

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 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?

How does prek handle pre-push hooks? I.e. how does it determine the list of modified files.

This is a long standing sore point in pre-commit, see https://github.com/pre-commit/pre-commit/issues/860 and also linked duplicates (some of which are not duplicates).

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.

They integrate well with CI.

You run the same hooks in CI as locally so it's DRY and pushes people to use the hooks locally to get the early feedback instead of failing in CI.

Hooks without CI are less useful since they will be constantly broken.

Critical section was IIRC built on top of windows manual/auto reset events which are a different primitive useful for more than just mutex but without the userspace coordination aspect (32 bit value) of futexes.

What is a BM?

What is the point of the intent entry at all? It seems like operations are only durable after the completion record is written so the intent record seems to serve no purpose (unless it is say much larger).

No there are vanilla 64GB shipping now too, e.g. Crucial CT2K64G56C46S5.

Writes to the log don't need to be in the order of the producers timestamp, they just need to be in some (and respect ack to produce causality, etc).

Yes, I rely heavily on ^ and ' in antuin, though that's partly to workaround the relatively poor fuzzy search (in fzf I never even needed those).

I use Atuin and like it a lot, and sync history across hosts.

However, the fuzzy search in Atuin is worse than fzf, which was a downgrade. It just has less effective heuristics/scoring, e.g. it might find the individual letters of a short command scattered in a command that had a long base64 input or something.

What is a late slip?

Uncontended CAS without carried dependendies on the result (almost always the case in this use case) are similar in performace to atomic add on most platforms.

The CAS is the price they pay for contention detection, though it would be interesting to consider solutions which usually use unconditional atomics with only the occasional CAS in order to check contention, or which relied on some other contention detection approach (e.g., doing a second read to detect when the value incremented by more than your own increment).

The solution looks reasonable to me given the constraints.

Yeah exactly, and this is a commonly used trick in concurrent data structures in general. The Java implemenation has the additional twist that they don't use a fixed number of "slots" but rather start at 1 and use CAS failures as a mechanism to detect contention and then grow the number of slots until there are no longer CAS failures.

Thanks, you mention explicitly kernel networking right below about the send path:

before flinging them at the kernel as [vectors of] large, contiguous DMA requests, without having to stop to allocate

So I had assumed you were taking about kernel networking elsewhere as well.

BTW, on the kernel send path, there is again a copy, contiguous or not, regardless of what API you use.

When using kernel networking I don't think contiguity matters as you suggest, as there is always a copy. Furthermore "contiguous" in userspace doesn't correspond to contiguous in physical address space so in any case the hardware is just often going to see a userspace buffer as a series of discontiguous pages anyway: that's what happens with direct IO disk writes, which _are_ zero copy (huge pages helps).

How does bytes crate, or anyone else, offer zero copy receive from kernel (as opposed to kernel bypass) sockets?

As far as I know that is not possible: there's always a copy.

I don't think that's "sure" at all. For one thing, only Python code directly calling Python has that option in the first place, often there is another layer of indirection, e.g., Python code which executes a shell script, which itself invokes Python, etc.

IME it is common to see a process tree with multiple invocations of Python in a ancestor relationship with other processes in between.

Note that in general calling the venv python directly vs activating the venv are not equivalent.

E.g. if the thing you run invokes python itself, it will use the system python, not the venv one in the first case.

Well very interesting. I don't really read that as supporting my idea of a renamer limit: seems like the throughput would either be higher (assuming the CQO just goes "for free" in the same rename cycle) or lower and also depend heavy on the interleaving (assuming the SHLX uses a whole rename cycle by itself or something like that).

So maybe it's like you say: SHLX with the anomaly is only semi-pipelined: it takes 2 cycles before the next SHLX can dispatch. Perhaps it needs to use 1 cycle to handle the unfolding of the folded immediates, then the shift happens in the second cycle, and then the latency just has to be rounded up to 3 since all uops on those ports are 1 or 3, never 2 (which simplifies the scheduler, I believe).

That would also explain the original 1/cycle throughput for pure SHLX with anomaly: as 2 non-pipelined cycles on the port, 2 ports = the observed throughput.

So it's sort of like a 2 uop instruction but can't _actually_ be 2 uops because "rename" is too late to crack something into 2 uops (that's already happened), so it just does the doubling up internally?

By default they are not thread safe, i.e., they offer the same thread safety as std::map or any stdlib type; however, the map can optionally be made thread safe and is apparently optimized for this usage. Details at: https://github.com/greg7mdp/parallel-hashmap?tab=readme-ov-f....

Really interesting. Normal uops don't work like that, they are always pipelined, so a p06 op with 3-cycle latency would always be 3/0.5, not 3/1.

So the 1-throughput strikes me as a renamer limit, not an execution limit. I.e., these instructions can only flow through the renamer at 1 per cycle.

This could perhaps be tested by interleaving unrelated p06 ops in the same ratio as SHLX, and see if they + SHLX are able to saturate p06, and also trying different interleaving granularities like 1:1 and 5:5 since I would expect those to behave differently in the renamer (but not much different in execution).

How did you test the throughout? Seems quite weird. Does it go to both ports still?