isa-l VS DirectStorage

For using accelerators (QAT, I assume, because the article is about this) from the CLI, then QATzip[3] comes with a command line tool qatzip which can be used as described in the project ReadMe. I didn't test it, though, as I have no QAT-enabled device.

[1] https://github.com/intel/isa-l/tree/master/igzip

Ex 1: https://github.com/intel/isa-l/blob/master/README.md

Examples: - Someone I know created machine-optimized library in c and asm to accelerate compression, erasure coding, and encryption on Intel Xeon CPUs (https://github.com/intel/isa-l) which runs those ops WAY faster than the standard linux libraries. - My friend is making a retro SEGA genesis game using a C and asm dev kit (https://github.com/Stephane-D/SGDK)

igzip (https://github.com/intel/isa-l) is much faster than gzip or pigz when it comes to decompression, 2-3x in my experience. There is also a Python module (isal) that provides a GzipFile-like wrapper class, for an easy speed-up of Python scripts that read gzipped files.

However, it only supports up to level 3 when compressing data, so it can't be used as a drop-in replacement for gzip. You also need to make sure to use the latest version if you are going to use it in the context of bioinformatics, since older versions choke on concatenated gzip files common in that field.

I don't think the GPU decompression optimizations is in this driver. I updated and using the Bulk Loader Demo test I'm actually seeing lower throughput than before. I used to hit around 24-25GB a sec, now I'm only hitting like 21GB a sec. Although it's possible but I doubt it, it could be related to the Windows 11 March update reducing SSD bandwidth. I haven't run the test in months so it might be related.

The data is compressed with GDeflate, not deflate. The single stream is designed to use the parallelism of a GPU. It is described here:

https://github.com/microsoft/DirectStorage/blob/main/GDeflat...

The GPU decompression benchmark I linked earlier allows you to specify a single file that it will compress with GDeflate (and zlib for comparison). The numbers presented in the docs that come with the benchmark and presented elsewhere are consistent with my own runs using a source file that is highly compressible.

Part of the trick of achieving this speedup is to read the data fast enough. I don't know of any NVMe drive that can reach full speed with a queue depth of 1. While running the benchmark in a windows VM with a GPU passed through, on the linux host I observed that the average read size was about 512k and the queue depth was sometimes over 30.

We already have GDeflate, with permissive sources available for both CPU compression/decompression and GPU decompression in the DirectStorage GitHub repo. I haven't personally played with it yet, but I'll be implementing it in a project I'm working on in the next few months and am pretty excited to do so.

Wrong: https://github.com/microsoft/DirectStorage/blob/main/Docs/diagrams.mmd

The github repo has some command line parameters.

Only the final test where the results of several SSDs are displayed in the graph is a synthetic one. The first two both support DirectStorage and are designed with Microsoft's recommendations for DirectStorage in mind. That is, random reads of 32k or greater block sizes with high queue depths. This is because you need a high queue depth to be able to saturate NVMe drives.

For most it'll be a background element they're not aware of, if you're running up to date win10 onwards you have DS capabilities, you can get the sample from microsoft build it and run it fine.

Direct Storage github Samples: https://github.com/microsoft/DirectStorage