[dead]
DRAM has a design flaw from 1966. I bypassed it [video]
161–170 of 174 posts
Re: DRAM has a design flaw from 1966. I bypassed it [video]
#162Would be cool to see the performance difference for llama2.c or see it work for gddr on gpus too with nanogpt, though I guess the latter might or might not be possible because of architecture differences.
Re: DRAM has a design flaw from 1966. I bypassed it [video]
#163Earlier quoted context omitted.
Yeah. These are literally just mainframe techniques from yesteryear.
Almost everything "new" was invented by IBM it seems like. And it goes by a completely different name there. It's still nice to rediscover what they knew.
As another poster said, the impressive part here is the work on lining up all the technical features to implement this simple concept. Though I'm the end Laurie realized that essentially brute force worked well.
One thing that I'd think about improving is the boundary search. It seems to me at mere first glance that binary search would usually be much faster. Also, knowing what architecture is used, e.g. channel width, could further optimize the search.
Re: DRAM has a design flaw from 1966. I bypassed it [video]
#164Earlier quoted context omitted.
Clearly, hitting a cache would be the better outcome. The technique suggested here could only apply to unavoidably cold reads, some kind of table that's massive and randomly accessed. Assume it exists, for whatever reason. To answer your question, refresh avoidance is an advertised benefit of hardware mirroring. Current IBM techno-advertising that you can Google yourself says this: "IBM z17 implements an enhanced red…
I can google, thanks. My point is that nobody is buying mainframes with redundant memory to avoid refresh stalls. It’s a mostly irrelevant freebie on hardware you bought for fault tolerance.
Do you have evidence that this is a fact? Have you looked at the computing requirements documents for, for example, stock exchanges?
I have it on good evidence that stock exchanges ran on mainframes. They are essentially the counterparty (in a computing sense not a financial sense) in each placed order.
If someone is willing to run a fiberoptic cable from Chicago to New York or New Jersey to exploit reduced propagation delay, admittedly much larger than a refresh stall, wouldn't you think that they or someone else would also be interested in predicting computing stalls. An exchange would face at least a significant reputational risk if it could be exploited that way.
Re: DRAM has a design flaw from 1966. I bypassed it [video]
#165Earlier quoted context omitted.
> clear spikes from 70ns to 330ns Isn't that rather trivial though as a source of tail latency? There's much worse spikes coming from other sources, e.g. power management states within the CPU and possibly other hardware. At the end of the day, this is why simple microcontrollers are still preferred for hard RT workloads. This work doesn't change that in any way.
Yeah exactly, and it’s absolutely dwarfed by the tail latency of going to DRAM in the first place. A cache miss is a 100x tail event vs. an L1 hit. The refresh stall is a further 5x on top of that, which barely registers if you’re already eating the DRAM cost.
It could be useful for large data set lookups where you're still limited to largely commodity hardware.
Not sure how ~2-8x hardware costs needed to implement this reasonably would compare with costs of specialized hardware.
Re: DRAM has a design flaw from 1966. I bypassed it [video]
#166Earlier quoted context omitted.
It is not only not practical, it is a completely useless technique. I got downvoted to negative infinity for mentioning this, but I guess I am the only person who actually read the benchmark. The reason the technique "works" in the benchmark is that all the threads run free and just record their timestamps. The winner is decided post hoc. This behavior is utterly pointless for real systems. In a real system you need…
You got downvoted for being an asshole, and if you continue to be an asshole on HN we are going to ban you. I suppose you don't believe this because we haven't done it yet even after countless warnings: https://news.ycombinator.com/item?id=43850950 (April 2025) https://news.ycombinator.com/item?id=43847946 (April 2025) https://news.ycombinator.com/item?id=42096833 (Nov 2024) https://news.ycombinator.com/item?id=37275…
[flagged]
Re: DRAM has a design flaw from 1966. I bypassed it [video]
#167This 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…
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? Up…
I think Laurie is still trying to develop her style. She's been at it for just a few years and her delivery greatly improved over that time span. Not a fan (yet?), but I've seen a few of her videos from different time periods.
Perhaps she or someone on her team (the camera work suggests at least a +1) thinks that this geeky/ditsy persona gets more clicks. Other successful YTers behave similarly. I don't find it useful or entertaining, but others might.
Having said this, I, myself, would've liked the video to be a bit more succinct
Re: DRAM has a design flaw from 1966. I bypassed it [video]
#168This is so cool! One thing that occurred to me while watching the video: would it potentially make more sense to just do this in the kernel? That way, you don't have to fight virtual addressing, and I imagine (?) you could even know for sure which channel you're on instead of guessing.
Re: DRAM has a design flaw from 1966. I bypassed it [video]
#169Earlier quoted context omitted.
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? Up…
FYI if you have a video you can't be bothered watching but would like to know the details you have 2 options that I use (and others, of course): 1. Throw the video into notebooklm - it gives transcripts of all youtube videos (AFAIK) - go to sources on teh left and press the arrow key. Ask notbookelm to give you a summary, discuss anything etc. 2. Noticed that youtube now has a little Diamond icon and "Ask" next to it…
I don't want an AI summary, I just want the author to write concisely, and hopefully make a text post instead of a video.
Re: DRAM has a design flaw from 1966. I bypassed it [video]
#170Earlier quoted context omitted.
The video definitely wouldn't be over 50m if she was targeting views. 11m -15m is where you catch a lot of people repeating and bloviating 3m of content to hit that sweet spot of the algorithm. It's sad you can't appreciate when someone puts passion into a project. This is the damage AI does to society. It robs talented people of appreciation. A phenomenal singer? Nah she just uses auto tune obviously. Great speech?…
Yes, I do want the summary because my time is (also) valuable. There is a reason why book covers have synopses, to figure out whether it's worth reading the book in the first place.
In this case the useful info in the book could be distilled down to the cover blurb.
This video really should have been two videos anyway. One to describe how DRAM works (old hat to some of us nerds, but interesting and new to lots of others), and the second one to explain how she got around the refresh interval. Then nerds could skip the first one completely. In reality the two videos could be about 5 minutes each.