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

111–120 of 174 posts

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

#111

Post by scrollop »

throwaway81523 wrote: post #32
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…

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 between the Share icon and Save icon. This brings up gemini and you can ask questions about the video (it has no internet access). This may be premium only. I still prefer Claude for general queries over Gemini.

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

#112

Post by scrollop »

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.

Or give the video to notebooklm - you can also get the trasncript (unformatted) using this technique

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

#113

Post by YesThatTom2 »

throwaway81523 wrote: post #32
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…

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…

[flagged]

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

#114

Post by sumeno »

saidnooneever wrote: post #49
UltraSane wrote: post #10

Earlier quoted context omitted.

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

everyone says this but no one says why it was clever. i find her videos have cool results but i cant have patience for them usually because its recycled old stuff (can be cool but its not ground breaking). there is a ton of info you can pull from: smbios, acpi, msrs, cpuid etc. etc. about cpu/ram topology and connecticity, latencies etc etc. isnt the info on what controllers/ram relationships exists somewhere in ther…

It's very funny that you're giving a RTFM response to a video you admit you didn't watch.

WTFV

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

#115

Post by dwoldrich »

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 bandwidth as we could get. I remember experimenting with cache line warming to try to keep the memory controllers saturated with work with measurable success. But it would have been difficult in Voxel Space to predict which lines to warm (and when), so nothing came of it.

Tailslayer would have given us an edge by just splitting up the scene with multiprocessing and with a lot more RAM usage and without any other code. Alas, hardware like that was like 15 years in the future. Le sigh.

[1] https://en.wikipedia.org/wiki/Voxel_Space

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

#116

Post by cestith »

weinzierl wrote: post #74
gopalv wrote: post #12

Earlier quoted context omitted.

>> It replicates data across multiple, independent DRAM channels with uncorrelated refresh schedules This is the sort of thing which was done before in a world where there was NUMA, but that is easy. Just task-set and mbind your way around it to keep your copies in both places. The crazy part of what she's done is how to determine that the two copies don't get get hit by refresh cycles at the same time. Particularly…

"This is the sort of thing which was done before in a world where there was NUMA" You sound like NUMA was dead, is this a bit of hyperbole or would really say there is no NUMA anymore. Honest question because I am out if touch.

EPYC chips have multiple levels of NUMA - one across CCDs on the one chip, and another between chips in different motherboard sockets. As a user under Linux you can treat it as if it was simple SMP, but you’ll get quite a bit less performance.

Home PCs don’t do NUMA as much anymore because of the number of cores and threads you can get on one core complex. The technology certainly still exists and is still relevant.

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

#118

Post by foltik »

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’s no point racing DRAM reads explicitly. Refreshes are infrequent and the penalty is like 5x on an already fast operation, 1% of the time.

What’s better is to “race” against cache, which is 100x faster than DRAM. CPUs already of do this for independent loads via out-of-order execution. While one load is stalled waiting for DRAM, another can hit the cache and do some compute in parallel. It’s all already handled at the microarchitectural level.

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

#119

Post by satvikpendem »

scrollop wrote: post #112
satvikpendem wrote: post #35

Earlier quoted context omitted.

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

Or give the video to notebooklm - you can also get the trasncript (unformatted) using this technique

If you just want the transcript, there is a Show Transcript button in the video description.

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

#120

Post by foltik »

zozbot234 wrote: post #92
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…

> 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.
Post reply on HN