Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Saving 100 terabytes of memory by optimizing 1.1.1.1's DNS cache

blog.cloudflare.com

Post reply on HN
Print view View original

211–220 of 305 posts

Re: Saving 100 terabytes of memory by optimizing 1.1.1.1's DNS cache

#211

Post by f311a »

kibwen wrote: post #181
f311a wrote: post #70

Earlier quoted context omitted.

Unfortunately, Rust is not a good choice for this kind of tricks. This is where Zig shines. In Rust, you can’t even use proper arenas, which can help a ton with allocations. Cloudflare started to pick Zig recently, for projects, that have memory constraints.

Rust supports arenas just fine ( https://crates.io/crates/bumpalo ), and if you mean the support for using custom allocators in the standard library collections, that's as stable as Zig is.

There are more than 10 crates for arenas with different tradeoffs, I'm well aware of them. They are still very limited compared to C/Zig.

Re: Saving 100 terabytes of memory by optimizing 1.1.1.1's DNS cache

#213

Post by anon48293 »

esseph wrote: post #199
hdjrudni wrote: post #183

Earlier quoted context omitted.

Well then you didn't read parent's comment > is it possible to buy a reasonably nice home located in a reasonably nice amerikkkan city… for $300k in 2026? Who wants acreage? We want homes.

> is it possible to buy a reasonably nice home located in a reasonably nice amerikkkan city… for $300k in 2026? What does "city" mean to you? For some, it's 500 people, or 5,000. For some, it's 5 million. Define that first. The US is a big place, and I know people that don't live within 50 miles of another human. Otherwise: https://www.zillow.com/homedetails/424-Olive-St-Kansas-City-... 4 bed, 3 bath, 1,580 sq ft, be…

That’s 350, which you can’t buy for 300..

Re: Saving 100 terabytes of memory by optimizing 1.1.1.1's DNS cache

#214

Post by jmalicki »

irdc wrote: post #74
listeria wrote: post #38

Earlier quoted context omitted.

Depends on how the CacheEntry is stored, it's probably stored in a slice of &[CacheEntry] which precludes storing the record data alongside it as the size of each entry must be fixed.

This is where hand-rolled intrusive data structures, as are traditional in C, really shine.

Even in C, if you want differently sized data to be indexable in O(1), you're stuck leaving them as pointers. You definitely could just have a variable-sized area for this, but that level of optimization is pretty seldomly done in C.

Re: Saving 100 terabytes of memory by optimizing 1.1.1.1's DNS cache

#215

Post by majke »

brainless wrote: post #176
lpapez wrote: post #68

This is the right way to deliver software. Produce working product first, validate the idea, stabilize the business, start generating profit, and then you can start optimizing your costs. In fact optimization is by far the easiest part of the process because there are many system programming experts on this HN thread who consider these optimizations to be trivial.

I do not think Cloudflare was a less-than-peers optimized product when they launched. This is one of their blog posts which describes taking one aspect even further. I think Cloudflare became big only because they were so much more optimized than others that they offered some services for free that others were not offering. If running costs are high, you only burn (VC) cash and then you exit.

First version was a three layer VM monster, with the main entrance done as HTTP proxy written in PHP.

Re: Saving 100 terabytes of memory by optimizing 1.1.1.1's DNS cache

#216

Post by GeneralMaximus »

perching_aix wrote: post #98
r3trohack3r wrote: post #37

Earlier quoted context omitted.

Rob Pikes 5 Rules of Programming: Rule 1. You can't tell where a program is going to spend its time. Bottlenecks occur in surprising places, so don't try to second guess and put in a speed hack until you've proven that's where the bottleneck is. Rule 2. Measure. Don't tune for speed until you've measured, and even then don't unless one part of the code overwhelms the rest. Rule 3. Fancy algorithms are slow when n is…

> Don't tune for speed until you've measured, and even then don't unless one part of the code overwhelms the rest. Genuine question, is software performance really linear like that, that one can and should only fight the tightest bottleneck, one workload at a time? Never really sounded right. It also sounds like the typical sleight of hand where the difficult bit is simply laundered a layer up, in this case the choic…

In many cases, yes. A software pipeline can only achieve as much throughput as its slowest stage, and much of the software we write can be modeled as a sequence of processing stages.

Re: Saving 100 terabytes of memory by optimizing 1.1.1.1's DNS cache

#217

Post by Sarkie »

lpapez wrote: post #68

This is the right way to deliver software. Produce working product first, validate the idea, stabilize the business, start generating profit, and then you can start optimizing your costs. In fact optimization is by far the easiest part of the process because there are many system programming experts on this HN thread who consider these optimizations to be trivial.

Make it work, make it fast, refactor

Re: Saving 100 terabytes of memory by optimizing 1.1.1.1's DNS cache

#218

Post by kibwen »

zamalek wrote: post #198

The intermediate level Rust dogma is to try your hardest to avoid the heap, and to tear your hair out at the throne of monomorphization. While both are broadly true, it's articles like this that show that a single pointer (or call) indirection can sometimes be better.

I'd say that boxing large enum variants is itself an intermediate level Rust topic, and a well-accepted practice. Clippy will even point out places where you might benefit from boxing an enum variant: https://rust-lang.github.io/rust-clippy/master/index.html?se...

Re: Saving 100 terabytes of memory by optimizing 1.1.1.1's DNS cache

#220

Post by IshKebab »

bvanheu wrote: post #109
pocksuppet wrote: post #103

Earlier quoted context omitted.

It's the exact thing Rust is made to protect against, on a more local scale. Every memory corruption bug is just an out-of-bounds index that wasn't protected against.

is dangling pointers reuse memory corruption bug from out of bound index?

No. He's wrong that every memory error is out-of-bounds access (spatial memory safety). There's also use-after-free (temporal memory safety). Arguably type confusion too but that's a grey area.
Post reply on HN