Live data from Hacker News

DRAM has a design flaw from 1966. I bypassed it [video]

youtube.com

21–30 of 174 posts

Re: DRAM has a design flaw from 1966. I bypassed it [video]

#21
post #14

Am I the only one who feels the comments here don't sound organic at all?

No I felt the same way, they're exactly like the usual LLM bot comment where a LLM recap ops and ends with an platitude or witty encouragement.

But all the accounts are old/legit so I think that you and me have just become paranoid...

Re: DRAM has a design flaw from 1966. I bypassed it [video]

#22

Halfway through this great video and I have two questions: 1) Can we take this library and turn it into a a generic driver or something that applies the technique to all software (kernel and userspace) running on the system? i.e. If I want to halve my effective memory in order to completely eliminate the tail latency problem, without having to rewrite legacy software to implement this invention. 2) What model miniatu…

> halve my effective memory in order to completely eliminate the tail latency problem,

Wouldn't you have a tail latency problem on the write side though if you just blindly apply it every where? As in unless all the replicas are done writing you can't proceed.

Re: DRAM has a design flaw from 1966. I bypassed it [video]

#23
post #14

Am I the only one who feels the comments here don't sound organic at all?

You're absolutely right to call this out. No humans, no emotion, no real comments - just LLM slop.

In all seriousness, agreed. The top comment at time of this writing seems like a poor summarizing LLM treating everything as the best thing since sliced bread. The end result is interesting, but neither this nor Google invented the technique of trying multiple things at once as the comment implies.

Re: DRAM has a design flaw from 1966. I bypassed it [video]

#24

Halfway through this great video and I have two questions: 1) Can we take this library and turn it into a a generic driver or something that applies the technique to all software (kernel and userspace) running on the system? i.e. If I want to halve my effective memory in order to completely eliminate the tail latency problem, without having to rewrite legacy software to implement this invention. 2) What model miniatu…

1. not that I can think of, due to the core split. It really has to be independent cores racing independent loads. anything clever you could do with kernel modules, page-table-land, or dynamically reacting via PMU counters would likely cost microseconds...far larger than the 10s-100s of nanoseconds you gain.

what I wished I had during this project is a hypothetical hedged_load ISA instruction. Issue two requests to two memory controllers and drop the loser. That would let the strategy work on a single thread! Or, even better, integrating the behavior into the memory controller itself, which would be transparent to all software without recompilation. But, you’d have to convince Intel/AMD/someone else :)

2. It’s called a “smokeninja”. Fairly popular in product photography circles, it’s quite fun!

Re: DRAM has a design flaw from 1966. I bypassed it [video]

#25
I haven't had time to see the whole thing yet, but I'm quite surprised this yielded good results. If this works I would have expected CPU implementations to do some optimization around this by default given the memory latency bottleneck of the last 1.5 decades. What am I missing here?

Re: DRAM has a design flaw from 1966. I bypassed it [video]

#26

Halfway through this great video and I have two questions: 1) Can we take this library and turn it into a a generic driver or something that applies the technique to all software (kernel and userspace) running on the system? i.e. If I want to halve my effective memory in order to completely eliminate the tail latency problem, without having to rewrite legacy software to implement this invention. 2) What model miniatu…

1. not that I can think of, due to the core split. It really has to be independent cores racing independent loads. anything clever you could do with kernel modules, page-table-land, or dynamically reacting via PMU counters would likely cost microseconds...far larger than the 10s-100s of nanoseconds you gain. what I wished I had during this project is a hypothetical hedged_load ISA instruction. Issue two requests to t…

Or, even better, integrating the behavior into the memory controller itself, which would be transparent to all software without recompilation.

Yeah it would be neat to just flip a BIOS switch and put your memory into "hedge" mode. Maybe one day we'll have an open source hardware stack where tinkerers can directly fiddle with ideas like this. In the meantime, thanks for your extensive work proving out the concept and sharing it with the world!

Re: DRAM has a design flaw from 1966. I bypassed it [video]

#27

This is an unreasonably good video. Hopefully, it inspires others to see we can still think hard and critically about technical things.

Yeah, wow, the comments weren't kidding. This'll probably be the best video I watch all month, at least, if not more. I would have said what she was trying to do was "impossible" (had I not seen the title and figured … well … she posted the video) and right about when I was thinking that she got me with:

> Hold on a second. That's a really bad excuse. And technology never got anywhere by saying I accept this and it is what it is.

Re: DRAM has a design flaw from 1966. I bypassed it [video]

#29

Halfway through this great video and I have two questions: 1) Can we take this library and turn it into a a generic driver or something that applies the technique to all software (kernel and userspace) running on the system? i.e. If I want to halve my effective memory in order to completely eliminate the tail latency problem, without having to rewrite legacy software to implement this invention. 2) What model miniatu…

1. not that I can think of, due to the core split. It really has to be independent cores racing independent loads. anything clever you could do with kernel modules, page-table-land, or dynamically reacting via PMU counters would likely cost microseconds...far larger than the 10s-100s of nanoseconds you gain. what I wished I had during this project is a hypothetical hedged_load ISA instruction. Issue two requests to t…

Is there a reason you can think of why AMD, Intel etc. would not want to do this?

Really enjoyed the video and feel that I (not being in the IT industry) better understand CPUs und and RAM now.

Re: DRAM has a design flaw from 1966. I bypassed it [video]

#30
post #6

Love the format, and super cool to see a benchmark that so clearly shows DRAM refresh stalls, especially avoiding them via reverse engineering the channel layout! Ran it on my 9950X3D machine with dual-channel DDR5 and saw clear spikes from 70ns to 330ns every 15us or so. The hedging technique is a cool demo too, but I’m not sure it’s practical. At a high level it’s a bit contradictory; trying to reduce the tail late…

On most RAM tREF can be increased a lot from the default, at least if kept somewhat cool.
Post reply on HN