marginalia_nu

Swap actually helps with performance for the most part.

Here's a good summary of what it actually does. https://chrisdown.name/2018/01/02/in-defence-of-swap.html

TL;DR that swap shouldn't be seen as "spare RAM", but a mechanism for paging out anonymous pages, which is desirable in many circumstances in avoiding OOM situations and making memory management work better. It paradoxically typically reduces I/O thrashing.

To be fair the pitch has frequently been that Devin/Claude/Astra/whatever is some sort of superhuman bottled John Carmack that will single-handedly replace entire teams of developers.

Congrats on your promotion to full time jira management!

Excess power is unevenly distributed both geographically and temporally.

In the SE1 region, which is the least populated and probably best candidate for a data center, there was a 400% price drop between February and March this year, then up 100% in May, then down 50% in July. Between summer 2025 and winter 2026, the same region saw a price hike of nearly 1000%.

https://data.nordpoolgroup.com/auction/day-ahead/prices?deli... 12&currency=EUR&aggregation=MonthlyAggregate&deliveryAreas=SE1,SE2

https://data.nordpoolgroup.com/auction/day-ahead/prices?deli...

I guess if you want a data center that only operates some months of the year that's fine.

At least Sweden is struggling a lot with scaling its power production, to the point where it's a problem for existing and new industries and causing some rather extreme price volatility.

A lot of the green energy is from hydro dams and you can't really add new rivers to the geography to support additional industry.

Anthropic is eyeing an IPO. Of course they're spinning a narrative where their product will reshape the entire economy. They have a vested interest in doing so in the most literal sense of the meaning.

We're never going to get to the point where everyone has a robot manservant making them breakfast in bed. That may well be a product, but you don't need billions of those, but thousands.

The pitch for the billions of humanoid robots is replacing workers, and in that context, the humanoid shape doesn't add much, and in such an economy, the replaced workers aren't going to be splurging on domestic robots.

Why would the robots be walking around so much? Can't you just have one robot on one floor and another robot on another floor and let them share information between them? Humans need to go places to see and hear things, and to communicate with each other. Robots don't have any such limitation.

For moving objects between locations there are much better solutions than building a humanoid robot and having it carry the thing. And it's not like they'd need to go home after their shift.

Wouldn't it be an even bigger economic incentive to not have to go through this inefficient humanoid interface? Anyway, even with the constraint of being able to operate human interfaces, a robot can look many different ways. Like most of the torso just doesn't make sense for a robot.

There's also a ton of obvious improvements. 360 degree vision. Put a camera in each hand too while we're at it. CCD sensors and basic lenses costs next to nothing and it's very easy to replace.

What would even be the point of mass producing humanoid robots? It's not a particularly practical shape for a robot. We have the shape we do because it's a local minimum that accommodates our biological needs (eating, digestion, blood oxygenation and purification, reproduction), all needs that a robot does not have.

A humanoid robot is "horseless carriage" mentality if I ever saw one.

Where pooling does sometimes win is for stuff like intermediate buffers for compression or decompression, since a Java alloc will zero the memory, which for sufficiently large buffers is much costlier than the allocation itself, and in such a case you don't care if it's zeroed.

Removing allocation pressure can also have effects on other parts of the system, but that is anything but trivial to measure or reason about.

Object pooling still has its place, but like any optimization it needs to be based on benchmarks and shouldn't be done haphazardly. Blindly pooling objects will lead to regressions and resource contention more often than improvements.

There are also middle ground options, like pooling objects but giving the pool a lifecycle that is tied to a request.

The entire industry runs on IOUs for compute and bills paid in cloud credits, could be anywhere. Could of course also be a a plain old DDoS.

Birds of the air, lilies of the field, and so on.

NG Resonance from Deus Ex II is arguably an even more on-point comparison.

Both are pretty good, but if you go into the former expecting the latter, you're in for a disappointment. The former is best enjoyed as a separate experience.

??? The only configuration that will allow disk reads at 10 GB/s is if you're using PCIe 5.0. PCIe 4.0 or lower, and SATA will not drop out long before that.

He's very clearly hauling data straight from the page cache.

If you send people to the optimal website containing exactly the information they are after, then you get fewer ad impressions than if you send them to a suboptimal website that has them going back and clicking on more links.

It does seem rather impactful.

I've seen an extremely aggressive uptick in API key requests and sales that I'm not sure where it's coming from. Like it's up 5x over the summer. Been a bit confused about this since I do basically zero traditional marketing or SEO, but I think it's AI search tools that's suggesting my services.

Hard to conclusively beat spam when your primary means of making money is selling the very ads that the spammers are using to make money.

It doesn't have to, but shifting the y-axis to exaggerate differences is like the most textbook example of deception in statistics. In that sense, if you want your work to be taken seriously, especially when it purports to be more accurate than other statistics, it's certainly a choice.

The races, as seen in american sociology have a socioeconomic and historical reality which makes them interesting to track regardless. The racial segregation laws of the past were real, and this has had consequences that are still very real regardless whether the race concept is used correctly in a biological sense.

Why is the y-axis not starting at 0% for all measures? Seems like they're attempting to exaggerate the race and gender differences, even though they'd be perfectly obvious even with a fair graph. Real credibility own-goal, especially given the topic at discussion.

--edit-- Top of the range is also varying between each graph, smaller issue but still ... weird. If you're trying to accurately convey percentages, this is not the way to do it.

DBMS workloads aren't asynchronous like that though. There generally isn't anything you can do while you wait for the buffer pool to execute a read, since what you want to do next depends on the data being read.

Yes that is correct.

You can look at 'rrqm/s' and '%rrqm' in `iostat -x` to get statistics for how many requests are merged, and `rareq-sz` for the average request size.

io_uring is significantly faster for certain workloads, but you can't expect that merely running a syscall via io_uring will somehow magically make it faster.

Replacing single sycalls with their equivalents in io_uring is generally slower than just making the syscall directly. io_uring still uses syscalls after all.

io_uring generally only wins if you can amortize its overhead across multiple simultaneous operations. Implementing readahead would be such a case, except you can accomplish the same amortization with a single preadv instead, which again turns into a single syscall for multiple reads.

If you submit 16 contiguous read requests the system will just merge them into one large read request.

Modern SSDs tolerate moderate queue depths very well, but piling on the I/O queue also incurs tail latency jitter unless you're able to ensure the queue depth stays in the moderate range and never goes higher. All else being equal, fewer larger requests is better for I/O latency (though read amplification for the sake of reading more data obviously doesn't help anyone). Though in this scenario, we're mostly comparing the syscall overhead of a single preadv against io_uring bookkeeping for multiple preads, regardless of how you submit the reads they end up being the same operation.

Though at that point you can just use FADV_WILLNEED.

Depends a lot on the memory pressure. If you can be fairly certain the data is (or will be) resident in memory, mmap is basically unbeatable. If you can't (because the data is larger than RAM or there's other stuff competing for RAM), mmap can have gnarly system-wide performance implications[1].

[1] Mandatory mmap=poop-emoji link: https://db.cs.cmu.edu/mmap-cidr2022/

So I have a buffer pool with O_DIRECT reads.

I implement read-ahead in the application by (optionally) preadv:ing a single read into multiple destination buffers in the pool, leaving them unpinned, since as long as you aren't up against the bandwidth limit of the drive, a larger read is generally as fast as multiple smaller one on modern hardware.

I've tried doing this with io_uring as well, but found just eating the preadv syscall cost was faster.