> Normally, when engineers try to make software faster, they work from the bottom up. They run a benchmark, look at a flamegraph, find a hotspot, and figure out how to speed up their code by 15% or 20%. The problem with working from the bottom up is that you don't know what the ceiling is. You might be 20% away from the fastest possible code the hardware can run, or you might be 100x away.
> When we started building Gravity, we flipped this question around. We asked ourselves: how fast can a database actually be? Instead of incrementally speeding up our existing query engine, we wanted to start from the physical speed limit of our hardware and file format and work backward. I like to call this “programming at light speed”.
What is described as the “normal” approach to optimizing code is really more the “naïve” approach. Any serious performance optimization work would follow the approach of defining first what’s the ceiling the hardware allows and benchmark against that. And that was already true before LLMs.
Apologies for being nitpicky, but I felt it might be useful for other readers to contextualize that this part of the approach is not novel. Their use of Claude to generate those optimized benchmarks is interesting enough already, so I don’t feel that calling extra attention to this part in their write up is necessary.
I think it kinda depends on the stage of the development. If you have an application already, flame graph whack-a-mole is the normal starting point. This is the correct way to go about it because of Amdahl's law. Random optimization is extremely unlikely to pay off in a way that leads to measurable application wide performance improvements; no matter how big improvements you find for a function that's 0.1% of the run time, you'll never see more than a 0.1% improvement of the run time.
Bottoms up optimization is what you reach for if you have a known hot spot (from a profiler flame graph), or you're deliberating design choices when building something from scratch (where you can be reasonably sure performance will matter).
Of course all of this is exponentially harder for database-adjacent work since you have os and hardware level caches, possibly a buffer pool of your own, and in production you usually operate in fickle semi-resident states that are extremely hard to replicate in a benchmark scenario. So you end up with a lot of benchmarks (cold cache, hot cache, cgroup memory constraints) hoping that sort of fixes it.
You’re absolutely right. Re-reading my take I recognize it is unfair to present these as “naïve”/“serious”. Optimization is a really complex area and there’s a lot of nuance and layers on the techniques involved.
By the way, thanks for marginalia and the great write-ups on your blog.
> Current models are clearly nowhere near the efficiency limit (the brain does vastly more with far less power).
I think this is disingenuous. One could say that drones are nowhere the efficiency limit either: a bee can fly for hours on the energy contained in just a few milligrams of honey, while our best battery-powered drones can't stay airborne for more than 30 minutes. But comparing energy efficiency of electric/mechanical devices to their biological counterparts is not an apples-to-apples comparison. There's a world of difference between the energy storage and delivery mechanisms.
And as many have pointed out already in the siblings, it's not just about the compute but the access to petabytes of training data.
> But here we're talking about a system where legitimate users (human browsers) and scrapers get the same value for every application of the work function. The cost:value ratio is unchanged; it's just that everything is more expensive for everybody. You're getting the worst of both worlds: user-visible costs and a system that favors large centralized well-capitalized clients.
Based on my own experience fighting these AI scrappers, I feel that the way they are actually implemented makes it that in practice there is asymmetry in the work scrappers have to do vs humans.
The pattern these scrappers follow is that they are highly distributed. I’ll see a given {ip, UA} pair make a request to /foo immediately followed by _hundreds_ of requests from completely different {ip, UA} pairs to all the links from that page (ie: /foo/a, /foo/b, /foo/c, etc..).
This is a big part of what makes these AI crawlers such a challenge for us admins. There isn’t a whole lot we can do to apply regular rate limiting techniques: the IPs are always changing and are no longer limited to corporate ASN (I’m now seeing IPs belonging to consumer ISPs and even cell phone companies), and the User Agents all look genuine. But when looking through the logs you can see the pattern that all these unrelated requests are actually working together to perform a BFS traversal of your site.
Given this pattern, I believe that’s what makes the Anubis approach actually work well in practice. For a given user, they will encounter the challenge once when accessing the site the first time, then they’ll be able to navigate through it without incurring any cost. While the AI scrappers would need to solve the challenge for every single one of their “nodes” (or whatever it is they would call their {ip, UA} pairs). From a site reliability perspective, I don’t even care if the crawlers manage to solve the challenge or not. That it manages to slow them down enough to rate limit them as a network is enough.
To be clear: I don’t disagree with you that the cost incurred by regular human users is still high. But I don’t think it’s fair to say that this is not a situation in which the cost to the adversary is not asymmetrical. It wouldn’t be if the AI crawlers hadn’t converged towards an implementation that behaves as a DDOS botnet.
I find it really frustrating that I am not able to avoid using whatsapp due to how popular it is to the point that it’s become the go-to communication channel for most things :/
Indeed. And the worse isn't that we'll have to deal with ads. The worse is that people will stick around despite the ads, which only goes to show how powerful the grip of Meta on our societies is.
... and once they have proof of they power because WhatsApp use keeps increasing despite all the enshittification done in the last few months, they'll feel encouraged to enshittify further in even bolder ways.
That blog post is very interesting in number of ways!
The principles they enlisted
> Advertising has us chasing cars and clothes, working jobs we hate so we can buy shit we don't need. – Tyler Durden, Fight Club
> Advertising isn't just the disruption of aesthetics, the insults to your intelligence and the interruption of your train of thought.
> Remember, when advertising is involved you the user are the product.
---
That said, building a product and selling it for 19 Billion dollars in 2012 was essentially a success of capitalism over those principles. There shouldn't be any complaints, since FB didn't kill it, and the number of users kept increasing.
Just wanted to call out that linkhut does have IFTTT integration [0]. Although you will need to pay for an IFTTT developer account if you want to enable that on your self hosted instance. If you need help setting that up let me know, I’ll be happy to walk you through the process (and that way I can write documentation on how to do it).
Edit: I also was under the impression that one could use the webhooks integration [1] to make bespoke integrations (as the documentation says they support passing arbitrary request headers) but haven’t tried it myself, have you tried it and run into any issues? I’d also be happy to help improving support for that workflow.
Do you have pointers to this? As a Spaniard I recall that even though I was originally told the spanish alphabet treated the LL as its own letter, it always felt quite inconsistent. And I always assumed it’s removal was more about simplifying things than having to do with computers
There is a comment from "adolph" parallel to yours with footnotes. But I remember the event well (though it was 30 years ago) as the difficulty for programmers was given as the justification for the law (this was a change in collation).
This particularly irked me as unicode was a few years old at this point, and while not really adopted yet, was clearly the future.
Just the typical thing: while adding a bookmark, when I start typing in the first letters of a tag (e.g. "hack" for "hackernews"), Pinboard is offering a drop-down menu with possible matches. Linkhut didn't have this last time I checked. It is maybe not a big issue, though -- possibly, relying on your own memory (not programmatically offered suggestions), your tagcloud may get less messy over time; you'll end up with a smaller amount of tags, which may be a good thing at times.
I think I like 'em both, Pinboard and Linkhut, though.
I’ve been using a Steel HR for a few years now. I’m extremely satisfied.
Long battery life is an understatement! Even when the battery drops to near 0 the watch is still useable as a plain analog watch for at least a week giving me enough time to find where I left the damn charger (given that I don’t get to use it often at all).
What I don’t get is how this model (analog watch with just enough smarts) hasn’t gained more traction. It seems to me there’s a lot of opportunities in this space, not everything requires a high resolution display.
I'm kind of disappointed that the Fossil hybrid watches don't do the trick where the watch keeps working when the smart has run out of juice. That said, I get four weeks of battery life, so it's never been an issue in practice.
See for example: https://www.marginalia.nu/log/a_106_native_calls/
Apologies for being nitpicky, but I felt it might be useful for other readers to contextualize that this part of the approach is not novel. Their use of Claude to generate those optimized benchmarks is interesting enough already, so I don’t feel that calling extra attention to this part in their write up is necessary.
reply