Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Bringing SSD Performance to the DIMM form factor

sandisk.com.br

Post reply on HN
Print view View original

141–150 of 205 posts

Re: Bringing SSD Performance to the DIMM form factor

#141

Post by gtk40 »

avn2109 wrote: post #118
j_s wrote: post #99

Earlier quoted context omitted.

I will archive this thread to save this: > 1TB of non-volatile storage [...] Most average consumers won't use all of that

Seriously this. Don't worry, Windows 11 will certainly require 1TB to run MaterialAeroMetro 2022. The only thing worth debating is whether the GUI design pendulum will have swung between Flat/glossy an even or odd number of times by then :p

Windows minimum system requirements haven't changed since Windows Vista in 2006, up to Windows 10 technical preview.

Re: Bringing SSD Performance to the DIMM form factor

#142

Post by jacquesm »

hrjet wrote: post #132
maxidog wrote: post #77

Earlier quoted context omitted.

Is that fundamentally different from http://en.wikipedia.org/wiki/Memory-mapped_file ?

I was just thinking about this the other day. Yes, a memory-mapped-file is different, because the API is still that of a file. The memory mapping is just a behind-the-scenes optimisation.

Only if you want posix compliance across threads and such. If you just want the contents of the file memory mapped nothing stops you from setting up a shared memory segment and mapping it without that filesystem overhead.

Re: Bringing SSD Performance to the DIMM form factor

#143

Post by com2kid »

vidarh wrote: post #103
userbinator wrote: post #79

The capacities are very odd - you'd expect something in a DIMM format to have a power-of-2 size. I think the market for this could be much bigger if it behaved like a regular RAM DIMM, only slower and nonvolatile; it somewhat reminds me of old machines that used magnetic core RAM. This could be useful for laptops, like a zero-power suspend-to-(NV)RAM. The only thing that is worrying is the endurance of the flash - es…

It's still way too slow to be treated as RAM. The performance they quote is equivalent to a mid to lower range PCIe SSD. For comparison, the stated read performance is 800MB/sec or so. Last time I checked - on ca. 8 year old hardware, we could read files from a RAM disk under Linux at a rate of about 6GB/sec. That's with the added overhead of the benchmark software running and going through a filesystem.

I wouldn't say that 800MB/s is slow.

http://en.wikipedia.org/wiki/PC133

I also wonder if that 880 is for just one slot filled up. If it is, then I wonder if you can parallelize to 4 slots for ~3.4GB/s.

At that point, I imagine many types of data sets would work A-OK.

Though I wonder how that's scaled for cores, given that in the situation I imagined above, you'd be streaming all that data to just one CPU to get that aggregate bandwidth.

Hmm.

OK what about some other scenarios? Being able to have RAM and Storage on a sliding partition is sort of cool. I wonder if it'd make provisioning VMs any easier. "How much RAM do you want? Set the slider!"

Re: Bringing SSD Performance to the DIMM form factor

#144

Post by itchyouch »

IgorPartola wrote: post #137

This is sort of the opposite of the RAM-based battery backed drives [1]. I can see this being immediately useful for things like large database servers: instead of re-priming caches on reboots you just have them already warmed up. You can also suddenly have a whole lot more "RAM" at the cost of its speed. I do have a hard time picturing what this will look like if it was as fast as traditional RAM. If I can store eve…

While block devices can go away, the notion of a file will probably continue to remain.

We run clusters of ephemeral linux hosts, and while we use disk, we also have plenty of hosts that run diskless. The disk mount point just becomes a tmpfs mount and the required minimal installation is made on a tmpfs partition which amounts to a trivial amount for hosting busybox and some conf files in /etc. Linux does appear to understand that tmpfs backed filestores are already in memory and do not need to synchronize pages and flush out dirty pages. That whole caching/memory layer for this fake block device is just not used at all.

Re: Bringing SSD Performance to the DIMM form factor

#145

Post by Symmetry »

chongli wrote: post #110
userbinator wrote: post #83

Earlier quoted context omitted.

Tradeoffs like these are not a natural law They are, they're the laws of physics. According to known theories information cannot travel faster than the speed of light, so unless a very very radical new discovery is made sometime in the future, size and speed will basically be inversely proportional to each other.

The laws of physics don't dictate what technologies we know, only what their ultimate limits are. Just because our current memory technologies have some limitations that force us to make a tradeoff does not mean this will always be the case. Just look back at how things were before the discovery of GMR[0]. We had very different tradeoffs then as compared to now. [0] http://en.wikipedia.org/wiki/Giant_magnetoresistanc…

As long as we care about computational latency, the forces that give rise to caching will continue to hold force. The speed of light places a fundamental limit on the response time from a storage system of a given physical volume, and there are equivalent physical laws on the maximum amount of information that can be stored in that volume.

Which technologies we use for our caches and main storages will change, but we're never going to get around the need for caching.

Re: Bringing SSD Performance to the DIMM form factor

#147

Post by IgorPartola »

itchyouch wrote: post #144
IgorPartola wrote: post #137

This is sort of the opposite of the RAM-based battery backed drives [1]. I can see this being immediately useful for things like large database servers: instead of re-priming caches on reboots you just have them already warmed up. You can also suddenly have a whole lot more "RAM" at the cost of its speed. I do have a hard time picturing what this will look like if it was as fast as traditional RAM. If I can store eve…

While block devices can go away, the notion of a file will probably continue to remain. We run clusters of ephemeral linux hosts, and while we use disk, we also have plenty of hosts that run diskless. The disk mount point just becomes a tmpfs mount and the required minimal installation is made on a tmpfs partition which amounts to a trivial amount for hosting busybox and some conf files in /etc. Linux does appear to…

That's right, we already have a filesystem backed by RAM: tmpfs. Except now it's no longer so tmp. I suppose then yes we don't have to do much in the way of emulating block devices: just run tmpfs or it's later revisions and know that everything is permanent. In that case, this is not much of a leap for the current OS's to support it, which is great. I wonder if this means that theoretically mmap() can become a one liner now.

Re: Bringing SSD Performance to the DIMM form factor

#149

Post by 13 »

IgorPartola wrote: post #137

This is sort of the opposite of the RAM-based battery backed drives [1]. I can see this being immediately useful for things like large database servers: instead of re-priming caches on reboots you just have them already warmed up. You can also suddenly have a whole lot more "RAM" at the cost of its speed. I do have a hard time picturing what this will look like if it was as fast as traditional RAM. If I can store eve…

I do wish the iRam had stuck around longer. The 4GB limit makes it practically useless today, but a modern version of the same would be incredibly useful for some workloads.

Re: Bringing SSD Performance to the DIMM form factor

#150

Post by sjtrny »

amalag wrote: post #55
NamTaf wrote: post #3

I can't wait to see the programming paradigm of memory vs permanent storage begin to blur in the next 5 or so years. It's going to make some major assumptions about how you program stuff change quite significantly and it's really exciting.

And AMD is aiming towards a shared GPU/CPU architecture too.

I'm really excited for shared RAM between GPU and CPU. At the moment GPU acceleration is limited by the meagre amount of VRAM on most desktop cards. I would love to be able to do GPU programming with a 32+GB RAM pool.
Post reply on HN