I look forward to the point where 3/4 of business application code will go the trash when we'll have a persistant memory with the latency of actual RAM disk (Memristor !!). Exit all that "copy from RAM to Disk/Network" code.
It will definitely change the way we code and look at code. That's why nowadays I think a good interface to your entities, like the Repository pattern, is a must have.
Bringing SSD Performance to the DIMM form factor
41–50 of 205 posts
Re: Bringing SSD Performance to the DIMM form factor
#42Earlier quoted context omitted.
Maybe it helps if you have much data to process and don't need to move it from disk to RAM anymore. Everything can be done in RAM.
Except that it is 20,000 times slower than RAM.
But still faster than swapping to disk. You would also benefit from the increased throughput.
Re: Bringing SSD Performance to the DIMM form factor
#43Is the advantage the low latency because the rest of the specifications seem to be pretty standard for an SSD. Does this require a BIOS patch of some sort?
If it behaves like RAM, from the POV of the OS, I'd imagine the advantage to be the large size. There's also the fact that it won't lose its data on power loss. Of course, if it behaves like a regular SSD, the read speeds still exceed SATA3.0 speed.
> There's also the fact that it won't lose its data on power loss.
Does this mean that for software to take full advantage of this, the software will need to be updated to account for it? For instance, Redis loads data into memory from disk upon starting, but if something like this 400GB SSD is available as memory (and say for instance, 300GB is in use by Redis), wouldn't it make sense for Redis, upon starting, to just "remember" the state of the memory rather than reloading it from disk?
Re: Bringing SSD Performance to the DIMM form factor
#44I 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.
Memristors (long promised and still not quite here) also bring together the ideas of long-term and short-term memory into one and, in future incarnations, even promise to bring computation and storage together.
You can get that today with FRAM, although not at high density. TI do microcontroller eval boards with built in FRAM; you can have your device resume automatically from power loss with all its memory still there.
Re: Bringing SSD Performance to the DIMM form factor
#45Earlier quoted context omitted.
I doubt that will happen ever, there's always a tradeoff between cost, speed and space (on the die, ...), otherwise we'd all be running machines with 1TB L1 Cache.
Just because we've had to make tradeoffs so far does not mean these tradeoffs will always exist. Tradeoffs like these are not a natural law.
Yes they are, because the storage isn't arbitrarily small. There is always the latency of distance to overcome. That includes the centimeters to your main memory. There's always going to be a capacity-latency tradeoff.
Re: Bringing SSD Performance to the DIMM form factor
#46I 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.
Memristors (long promised and still not quite here) also bring together the ideas of long-term and short-term memory into one and, in future incarnations, even promise to bring computation and storage together.
When they work (there is to much cash on the table for them not too), they'll completely change the way we think of volatile and non-volatile memory. Since all memory will be non-volatile.
It'll be a huge paradigm shift in storage and IO speed.
Re: Bringing SSD Performance to the DIMM form factor
#47I look forward to the point where 3/4 of business application code will go the trash when we'll have a persistant memory with the latency of actual RAM disk (Memristor !!). Exit all that "copy from RAM to Disk/Network" code. It will definitely change the way we code and look at code. That's why nowadays I think a good interface to your entities, like the Repository pattern, is a must have.
I work on an application that was originally designed to persist transactions to battery backed SRAM. It's still full of "business logic", because that's where all the value is. Copying data around really doesn't consume that much time and effort; performing logical, semantic or administrative transformation on it does.
Re: Bringing SSD Performance to the DIMM form factor
#48I look forward to the point where 3/4 of business application code will go the trash when we'll have a persistant memory with the latency of actual RAM disk (Memristor !!). Exit all that "copy from RAM to Disk/Network" code. It will definitely change the way we code and look at code. That's why nowadays I think a good interface to your entities, like the Repository pattern, is a must have.
It will definitely change the way we code
Re: Bringing SSD Performance to the DIMM form factor
#49This is pretty cool, especially since the data is persistent. You could put an entire data warehouse onto one or of a couple of these things, update it once a week and get amazing response time.
But I thought the main drawback of SSDs was that eventually the individual memory cells will degrade and lose the ability to write new data. I don't see anything about endurance other than a MTBF of 2.5 million hours and the disk-writes-per-day (DWPD), which I had to look up. I have no idea if these are good or bad. I feel like these things will be great if you didn't write new data a lot, or you have deep pockets to replace them when you need to.