The "write" tools include the entire written content in the context, right? So I don't see the distinction.
2,629 karma · joined August 7, 2017
Where they more exhaustive or more frequent?
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%).
That is ... hard to believe for a CPU-bound task. Do you have any open benchmark which can reproduce that?
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.
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.
> 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.
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).
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).
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.
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.
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.
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.
> 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).
As far as I know that is not possible: there's always a copy.
IME it is common to see a process tree with multiple invocations of Python in a ancestor relationship with other processes in between.
E.g. if the thing you run invokes python itself, it will use the system python, not the venv one in the first case.
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?