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

141–150 of 174 posts

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

#141

Post by MisterTea »

kitku wrote: post #72
tromp wrote: post #59

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

It could be a display bug on my side, but you posted this exact comment twice.

This comment was the faster of the two comments and therefor won. The other was simply discarded.

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

#142

Post by jeffbee »

shiftingleft wrote: post #139
jeffbee wrote: post #136

Earlier quoted context omitted.

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?

The memory controller sends the read to the DIMM that is not refreshing. It is invisible to software, except for the side-effect of having better performance.

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

#143

Post by PinkSheep »

kzrdude wrote: post #69
GeneralMayhem wrote: post #33

Earlier quoted context omitted.

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?

Access optimization or interleaving at a lower level than linearly mapping DIMMs and channels. x86 cache lane size is 64 bytes, so it must be a multiple. Probably 64*2^n bytes.

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

#144

Post by foltik »

deegu wrote: post #138
strongpigeon wrote: post #127

Earlier quoted context omitted.

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

In this case it’s better to asynchronously bring the data into the cache, which you can do with a prefetch shortly before the read.

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

#145

Post by CamperBob2 »

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

I don't consider AI to threaten "damage to society" the way you seem to, but I did find it interesting to think about how ridiculously well-produced the video was, and what that might signify in the future.

I kept squinting and scrutinizing it, looking for signs that it was rendered by a video model. Loss of coherence in long shots with continuity flaws between them, unrealistic renderings of obscure objects and hardware, inconsistent textures for skin and clothing, that sort of thing... nope, it was all real, just the result of a lot of hard work and attention to detail.

Trouble is, this degree of perfection is itself unrealistic and distracting in a Goodhart's Law sense. Musicians complain when a drum track is too-perfectly quantized, or when vocals and instruments always stay in tune to within a fraction of a hertz, and I do have to wonder if that's a hazard here. I guess that's where you're coming from? If you wanted to train an AI model to create this type of content, this is exactly what you would want to use as source material. And at that point, success means all that effort is duplicated (or rather simulated) effortlessly.

So will that discourage the next-generation of LaurieWireds from even trying? Or are we going to see content creators deliberately back away from perfect production values, in order to appear more authentic?

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

#147

Post by spockz »

vitus wrote: post #82
100ms wrote: post #53

Earlier quoted context omitted.

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

> magic eyeballs https://en.wikipedia.org/wiki/Happy_Eyeballs is the usual name. It's not quite identical, since you often want to give your preferred transport a nominal headstart so it usually succeeds. But yes, there are some similarities -- you race during connection setup so that you don't have to wait for a connection timeout (on the order of seconds) if the preferred mechanism doesn't work for some reason. The…

Request hedging or backup requests are indeed the terms I know for requests where you give the first request a bit of a headstart. I didn’t know about the term happy eyeball to signify that all requests fire at the same time.

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

#148

Post by rationalist »

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…

As requested:

https://news.ycombinator.com/item?id=47713090

I agree, not everyone has 54 minutes to watch a video full of fluff (I tried, but only got so far, even on 1.5x speed).

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

#149

Post by intothemild »

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…

Man. You really don't get it do you.

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

#150

Post by tromp »

MisterTea wrote: post #141
kitku wrote: post #72

Earlier quoted context omitted.

It could be a display bug on my side, but you posted this exact comment twice.

This comment was the faster of the two comments and therefor won. The other was simply discarded.

I had to manually delete it.
Post reply on HN