Hacker News: dist1ll

New comment by dist1ll in "OpenTPU – An open-source AI accelerator, developed by AI"

dist1ll — Tue, 06 Oct 2026 18:26:25 +0000

> with about the same efficiency and just a little more code.

It depends. For some things, CPUs don't even come close. An XCVU13P FPGA can handle 1.2Tbps of full-duplex Ethernet @ 1 billion pps. And that part costs less than a grand at moderate qty, and with significantly less power consumption than a CPU that'd be capable of operating a dataplane at these speeds.

New comment by dist1ll in "Cloudflare AKE cuts origin HelloRetryRequests from 52% to 3.7%"

dist1ll — Tue, 15 Sep 2026 02:54:58 +0000

There's more to building a successful CDN business than running workloads in a testing environment.

New comment by dist1ll in "Cloudflare AKE cuts origin HelloRetryRequests from 52% to 3.7%"

dist1ll — Mon, 14 Sep 2026 23:12:56 +0000

For content delivery you can simulate the load one PoP would get. You don't need to be at Cloudflare scale to build a testbench with 800G+ of traffic at different pps.

New comment by dist1ll in "Principles for Fast Tokio Applications"

dist1ll — Mon, 14 Sep 2026 22:55:48 +0000

Fwiw with ef_vi you have full control over the event queue - you don't need to busy-spin it, you can choose whatever strategy you prefer.

> tokio is appropriate for general userspace apps

Yep, and for those I wouldn't recommend it. But tokio is also widely used in performance-critical infrastructure and web services. For those I'd say it can definitely be worth taking a second look at kernel bypass.

New comment by dist1ll in "Principles for Fast Tokio Applications"

dist1ll — Mon, 14 Sep 2026 18:31:19 +0000

When you're at a point of tuning Tokio, consider taking a look at ef_vi/DPDK + SPDK

New comment by dist1ll in "Building a 25 Gbit/s workstation for the SCION Association"

dist1ll — Tue, 13 Jan 2026 08:59:14 +0000

Your MS-01 routes line-rate 25Gbps in software with VyOS w/o kernel bypass? That's very surprising to me. At what packet sizes?

New comment by dist1ll in "Logging sucks"

dist1ll — Tue, 23 Dec 2025 03:04:30 +0000

Sorry for the OT response, I was curious about this comment[0] you made a while back. How did you measure memory transfer speed?

[0] https://news.ycombinator.com/item?id=38820893

New comment by dist1ll in "What Does a Database for SSDs Look Like?"

dist1ll — Sat, 20 Dec 2025 13:58:11 +0000

The Aurora paper [0] goes into detail of correlated failures.

> In Aurora, we have chosen a design point of tolerating (a) losing an entire AZ and one additional node (AZ+1) without losing data, and (b) losing an entire AZ without impacting the ability to write data. [..] With such a model, we can (a) lose a single AZ and one additional node (a failure of 3 nodes) without losing read availability, and (b) lose any two nodes, including a single AZ failure and maintain write availability.

As for why this can be considered durable enough, section 2.2 gives an argument based on their MTTR (mean time to repair) of storage segments

> We would need to see two such failures in the same 10 second window plus a failure of an AZ not containing either of these two independent failures to lose quorum. At our observed failure rates, that’s sufficiently unlikely, even for the number of databases we manage for our customers.

[0] https://pages.cs.wisc.edu/~yxy/cs764-f20/papers/aurora-sigmo...

New comment by dist1ll in "What Does a Database for SSDs Look Like?"

dist1ll — Sat, 20 Dec 2025 12:41:01 +0000

> "surely if I send request to 5 nodes some of that will land on disk in reasonably near future?"

That would be asynchronous replication. But IIUC the author is instead advocating for a distributed log with synchronous quorum writes.

New comment by dist1ll in "What Does a Database for SSDs Look Like?"

dist1ll — Sat, 20 Dec 2025 12:37:36 +0000

Is there more detail on the design of the distributed multi-AZ journal? That feels like the meat of the architecture.

New comment by dist1ll in "Revisiting "Let's Build a Compiler""

