DirectStorage VS zip.js

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

Similarly, if people are interested, I have coded the possibility to compress zip files on several cores in zip.js [1]. The approach is simpler as it consists of compressing the entries in parallel. It still offers a significant performance gain though when compressing multiple files in a zip file, which is often the nominal case.

[1] https://github.com/gildas-lormeau/zip.js

This shouldn't be an issue. There are JS libraries that can decompress zip (e.g. https://gildas-lormeau.github.io/zip.js/). Nowadays even huge C/C++ codebases can be compiled into JS via Emscripten.

Well, you can build zip.js with fflate if you want to, see https://github.com/gildas-lormeau/zip.js/blob/master/rollup-fflate.config.js. I wasn't saying that zip.js is faster than fflate or any other library. I'm just saying it can compress files in parallel.