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

41–50 of 174 posts

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

#41

Post by tastroder »

100ms wrote: post #36
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…

> Google's strange job optimisation technique (for jobs running on hard disk storage) Can you give more context on this? Opus couldn't figure out a reference for it

https://cacm.acm.org/research/the-tail-at-scale/ (hedged / tied requests)

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

#42

Post by yalogin »

This is a cool idea, very well put through for everyone to understand such an esoteric concept.

However I wonder if the core idea itself is useful or not in practice. With modern memory there are two main aspects it makes worse. First is cost, it needs to double the memory used for the same compute. With memory costs already soaring this is not good. Then the other main issue of throughout, haven’t put enough thought into that yet but feels like it requires more orchestration and increases costs there too.

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

#44

Post by actionfromafar »

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

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.

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

#45

Post by guenthert »

boznz wrote: post #8

Should say DRAM, SRAM does not have this.

Indeed. And only for certain DRAM refresh strategies. I mean, it's at least conceivable that a memory management system responsible for the refresh notices that a given memory location is requested by the cache and then fills the cache during the refresh (which afaiu reads the memory) or -- simpler to implement perhaps -- delays the refresh by a μs allowing the cache-fill to race ahead.

(seems that in the earlier submission, https://news.ycombinator.com/item?id=47680023, jeffbee hinted that IBM zEnterprise is doing something to that effect)

Said that, I'm not convinced that this is a big issue in practice. If you really care about performance, you got to avoid cache misses.

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

#47

Post by fc417fc802 »

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…

> using (undocumented!) channel scrambling offsets that works on AMD, Intel, and Graviton

Seems odd to me that all three architectures implement this yet all three leave it undocumented. Is it intended as some sort of debug functionality or what?

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

#48

Post by guenthert »

rcbdev wrote: post #14

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

No, something is funny here. In the previous submission (https://news.ycombinator.com/item?id=47680023) the only (competently) criticizing comment (by jeffbee) was downvoted into oblivion/flagged.

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

#49

Post by saidnooneever »

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.

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 there provided by firmware or platform?

i can hardly imagine it is not just plainly in there with the plethtora info in there...

theres srat/slit/hmat etc. in acpi, then theres MSRs with info (amd expose more than intel ofc, as always) and then there is registers on memory controller itself as well as socket to socket interconnects from upi links..

its just a lot of reading and finding bits here n there. LLms are actually really good at pulling all sorts of stuff from various 6-10k page documents if u are too lazy to dig yourself -_-

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

#50

Post by svrtknst »

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…

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

Post reply on HN