Hacker News Reader

Comment by bhouston | Hacker News Reader

2023/2024 I suspect you meant to write.

I do like the fact that SSD bandwidth may be approaching memory bandwidth.

SSD bandwidth is not really approaching modern memory bandwidth - a computer with one of these will probably have 4 to 8 channels of DDR4 at 25GB/s each with DDR5 released about a year ago. That is 100GB/s to 200GB/s currently and more by the time PCIe 5 becomes a reality.

I am sure if you go back a few years you can find systems that have the same or less memory bandwidth than this has now, but they have both been moving forward enough that SSDs are still not close. That being said, between bandwidth and random access times, swapping out to disk backed virtual memory is very pragmatic and isn't the death of performance it used to be.

I think a fairer comparison would be 1 DDR channel to one SSD, or comparing the 8 channels to a multi-SSD striped RAID array. SSDs are ~7GB/sec, so I would say that SSD bandwidth is roughly within one or two orders of magnitude slower than RAM. I certainly wouldn't want to replace an app optimized to use all the RAM on a machine with one running on a lower-RAM SSD machine, though.

Maybe I'm old. I never used to think that an application that is able to use my whole ram is optimized. It evokes exactly the opposite impression, indeed.

I think I understand what you mean, but the gut reaction is that one.

Yeah, I am really old, after all.

Edit: let me explain. Something that is able to use the whole space of a flat memory model is way less sophisticated than something that is able to deal with a complex memory hierarchy. Our machines are indeed a complex pyramid of different subsystems with varying bandwidth and latency characteristics. A program that is able to embrace the inherent hierarchical nature of our machines (or multi-node systems) is way more "optimized", according to my sensibility.

I'm talking about situations like search, where you hold the entire index in ram. Total # of machines = size of index / indexserver ram. Usually the apps that run on these have, say, 96 cores and they're using about 80, and the idle time is mostly instructions waiting for memory fetches.

Typically that index fronts a disk repository which wouldn't fit in RAM, although over time, what fit in RAM, what fit in disk, what lived in RAM, what got cached in RAM, etc, have changed over time.

BTW, I'm probably of the same generation as you and the single most important lesson I ever learned for computing performance was "add more RAM"; in the days when I first started using Linux with 4MB of RAM, it wasn't enough to do X11, g++ and emacs all at the same time without swapping, so I spent my hard-earned money to max out the RAM, at which point it didn't swap and I could actually do software development quickly.

If you have 8 of these on a single system, you are getting very close to RAM bandwidth. Still, there is issue of latency and TBW.

Now if we could just make a Beowulf cluster of these...

Beowulf, that is a name i haven't heard in a long time.

It really depends on the type of memory usage though. On current Intel multi-socket the bandwidth a single process can have for core meditated memory accesses, even for node local memory, is seriously disappointing. Often < 10GB/s. Yes, it scales reasonably nicely, but it's very painful to tune for that, given that client and low core count, single socket, SKUs end up with > 35GB/s. And that this affects you even from within VMs that are on a single socket.

I heard that ice lake sp improves a bit in the area, but haven't gotten access to one yet.

IMO disk tech of 25 GB/s vs 100 GB/s for memory counts as approaching.

Where are you getting 25 GB/s of disk speed?

>2023/2024 I suspect you meant to write.

ROFL. Thanks. Keep thinking about the good old days.

Reply on news.ycombinator.com