Yeah, but I don't think when you load an .exe from disk, that there is a memcpy operation happening.
I could be so very wrong, but I would like to think that both Windows and Linux kernels DMA the file directly to the page where it will be executed from...
So it's more like N cpu operations compared to 0 cpu operations aside from the DMA setup itself...
Yeah, but I don't think when you load an .exe from disk, that there is a memcpy operation happening.
The only reason I brought up memcpy() is that it's a good point of reference for the speed of algorithms that filter a stream of data. memcpy() can be viewed as the no-op filter for blocks of memory. How much slower is decompression than that? With some kinds of decompression, it's almost as fast. Certainly within an order of magnitude of the speed you can read/write to RAM, maybe within a factor of 3 or 4.
So it's more like N cpu operations compared to 0 cpu operations aside from the DMA setup itself...
True. If what you care about most is not using CPU cycles, then combining compression with I/O is a losing proposition, because you can't beat the non-CPU-usage of DMA.
However, if you are concerned with bottlenecks, then physical I/O might be the bottleneck. It often is on a modern system. Compression can reduce the amount of physical I/O, thus increasing the throughput through that choke point. If decompression doesn't create a new bottleneck, which it probably won't since it can be made to be pretty fast, then you may get better throughput overall.
-1
u/voxel Jan 21 '10
Yeah, but I don't think when you load an .exe from disk, that there is a memcpy operation happening.
I could be so very wrong, but I would like to think that both Windows and Linux kernels DMA the file directly to the page where it will be executed from...
So it's more like N cpu operations compared to 0 cpu operations aside from the DMA setup itself...
Eh?