HackerReposA FIELD GUIDE TO OPEN SOURCE
ProSponsor the shelf♧ 0
← Back to top all-time
LaurieWired
tailslayer
C++2026–2026
LaurieWired / tailslayer

tailslayer

Library for reducing tail latency in RAM reads

3Distinct people
3Mentions
0Explicit recommenders
2.9KGitHub stars
REPOSITORY AT A GLANCE

What to know before exploring

What it is

Library for reducing tail latency in RAM reads

GitHub

Where it is used

No documented product use has been verified yet.

What people are saying

No recommendation phrase was found in the indexed comments.

No classified warning is attached to this page. Read the discussions before treating silence as approval.

Also in these discussions

No other repository is repeatedly linked in the same discussions.

This week on Hacker News

Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 3:56:07 PM UTC.

No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.

Mentions over time

HN mentions by 3-hour interval3 dated mentions

Observed mentions: 2026-04-07 19:16:10 UTC to 2026-04-10 07:12:50 UTC.

012026-04-07 18:00:00 UTC to 2026-04-07 21:00:00 UTC (exclusive): 1 mentions; 1 submissions, 0 commentsApr 7, 18:002026-04-07 21:00:00 UTC to 2026-04-08 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2026-04-08 00:00:00 UTC to 2026-04-08 03:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2026-04-08 03:00:00 UTC to 2026-04-08 06:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2026-04-08 06:00:00 UTC to 2026-04-08 09:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2026-04-08 09:00:00 UTC to 2026-04-08 12:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2026-04-08 12:00:00 UTC to 2026-04-08 15:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2026-04-08 15:00:00 UTC to 2026-04-08 18:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2026-04-08 18:00:00 UTC to 2026-04-08 21:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2026-04-08 21:00:00 UTC to 2026-04-09 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2026-04-09 00:00:00 UTC to 2026-04-09 03:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 commentsApr 9, 00:002026-04-09 03:00:00 UTC to 2026-04-09 06:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2026-04-09 06:00:00 UTC to 2026-04-09 09:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2026-04-09 09:00:00 UTC to 2026-04-09 12:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2026-04-09 12:00:00 UTC to 2026-04-09 15:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2026-04-09 15:00:00 UTC to 2026-04-09 18:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2026-04-09 18:00:00 UTC to 2026-04-09 21:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2026-04-09 21:00:00 UTC to 2026-04-10 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2026-04-10 00:00:00 UTC to 2026-04-10 03:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2026-04-10 03:00:00 UTC to 2026-04-10 06:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2026-04-10 06:00:00 UTC to 2026-04-10 09:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 commentsApr 10, 06:00

Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.

View mention counts and date ranges
UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
PeriodStart (UTC)End (exclusive, UTC)MentionsSubmissionsComments
Apr 7, 18:002026-04-07 18:00:00 UTC2026-04-07 21:00:00 UTC110
Apr 7, 21:002026-04-07 21:00:00 UTC2026-04-08 00:00:00 UTC000
Apr 8, 00:002026-04-08 00:00:00 UTC2026-04-08 03:00:00 UTC000
Apr 8, 03:002026-04-08 03:00:00 UTC2026-04-08 06:00:00 UTC000
Apr 8, 06:002026-04-08 06:00:00 UTC2026-04-08 09:00:00 UTC000
Apr 8, 09:002026-04-08 09:00:00 UTC2026-04-08 12:00:00 UTC000
Apr 8, 12:002026-04-08 12:00:00 UTC2026-04-08 15:00:00 UTC000
Apr 8, 15:002026-04-08 15:00:00 UTC2026-04-08 18:00:00 UTC000
Apr 8, 18:002026-04-08 18:00:00 UTC2026-04-08 21:00:00 UTC000
Apr 8, 21:002026-04-08 21:00:00 UTC2026-04-09 00:00:00 UTC000
Apr 9, 00:002026-04-09 00:00:00 UTC2026-04-09 03:00:00 UTC000
Apr 9, 03:002026-04-09 03:00:00 UTC2026-04-09 06:00:00 UTC000
Apr 9, 06:002026-04-09 06:00:00 UTC2026-04-09 09:00:00 UTC000
Apr 9, 09:002026-04-09 09:00:00 UTC2026-04-09 12:00:00 UTC000
Apr 9, 12:002026-04-09 12:00:00 UTC2026-04-09 15:00:00 UTC000
Apr 9, 15:002026-04-09 15:00:00 UTC2026-04-09 18:00:00 UTC000
Apr 9, 18:002026-04-09 18:00:00 UTC2026-04-09 21:00:00 UTC000
Apr 9, 21:002026-04-09 21:00:00 UTC2026-04-10 00:00:00 UTC000
Apr 10, 00:002026-04-10 00:00:00 UTC2026-04-10 03:00:00 UTC101
Apr 10, 03:002026-04-10 03:00:00 UTC2026-04-10 06:00:00 UTC000
Apr 10, 06:002026-04-10 06:00:00 UTC2026-04-10 09:00:00 UTC101

What Hacker News says

3 sources
This is a 54 minute video. I watched about 3 minutes and it seemed like some potentially interesting info wrapped in useless visuals. I thought about downloading and reading the transcript (that's faster than watching videos), but it seems to me that it's another video that would be much better as a blog post. Could someone summarize in a sentence or two? Yes we know about the refresh interval. What is the bypass? Update: found the bypass via the youtube blurb: https://github.com/LaurieWired/tailslayer "Tailslayer is a C++ library that reduces tail latency in RAM reads caused by DRAM refresh stalls. "It replicates data across multiple, independent DRAM channels with uncorrelated refresh schedules, using (undocumented!) channel scrambling offsets that works on AMD, Intel, and Graviton. Once the request comes in, Tailslayer issues hedg
Read the rest
ed reads across all replicas, allowing the work to be performed on whichever result responds first."
In DRAM has a design flaw from 1966. I bypassed it [video]
This is very much worth watching. It is a tour de force. Laurie does an amazing job of reimagining Google's strange job optimisation technique (for jobs running on hard disk storage) that uses 2 CPUs to do the same job. The technique simply takes the result of the machine that finishes it first, discarding the slower job's results... It seems expensive in resources, but it works and allows high priority tasks to run optimally. Laurie re-imagines this process but for RAM!! In doing this she needs to deal with Cores, RAM channels and other relatively undocumented CPU memory management features. She was even able to work out various undocumented CPU/RAM settings by using her tool to find where timing differences exposed various CPU settings. She's turned "Tailslayer" into a lib now, available on Github, https://github.com/LaurieWired/tailsla
Read the rest
yer You can see her having so much fun, doing cool victory dances as she works out ways of getting around each of the issues that she finds. The experimentation, explanation and graphing of results is fantastic. Amazing stuff. Perhaps someone will use this somewhere? As mentioned in the YT comments, the work done here is probably a Master's degrees worth of work, experimentation and documentation. Go Laurie!
In DRAM has a design flaw from 1966. I bypassed it [video]

MAKE YOURSELF AT HOME

A few shortcuts

/
Search the collection
?
Open this guide
Esc
Close dialogs and navigation

Your saved repositories and interests stay in this browser.