Saving another 100TB of RAM with math (and Rust)

ricardobeat•5 minutes ago

These optimizations are impressive, but it gets me thinking: at what point does a company become a collection of impenetrable siloes, where nothing really does what you expect? Maybe know with AI this is less of an issue as exploring a codebase is also much faster.

proc0•7 minutes ago

The only Rust section is the one on storage improvements about the struct that stores the hash, but do they really need that many hashes that 2 bytes makes that big of a difference? Article doesn't expand, but I guess it's a hash for every task on every computer, so maybe yes.

agosta•4 minutes ago

That's exactly his point/the area of cost saving - that they didn't actually need as many hashes as they had started with. The trick was in finding out how many hashes they could cull without degrading load balance.

agosta•8 minutes ago

Bang up article! As someone who doesn't get to do enough (almost any) calculus in my daily programming assignments, I thoroughly enjoyed reading about Kevin's dive into that derivation (linked in the supplemental article). All the people being negative here can swallow raisins

officialchicken•23 minutes ago

Come on CF, you can't even be bothered vibe a README for the crate? Somebody tear down this post until this garbage is documented properly.

I found this in the code, it looks like a rewrite-in-rust:

//! # pingora-ketama

//! A Rust port of the nginx consistent hashing algorithm.

//!

//! This crate provides a consistent hashing algorithm which is identical in

//! behavior to [nginx consistent hashing](https://www.nginx.com/resources/wiki/modules/consistent_hash...).

//!

//! Using a consistent hash strategy like this is useful when one wants to

//! minimize the amount of requests that need to be rehashed to different nodes

//! when a node is added or removed.

cyberpunk•7 minutes ago

Anyone have an idea how it behaves differently from google's jump hash algorithm? The cool thing about google's one is it's so short I can include it in a HN comment:

    int32_t JumpConsistentHash(uint64_t key, int32_t num_buckets) {
      int64_t b = 1, j = 0;
      while (j < num_buckets) {
        b = j;
        key = key * 2862933555777941757ULL + 1;
        j = (b + 1) * (double(1LL << 31) / double((key >> 33) + 1));
      }
      return b;
    }

https://arxiv.org/pdf/1406.2294

agosta•13 minutes ago

We can tell you didn't read the post because it is definitively NOT garbage. Very interesting write up by the Cloudflare team - the man literally did calculus to improve something. When's the last time any of us did Calculus to improve anything? Bang up job Kevin and everyone!!

go_elmo•about 1 hour ago

Was this vibecoded? I hope so, would expect models to be good enough by now, its not that creative.

n738•about 1 hour ago

go_elmo is unimpressed everyone. Pack it up. Time to go home.

Maxion•about 1 hour ago

I think it's more important now than it was last year to differentiate pure yolo vibecoding from "AI assisted engineering" or "AI engineering", I.e. deliberate and careful use of AI to speed up coding but without creating too much slop. Maybe aineering?

wild_pointer•about 1 hour ago

Nah, AI code is black or white, and whether the code is good depends on your religion.

kawogi•about 1 hour ago

AIded development?

derwiki•about 1 hour ago

Just like the original harness, aider.chat

readthenotes1•about 1 hour ago

I expect a another post in a year where they get a performance improvement by reducing the number of calls to create integers from bytes.

Saving another 100TB of RAM with math (and Rust)

⚡ Community Insights

Discussion (14 Comments)Read Original on HackerNews