Page 1 of 1
Tailslayer
Posted: Sun Apr 12, 2026 5:29 pm
by computeraddict
TL;DR
Implement tailslayer for RAM reads (all? hottest?) to lower average read latency and address the most common megabase hardware limitation
What?
Avoid waiting for DRAM refresh with clever software tricks.
https://www.youtube.com/watch?v=KKbgulTp3FE
Why?
Bigger, more performant megabases. Factory must grow.
Seriously?
Not entirely. I understand that this is a somewhat insanely big request that would only seriously affect a small fraction of the playerbase. That doesn't even include me
Re: Tailslayer
Posted: Sun Apr 12, 2026 5:35 pm
by boskid
No.
Re: Tailslayer
Posted: Sun Apr 12, 2026 5:48 pm
by computeraddict
boskid wrote: Sun Apr 12, 2026 5:35 pmNo.
Totally understandable
Re: Tailslayer
Posted: Mon Apr 13, 2026 4:58 pm
by pioruns
TL;DR: he wrote obscure C++ library to speed up memory operations. Probably vibe coded, no idea as I did not watch the video. Library is here:
https://github.com/LaurieWired/tailslayer
@Tailslayer where are benchmark results you did before and after? What speed gain are we talking about?
Re: Tailslayer
Posted: Mon Apr 13, 2026 9:16 pm
by computeraddict
pioruns wrote: Mon Apr 13, 2026 4:58 pm
TL;DR: he wrote obscure C++ library to speed up memory operations. Probably vibe coded, no idea as I did not watch the video. Library is here:
https://github.com/LaurieWired/tailslayer
@Tailslayer where are benchmark results you did before and after? What speed gain are we talking about?
I still can't figure out what the point of this reply is. You don't seem to know what the thread is about, and I'm sure boskid already knew how silly my request was before you posted this off-base non-summary.
Re: Tailslayer
Posted: Mon Apr 13, 2026 9:27 pm
by pioruns
No, I don't know what this is about. If you were serious you wouldn't post link to YT promotional video to catch likes, but explain it instead, to avoid posts like mine.
Re: Tailslayer
Posted: Mon Apr 13, 2026 9:37 pm
by boskid
Quick summary of the video is that DRAM needs refresh cycles and if a memory channel is currently being refreshed this causes memory access to be delayed until refresh finishes. Proposed solution in the video is that when you have more than 1 channel of memory then refresh cycles are usually not happening at the same time, so by probing which memory addresses are located on memory chips of each channel, you can get a set of variables where each one lives on a different memory channel. By having data duplicated across channels and having multiple threads read data from different variables, if one thread is blocked due to refresh cycle the other thread will finish first and provide a value.
This idea completly misses factorio realms because it would require having literally everything in a hot set of data to be duplicated, it works under assumption you have multiple channels of memory (with ddr5 it is slightly easier since each stick works as 2 halves in separate channels), and from my understanding it would require having multiple threads that are fetching data in a "whoever reads first wins" strategy while causing memory bandwidth requirement to double. This idea is not something we would ever attempt doing, because of uncertainty of hardware players have, because of multiplied memory requirements, because of effectively halved available memory bandwidth, because of complexity of having multiple threads synchronized to read the same value to feed another thread with data.
Re: Tailslayer
Posted: Mon Apr 13, 2026 10:19 pm
by computeraddict
pioruns wrote: Mon Apr 13, 2026 9:27 pm
No, I don't know what this is about. If you were serious you wouldn't post link to YT promotional video to catch likes, but explain it instead, to avoid posts like mine.
It's not my video...? It's also decently large tech news among people interested in hardware, intended mostly as a joke to the devs who I was sure would already be aware of it.
Re: Tailslayer
Posted: Tue Apr 14, 2026 7:11 am
by pioruns
boskid wrote: Mon Apr 13, 2026 9:37 pm
Quick summary of the video is that DRAM needs refresh cycles and if a memory channel is currently being refreshed this causes memory access to be delayed until refresh finishes. Proposed solution in the video is that when you have more than 1 channel of memory then refresh cycles are usually not happening at the same time, so by probing which memory addresses are located on memory chips of each channel, you can get a set of variables where each one lives on a different memory channel. By having data duplicated across channels and having multiple threads read data from different variables, if one thread is blocked due to refresh cycle the other thread will finish first and provide a value.
This idea completly misses factorio realms because it would require having literally everything in a hot set of data to be duplicated, it works under assumption you have multiple channels of memory (with ddr5 it is slightly easier since each stick works as 2 halves in separate channels), and from my understanding it would require having multiple threads that are fetching data in a "whoever reads first wins" strategy while causing memory bandwidth requirement to double. This idea is not something we would ever attempt doing, because of uncertainty of hardware players have, because of multiplied memory requirements, because of effectively halved available memory bandwidth, because of complexity of having multiple threads synchronized to read the same value to feed another thread with data.
Thank you for extensive explanation.
This is exactly what was missing from the opening post.
This is exactly what was missing from the opening post.