Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

youtube.com

Post reply on HN
Print view View original

61–70 of 174 posts

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

#61

Post by josephg »

kreelman wrote: post #4

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…

I hope this approach gets some visibility in the CPU field. It could be obviously improved with a special cpu instruction which simply races two reads and returns the first one which succeeds. She’s doing an insane amount of work, making multiple threads and so on (and burning lots of performance) all to work around the lack of dedicated support for this in silicon.

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

#62

Post by v1ne »

rcbdev wrote: post #14

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

I think it's more people being fascinated by this curious architectural detail. I imagine it's fascinating to people who are not exposed to the intricate details of computer architecture, which I assume is the vast majority here. It's a glimpse into a very odd world (which is your day-to-day work in the HFT field, but they rarely talk about this, and much less in such big words).

TBH, I didn't watch the video because the title is too click-baity for me and it's too long. Instead, I looked at the benchmark results on the Github page and sure, it's fascinating how you can significantly(!) thin the latency distribution, just by using 10× more CPU cores/RAM/etc. Classic case of a bad trade-off.

And nobody talked about what we use RAM for, usually: Not to only store static data, but also to update it when the need arises. This scheme is completely impractical for those cases. Additionally, if you really need low latency, as others pointed out, you can go for other means of computation, such as FPGAs.

So I love this idea, I'm sure it's a fun topic to talk about at a hacker conference! But I'm really put off by the click-baity title of the video and the hype around it.

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

#63

Post by wkjagt »

tredre3 wrote: post #21
rcbdev wrote: 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...

I have become oversensitive to this, and my brain is probably generating a lot of false positives. I don't think it's necessarily the case here, but I've wondered if people who use LLMs a lot take over some of its idiosyncrasies and in a way start sounding like one a bit. A strange side effect is that I've come to appreciate text with grammatical errors, videos where people don't enunciate well etc because it's a sign that it's human created content.

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

#64

Post by josephg »

foltik wrote: 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…

It could be massively improved with a special CPU instruction for racing dram reads. That might make it actually useful for real applications. As it is, the threading model she used here would make it incredibly difficult to use this in a real program.

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

#65

Post by saidnooneever »

fc417fc802 wrote: post #51
svrtknst wrote: post #50

Earlier quoted context omitted.

Unnecessarily negative imo. I like the video because I cant read a blog post in the background while doing other stuff, and I like Gadget Hackwrench narrating semi-obscure CS topics lol

> I cant read a blog post in the background You can consume technical content in the background?

this is a thing people do. convince themselves they can consume technical content subconsciously. its now how the brain works though. it will just give you the idea you are following something.

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

#66

Post by dspillett »

satvikpendem wrote: post #35
throwaway81523 wrote: post #32

Earlier 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…

Just use the Ask button on YouTube videos to summarize, that's what it's for.

Not complaining about the particular presenter here, this is an interesting video with some decent content, I don't find the presentation style overly irritating, and it is documenting a lot of work that has obviously been done experimenting in order to get the end result (rather than just summarising someone else's work). Such a goofy elongated style, that is infuriating if you are looking for quick hard information, is practically required in order to drive wider interest in the channel.

But the “ask the LLM” thing is a sign of how off kilter information passing has become in the current world. A lot of stuff is packaged deliberately inefficiently because that is the way to monetise it, or sometimes just to game the searching & recommendation systems so it gets out to potentially interested people at all, then we are encouraged to use a computationally expensive process to summarise that to distil the information back out.

MS's documentation the large chunks of Azure is that way, but with even less excuse (they aren't a content creator needing to drive interest by being a quirky presenter as well as a potential information source). Instead of telling me to ask copilot to guess what I need to know, why not write some good documentation that you can reference directly (or that I can search through)? Heck, use copilot to draft that documentation if you want to (but please have humans review the result for hallucinations, missed parts, and other inaccuracies, before publishing).

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

#68

Post by gkbrk »

ahoka wrote: post #52
bronlund wrote: post #28

She could probably have been stinking rich on this work alone, but instead she just put it up on Github. Kudos to Laurie.

Companies are standing in line to double their RAM usage right now, right.

Depends how much total RAM your application needs and how much money RAM access tail latency costs your business.

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

#69

Post by kzrdude »

GeneralMayhem wrote: post #33
rockskon wrote: post #15

Earlier quoted context omitted.

She determines that by having three copies. Or four. Or eight. Tis just probabilities and unlikelihood of hitting a refresh cycle across that many memory channels all at once.

Right, but the impressive part is finding addresses that are actually on different memory channels.

Surprising to me that two memory channels are separated by as little as 256 bytes. The short distance makes it easier to find, surely?

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

#70

Post by kzrdude »

UltraSane wrote: post #10
ufocia wrote: post #7

Earlier quoted context omitted.

I like the video, but this is hardly groundbreaking. You send out two or more messengers hoping at least one of them will get there on time.

The clever part is figuring out what RAM is controlled by which controllers.

I have to say that using drawbridges and differently colored rail pieces to explain it was very clever.
Post reply on HN