By: Brett (ggtgp.delete@this.yahoo.com), December 8, 2014 10:00 am
Room: Moderated Discussions
Eric Bron (eric.bron.delete@this.zvisuel.privatefortest.com) on December 8, 2014 4:35 am wrote:
> > have huge working sets which would take too much memory, energy, and loading time to access.
>
> even without resorting to new technologies, SSD are vey fast already, something which need
> much attention for out of core processing is the file formats, legacy formats and many new
> formats (!) are based on serialization of the whole file which goes against parallelization
A SSD has one set of pins you plug the device into, so ultimately the interface is serial.
The big mistake is not preallocating your disk blocks, a simple byte stream will have to update the file table for each block added. This doubles the number of blocks written to and almost all those file table blocks will need to be erased, which leads to a slow garbage collection wear leveling pass.
> > have huge working sets which would take too much memory, energy, and loading time to access.
>
> even without resorting to new technologies, SSD are vey fast already, something which need
> much attention for out of core processing is the file formats, legacy formats and many new
> formats (!) are based on serialization of the whole file which goes against parallelization
A SSD has one set of pins you plug the device into, so ultimately the interface is serial.
The big mistake is not preallocating your disk blocks, a simple byte stream will have to update the file table for each block added. This doubles the number of blocks written to and almost all those file table blocks will need to be erased, which leads to a slow garbage collection wear leveling pass.