Net Present Value isn't quite the right thing to look at. Inflation-adjusted energy prices have been rising over time, so the thing these batteries are projected to deliver (fixed impact on that electricity grid) increases in value over time even after the NPV discount. The more important component is the "risk-adjusted" NPV, which may or may not make tech like this effectively worthless.

why dont you think revenue from energy prices isnt baked into the NPV? The time discout is applied, on top of whatever the revenue model is.

At my last company I cut 8k lines from a 10k component and fixed every major bug in the process. It wasn't "dead" per se, but if you start by cleaning up one little bad abstraction then that opens opportunities for the next one and the one after that till eventually all you're left with is software which actually does what it's supposed to.

That hasn't been a unique experience either -- quite the opposite. Codebases bloat over time. The only thing astonishing to me is that in something as large as Bun they only found 11k lines.

FWIW, I notice the intelligence drop drastically with long contexts with Opus 4.6. It's barely usable for anything intricate and long. That long window is good for _something_, but it's not as good as a short window.

for synthesis. read the entire whatever in one gulp and boil it down or plan what to do about it.

not for steps.

Oh yeah, that's a use case I love long contexts for. "Here's a day of prod logs, what's broken?" It's an incredible utility, but the qualities much less than with shorter contexts, and you see it much more apparently when you do similar coding tasks with progressively larger windows.

For the lazy among us (not me of course), is there a small number of core techniques which enabled this for even a single architecture and single CPU core?

1000x improvements unlock qualitatively new capabilities, even when only applied to subcomponents. Moreover, the fact that it's only 0.1% of the runtime is usually [0] an artifact of the entire project being treated that way -- why write this the right way when it won't move the needle on the composite project?

[0] Yes, for LLMs we're closer to the bound than 1000x. Even there though, basic pytorch operations are often 2x slower than simple rewrites, better scheduling algorithms have a history of closer to 5x-10x gains, and all of that supposes you don't have further architectural improvements over time. Moreover, who's to say that legitimately fast tokenization doesn't unlock additional capabilities elsewhere which people have ignored because it was never close to viable?

Say what now? What criteria do they use to scan the populace and create a pre-crime registry of any kind?

Assuming the ink is free, you use some sort of scheme to take advantage of the full printable ascii character set, and you don't bother presenting key values (if necessary, you could print a key offset at the top-left of each page), just the table outputs, I'm getting a break-even point at each character being around 0.2 square nanometers.

The more obvious answer is that they get different marketing signals from the two companies' offerings and want both.

Both. The hypothesis with Eytzinger is that you're doing vanilla binary search on a data structure where each hop is one operation. It doesn't, by itself, do anything to optimize around particular hot leaves, so assuming you aren't doing a weighted rebalance operation before construction it additionally assumes access patterns are somewhat uniform. That's the algorithm and input pattern whose cachability we're trying to optimize.

Imagine, e.g., doing a b-tree lookup on a binary Eytzinger layout. You would always grab more cache lines than optimal. Even more obviously, consider an inorder traversal. The properties of an algorithm and data structure depend properly on both components.

My holdings aren't even locked up, and I'm still not allowed to short my employer -- true as a matter of policy which could get me fired, and true from a US legal perspective most of the time given my role.