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

51–60 of 174 posts

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

#51

Post by fc417fc802 »

svrtknst wrote: post #50
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…

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?

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

#53

Post by 100ms »

why_only_15 wrote: post #39
100ms wrote: post #36

Earlier quoted context omitted.

> 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

This is a quite old technique. The idea, as I understood it, was that lots of data at Google was stored in triplicate for reliability purposes. Instead of fetching one, you fetched all three and then took the one that arrived first. Then you sent UDP packets cancelling the other two. For something like search where you're issuing hundreds of requests that have to resolve in a few hundred milliseconds, this substantia…

Aha that makes more sense, I thought it was specifically to do with job scheduling from the description. You can do something similar at home as a poor man's CDN by racing requests to regionally replicated S3 buckets. Also magic eyeballs (ipv4/v6 race done in browsers and I think also for Quic/HTTP selection) works pretty much the same way

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

#55

Post by fc417fc802 »

sbiru93 wrote: post #46

Doesn't doing this halve the computing power? I don't know this world at all, is that acceptable?

It halves (or thirds or quarters or etc) available CPU cores, cache space, memory bandwidth, all the critical resources. So I expect that it's only applicable for small reads that you are reasonably certain won't be in cache and that it can only be used extremely sparingly, otherwise it will be nothing but a massive drain.

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

#56

Post by fc417fc802 »

guenthert wrote: post #48
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.

Well he veered off of the technical and into the personal so I'm not surprised it's dead. But yeah something feels weird about this comment section as a whole but I can't quite put my finger on it.

I think rather than AI it reminds me of when (long before AI) a few colleagues would converge on an article to post supportive comments in what felt like an attempt to manipulate the narrative and even at concentrations that I find surprisingly low it would often skew my impression of the tone of the entire comment section in a strange way. I guess you could more generally describe the phenomenon as fan club comments.

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

#57

Post by alex_duf »

fc417fc802 wrote: post #47
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…

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

it's explained in the video, and there's no way I'll be explaining it better than her

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

#58

Post by kelsolaar »

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…

The video could be a shorter, some of the goofiness might not please the most pressed people but that is also what makes it fresh and stand out.

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

#59

Post by tromp »

A more accurate but less inspiring title would be:

RAM Has a Design Tradeoff from 1966. I made another one on top.

The first tradeoff, of 6x fewer transistors for some extra latency, is immensely beneficial. The second, of reducing some of that extra latency for extra copies of static data, is beneficial only to some extremely niche application. Still a very educational video about modern memory architecture.

[EDIT: accidental extra copy of this comment deleted]

Post reply on HN