dist1ll — Wed, 10 Dec 2025 13:04:40 +0000

As long as your target language has a strict define-before-use rule and no advanced inference is required you will know the types of expressions, and can perform type-based optimizations. You can also do constant folding and (very rudimentary) inlining. But the best optimizations are done on IRs, which you don't have access to in an old-school single pass design. LICM, CSE, GVN, DCE, and all the countless loop opts are not available to you. You'll also spill to memory a lot, because you can't run a decent regalloc in a single pass.

I'm actually a big fan a function-by-function dual-pass compilation. You generate IR from the parser in one pass, and do codegen right after. Most intermediate state is thrown out (including the AST, for non-polymorphic functions) and you move on to the next function. This give you an extremely fast data-oriented baseline compiler with reasonable codegen (much better than something like tcc).

New comment by dist1ll in "StardustOS: Library operating system for building light-weight Unikernels"

dist1ll — Fri, 05 Dec 2025 07:19:49 +0000

I would argue that stateful services (databases, message queues, CDNs) all perfectly fit the unikernel model. The question is whether the additional engineering effort and system design is worth the performance gain.

New comment by dist1ll in "Why xor eax, eax?"

dist1ll — Mon, 01 Dec 2025 14:04:31 +0000

Another one is "jalr x0, imm(x0)", which turns an indirect branch into a direct jump to address "imm" in a single instruction w/o clobbering a register. Pretty neat.

New comment by dist1ll in "Cloudflare outage on November 18, 2025 post mortem"

dist1ll — Wed, 19 Nov 2025 16:09:27 +0000

I do use a combination of newtyped indices + singleton arenas for data structures that only grow (like the AST). But for the IR, being able to remove nodes from the graph is very important. So phantom typing wouldn't work in that case.

New comment by dist1ll in "Cloudflare outage on November 18, 2025 post mortem"

dist1ll — Wed, 19 Nov 2025 03:06:26 +0000

Sure, these days I'm mostly working on a few compilers. Let's say I want to make a fixed-size SSA IR. Each instruction has an opcode and two operands (which are essentially pointers to other instructions). The IR is populated in one phase, and then lowered in the next. During lowering I run a few peephole and code motion optimizations on the IR, and then do regalloc + asm codegen. During that pass the IR is mutated and indices are invalidated/updated. The important thing is that this phase is extremely performance-critical.

New comment by dist1ll in "Cloudflare outage on November 18, 2025 post mortem"

dist1ll — Wed, 19 Nov 2025 02:04:22 +0000

If that's the case then hats off. What you're describing is definitely not what I've seen in practice. In fact, I don't think I've ever seen a crate or production codebase that documents infallibility of every single slice access. Even security-critical cryptography crates that passed audits don't do that. Personally, I found it quite hard to avoid indexing for graph-heavy code, so I'm always on the lookout for interesting ways to enforce access safety. If you have some code to share that would be very interesting.

New comment by dist1ll in "Cloudflare outage on November 18, 2025 post mortem"

dist1ll — Wed, 19 Nov 2025 01:41:57 +0000

For iteration, yes. But there's other cases, like any time you have to deal with lots of linked data structures. If you need high performance, chances are that you'll have to use an index+arena strategy. They're also common in mathematical codebases.

New comment by dist1ll in "Cloudflare outage on November 18, 2025 post mortem"

dist1ll — Wed, 19 Nov 2025 01:11:33 +0000

> every unwrap in production code needs an INFALLIBILITY comment. clippy::unwrap_used can enforce this.

How about indexing into a slice/map/vec? Should every `foo[i]` have an infallibility comment? Because they're essentially `get(i).unwrap()`.

New comment by dist1ll in "WASM 3.0 Completed"

dist1ll — Thu, 18 Sep 2025 03:32:13 +0000

WASM traps on out-of-bounds accesses (including overflow). Masking addresses would hide that.

New comment by dist1ll in "How is Ultrassembler so fast?"

dist1ll — Sun, 31 Aug 2025 21:32:49 +0000

Ditto. Perfect hashing strings smaller than 8 bytes has been the fastest lookup method in my experience.