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

151–160 of 174 posts

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

#151

Post by foltik »

jeffbee wrote: post #142
shiftingleft wrote: post #139

Earlier quoted context omitted.

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.

Mirroring is more of a reliability feature though, no? From my understanding it’s like RAID where you keep multiple copies plus parity so uncorrectable errors aren’t catastrophic. Makes sense for mainframes which need to survive hardware failures.

Refresh avoidance is a tangential thing the memory controller happens to be able to do in a scheme like that, but you’d really have to be looking at it in a vacuum to bill it as a benefit.

Like I said, it’s all about cache. You’re not going to DRAM if you actually care about performance fluctuations at the scale of refresh stalls.

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

#152

Post by jeffbee »

foltik wrote: post #151
jeffbee wrote: post #142

Earlier quoted context omitted.

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.

Mirroring is more of a reliability feature though, no? From my understanding it’s like RAID where you keep multiple copies plus parity so uncorrectable errors aren’t catastrophic. Makes sense for mainframes which need to survive hardware failures. Refresh avoidance is a tangential thing the memory controller happens to be able to do in a scheme like that, but you’d really have to be looking at it in a vacuum to bill…

Clearly, hitting a cache would be the better outcome. The technique suggested here could only apply to unavoidably cold reads, some kind of table that's massive and randomly accessed. Assume it exists, for whatever reason. To answer your question, refresh avoidance is an advertised benefit of hardware mirroring. Current IBM techno-advertising that you can Google yourself says this:

"IBM z17 implements an enhanced redundant array of independent memory (RAIM) design with the following features: ... Staggered memory refresh: Uses RAIM to mask memory refresh latency."

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

#153

Post by dwoldrich »

sodaplayer wrote: post #137
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?

I was just the lowly build-master/installer/utility developer, but I got tapped for testing and debugging and performance because I was just a sponge for coding knowledge because I wanted to be a game developer so baaaad at the time. I didn't get to do any of the game coding, and my experiments were just fruits of conversations with benevolent sages.

The reason facing east-west (or was it north-south, now I'm unsure) made such a difference in framerate was the color and height maps were ray marched in straight lines up from the bottom of the screen to the horizon. This meant you were zipping through the color map in straight lines, wrapping around to the other side if the ray went far enough.

When those straight lines lined up with the color and height map (north-south), life was good (and when a ray marched up a sheer canyon wall, life was VERY good.) But, when those straight lines went perpendicular (east-west) to the color and height map, you were blowing through the L2 cache constantly and going to main memory very often. I imagine on modern hardware these cache misses wouldn't amount to much measurable time, but on a 386dx with 8megs of RAM, the impact was very clear.

Novalogic was the only programming job I ever had where I got my own office with a door. ;) When I was with them, they had a policy of one game developer per game which I never saw again. Maximum cowboy coder energy, good times.

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

#154

Post by dwoldrich »

sodaplayer wrote: post #137
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?

Delta Force's programmer was really boss (Daniele Gaetano), a physics guy turned coder if I remember correctly. He rewrote Voxel Space to be true'ish 3D and not fakey 2.5D. He explained the innovative backtracking he had to do on the ray caster to make that work, implemented mipmaps in the voxels, very very clever guy. One of the friendlier guys I've known in videogames.

I did the first version of the matchmaking for the network play in Delta Force but didn't make it into the credits because I quit before it shipped. My psycho coworker built a custom web browser(!) that integrated directly with my from-scratch matchmaking server. At least they let me work in C for that project; most everything else I had to do for them was assembler because that was not a "sissy" programming language. That server code was by-far the coolest thing I wrote for many years afterward.

Unfortunately, my server code couldn't handle more than like 32 concurrents because the Windows NT 3.0 kernel would BSOD with more. My (extremely grumpy) manager and the Sega Saturn coder called me a few days after I had quit to ask how the code worked. I suspect I left data in the socket buffers too long (was trying to batch up my message broadcasting work at regular intervals) and the kernel panicked over that.

I recall learning later the TCP/IP stack was homegrown in NT by Microsoft at that time and they licensed a good one for later versions, so I can't be blamed, it wasn't me! :D

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

#155

Post by jayd16 »

I suppose hardware folks could cook up some kind of RAID 5 style striped RAM layout and utilize a hedging strategy. Write out parity, drop a late parity read instead of using it for error correction. You get better results than double the RAM needed with a striping strategy.

I guess this would have been a nice way to reduce HDD latency as a new RAID mode... oh well.

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

#156

Post by foltik »

jeffbee wrote: post #152
foltik wrote: post #151

Earlier quoted context omitted.

Mirroring is more of a reliability feature though, no? From my understanding it’s like RAID where you keep multiple copies plus parity so uncorrectable errors aren’t catastrophic. Makes sense for mainframes which need to survive hardware failures. Refresh avoidance is a tangential thing the memory controller happens to be able to do in a scheme like that, but you’d really have to be looking at it in a vacuum to bill…

Clearly, hitting a cache would be the better outcome. The technique suggested here could only apply to unavoidably cold reads, some kind of table that's massive and randomly accessed. Assume it exists, for whatever reason. To answer your question, refresh avoidance is an advertised benefit of hardware mirroring. Current IBM techno-advertising that you can Google yourself says this: "IBM z17 implements an enhanced red…

I can google, thanks. My point is that nobody is buying mainframes with redundant memory to avoid refresh stalls. It’s a mostly irrelevant freebie on hardware you bought for fault tolerance.

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

#158

Post by deegu »

foltik wrote: post #144
deegu wrote: post #138

Earlier quoted context omitted.

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.

Perhaps. Then again, if your target is to reduce dram refresh induced latency, you might not have time to prefetch either.

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

#159

Post by Jach »

tredre3 wrote: post #21
rcbdev wrote: post #14

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

No I felt the same way, they're exactly like the usual LLM bot comment where a LLM recap ops and ends with an platitude or witty encouragement. But all the accounts are old/legit so I think that you and me have just become paranoid...

I think part of it is that some of us are not used to reading (or writing) praise, apart from seeing the over-praising of LLMs, such that seeing praise in the wild makes us think of LLMs. This being used to lack of praise is partly reinforced by certain tech cultures (e.g. keeping ego out of code review, this implies not wasting time on personal praise/criticism but keeping remarks focused on the technical, and keeping in mind the distinction between technical and non-technical critique).

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

#160

Post by vitus »

spockz wrote: post #147
vitus wrote: post #82

Earlier quoted context omitted.

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

> I didn’t know about the term happy eyeball to signify that all requests fire at the same time.

It's not quite the same. Usually with Happy Eyeballs, you want to try multiple protocols (e.g. QUIC vs TCP, or IPv6 vs IPv4), and you have a preference for one over the other. As such, you try to establish your connection via IPv6, wait something like 30ms, then try to establish via IPv4. Whichever mechanism completes channel setup first wins, and you can cancel the other one.

It's a mechanism used to drive adoption of newer protocols while limiting the impact on end users.

Post reply on HN