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

131–140 of 174 posts

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

#131

Post by xpct »

derbOac wrote: post #84
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

FWIW, I like her videos but I usually prefer essays or blog posts in general as they're easier to scan and process at my own rate. It's not about this particular video, it's about videos in general.

I get a similar feeling for when friends send me 2minute+ Instagram reels, it's as if my brain can't engage with the content. I'd much rather read a few paragraphs about the topic, and It'd probably take less time too.

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

#134

Post by dang »

jeffbee wrote: post #129
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 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=37275963 (Aug 2023)

https://news.ycombinator.com/item?id=35746140 (April 2023)

https://news.ycombinator.com/item?id=34537078 (Jan 2023)

https://news.ycombinator.com/item?id=33914274 (Dec 2022)

https://news.ycombinator.com/item?id=33311881 (Oct 2022)

https://news.ycombinator.com/item?id=30890360 (April 2022)

https://news.ycombinator.com/item?id=26628758 (March 2021)

https://news.ycombinator.com/item?id=26307811 (March 2021)

https://news.ycombinator.com/item?id=25561372 (Dec 2020)

https://news.ycombinator.com/item?id=24724281 (Oct 2020)

https://news.ycombinator.com/item?id=24458954 (Sept 2020)

https://news.ycombinator.com/item?id=24380545 (Sept 2020)

https://news.ycombinator.com/item?id=23170477 (May 2020)

The reason we haven't banned you yet is because you obviously know a lot of things that are of interest to the community. That's good. But the damage you cause here by routinely poisoning the threads exceeds the goodness that you add by sharing information. This is not going to last, so if you want not to be banned on HN, please fix it.

https://news.ycombinator.com/newsguidelines.html

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

#135

Post by dspillett »

gosub100 wrote: post #99
dspillett wrote: post #66

Earlier quoted context omitted.

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…

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

> It's sad you can't appreciate when someone puts passion into a project.

It is sad that read comprehension is dropping such that you interpreted my comment that way.

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

#136

Post by jeffbee »

josephg wrote: post #64
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.

There are already systems that do this in hardware. Any system that has memory mirroring RAS features can do this, notably IBM zEnterprise hardware, you know, the company that this video promoter claims to be one-upping.

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

#137

Post by sodaplayer »

dwoldrich wrote: post #115

Voxel Space[1] could have used this, would that multicore had been prevalent at the time. I recall being fascinated that simply facing the camera north or south would knock off 2fps from an already slow frame rate. Many of our maps' routes would be laid out in a predominately east or west-facing track to max out our staying within cache lines as we marched our rays up the screen. So, we needed as much main memory ban…

>Many of our maps' routes would be laid out in a predominately east or west-facing track

That's fascinating to find out! I grew up a fan of Nova Logic, so I'll have to pay attention to this the next time I revisit their games.

Was this done for Comanche or did you also do this for Delta Force?

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

#138

Post by deegu »

strongpigeon wrote: post #127
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…

> At a high level it’s a bit contradictory; trying to reduce the tail latency of cold reads by doubling the cache footprint makes every other read even colder. That’s my main hang up as well. On one hand this is undeniably cool work, but on the other, efficient cache usage is how you maximize throughput. This optimizes for (narrow) tail latency, but I do wonder at what performance cost. I would be super interested in…

This might be useful in a case where a small lookup or similar is often pushed out from cache such that lookups are usually cold. Yet lookup data might by small enough to not cause issue with cache pollution, increased bandwidth or memory consumption.

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

#139

Post by shiftingleft »

jeffbee wrote: post #136
josephg wrote: post #64

Earlier quoted context omitted.

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.

There are already systems that do this in hardware. Any system that has memory mirroring RAS features can do this, notably IBM zEnterprise hardware, you know, the company that this video promoter claims to be one-upping.

I don't think memory mirring features available today allow you to race two DRAM accesses and use the result that returns earlier?

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

#140

Post by drooopy »

freedomben wrote: post #102

LaurieWired is so incredibly smart, and so incredibly nerdy :-D Really enjoyed this video, and I'm pretty picky. I learned a lot, even though I already know (or thought I knew) quite a bit about this subject as it was a particular interest of mine in Comp Sci school. I highly recommend. Skip forward through chunks of the train part though where she is messing around. It does get more informative later though so don't…

She and Technology Connections are two of my favourite YouTube channels. Also I love her geocities website so much: https://lauriewired.com/
Post reply on HN