Linked by Thom Holwerda on Sun 14th Apr 2013 20:30 UTC
Hardware, Embedded Systems "In the past five years, flash memory has progressed from a promising accelerator, whose place in the data center was still uncertain, to an established enterprise component for storing performance-critical data. It's rise to prominence followed its proliferation in the consumer world and the volume economics that followed. With SSDs, flash arrived in a form optimized for compatibility - just replace a hard drive with an SSD for radically better performance. But the properties of the NAND flash memory used by SSDs differ significantly from those of the magnetic media in the hard drives they often displace. While SSDs have become more pervasive in a variety of uses, the industry has only just started to design storage systems that embrace the nuances of flash memory. As it escapes the confines of compatibility, significant improvements in performance, reliability, and cost are possible."
Thread beginning with comment 558495
To read all comments associated with this story, please click here.
Comment by TempleOS
by TempleOS on Mon 15th Apr 2013 02:40 UTC
TempleOS
Member since:
2013-04-03

I haven't thought about but wouldn't a lot change? I have a text/graphics file format in my operating system -- think PDF. When I load it from disk, I put it in a doubly-linked list memory structure. If RAM was RAM, I could just store it, as long as I didn't move it. (Work with me, I'm exploring possibilities.)

Reply Score: 0

RE: Comment by TempleOS
by ssokolow on Mon 15th Apr 2013 06:36 in reply to "Comment by TempleOS"
ssokolow Member since:
2010-01-21

I haven't thought about but wouldn't a lot change? I have a text/graphics file format in my operating system -- think PDF. When I load it from disk, I put it in a doubly-linked list memory structure. If RAM was RAM, I could just store it, as long as I didn't move it. (Work with me, I'm exploring possibilities.)


Doubtful. Formats for storing and exchanging data have very different requirements from in-memory data structures.

On-disk formats need to be clearly-defined, unchanging, space-efficient, and often use checksums and compression.

In-memory formats need to support efficient modification, often incorporate cache data, and are decompressed.

Load time will never go away because it's just not feasible to waste 5.2MiB on disk for data that'd be 418.5KiB if you just PNG-compressed it first. (That's actual numbers taken from GIMP's readout for a deviantART pic named "Ganon Style")

...and even if you did, there'd still be programs that'd use different in-memory and on-disk layouts because they've found a more efficient way to do the in-memory stuff.

PDF is even worse since 99% of the time is spent generating raster renderings of vector (or mostly-vector) data (and re-rendering them every time you change the zoom level).

You could easily end up with a CD's worth of data (700MiB+) for a 1MiB PDF if you just kept it all around just in case the user decided to reload the file.

The space-time trade-off just doesn't make sense.

Sure. I could see things like databases benefiting hugely, but they are nothing like PDFs. Database file formats are already basically what you're talking about (A minimally-serialized memory dump, loaded from disk into a page cache on demand) and you never manually manipulate them directly.

Reply Parent Score: 3

RE[2]: Comment by TempleOS
by Laurence on Mon 15th Apr 2013 11:04 in reply to "RE: Comment by TempleOS"
Laurence Member since:
2007-03-26

Many databases are already run off RAM. Sometimes via dedicated RAM storage engines, sometimes using more conventional storage engines which are pointed towards virtual file system (read: RAM disk).

In fact for all the instances where it makes sense running a file system in RAM, we have already have RAM disk.

Edited 2013-04-15 11:13 UTC

Reply Parent Score: 3

RE[2]: Comment by TempleOS
by Flatland_Spider on Mon 15th Apr 2013 19:50 in reply to "RE: Comment by TempleOS"
Flatland_Spider Member since:
2006-09-01

The Linux devs are playing around with compressing allocated memory to increase transfer times and use RAM more efficiently.

With ECC RAM, RAM already has checksums, and checksummed RAM pages, at the OS level, would increase security.

OS X already renders everything in PDF, and it pre-renders icons and things of different sizes then stores them in an on-disk cache.

Every conceivable version doesn't have to be pre-rendered. Only the most common sizes need to be pre-rendered, or only the rendered sizes need to be cached. Plus, the rendered versions don't have to be saved with the original file.

Reply Parent Score: 2