6 ms·

It's tested against a wide range of other compressors in this thread: http://encode.ru/threads/2221-LZFSE-New-Apple-Data-Compression?s=031e6ce4e62b74fde592c96e9

by gribbly 10y ago

It's tested against a wide range of other compressors in this thread: http://encode.ru/threads/2221-LZFSE-New-Apple-Data-Compression?s=031e6ce4e62b74fde592c96e91384332 http://encode.ru/threads/2221-LZFSE-New-Apple-Data-Compressi... The results are kind of underwhelming.

muizelaar 10y ago
https://quixdb.github.io/squash-benchmark/unstable/ https://quixdb.github.io/squash-benchmark/unstable/ in particular paints a pretty good picture of the current landscape. It seems like ZStd is usually better than LZFSE and LZ4 is pretty competitive with LZFSE:LZVN.
- yAak 10y ago
  I'm curious to see comparisons on a 64bit ARM cpu, since that's what Apple likely optimized it for. (I don't expect a huge difference, but I'm admittedly ignorant on this topic.)
  - eridius 10y ago
    I'd also be curious to see what the energy impact is of the various methods. LZFSE wasn't just designed for speed, it was also designed for energy efficiency.
    - giovannibajo1 10y ago
      I can't see how "power efficiency" can be different from "speed" in the context of a CPU decompressor algorithm. Care to explain?
      - eridius 10y ago
        I don't know the details, but I don't see why power efficiency has to be the same thing as speed. For example, various patterns of memory access or I/O may run at the same speed but could very plausibly have different amounts of energy consumption. Similarly, it's conceivable that different CPU instructions that run in the same time might have different energy demands. CPUs also have different speeds they run at which have different energy usage, it's possible that LZFSE might be designed to avoid putting the CPU into its highest-power mode. But as I said before, I don't know the details about what LZFSE does, I just know that there are various reasons why energy usage is not the same thing as CPU time.
kvestyn 10y ago
Quoting the github page: "This is a reference C implementation". I read that as "not the optimized version used in Apple's libCompression."

by gribbly 10y ago

muizelaar 10y ago

https://quixdb.github.io/squash-benchmark/unstable/ https://quixdb.github.io/squash-benchmark/unstable/ in particular paints a pretty good picture of the current landscape. It seems like ZStd is usually better than LZFSE and LZ4 is pretty competitive with LZFSE:LZVN.

yAak 10y ago
I'm curious to see comparisons on a 64bit ARM cpu, since that's what Apple likely optimized it for. (I don't expect a huge difference, but I'm admittedly ignorant on this topic.)
- eridius 10y ago
  I'd also be curious to see what the energy impact is of the various methods. LZFSE wasn't just designed for speed, it was also designed for energy efficiency.
  - giovannibajo1 10y ago
    I can't see how "power efficiency" can be different from "speed" in the context of a CPU decompressor algorithm. Care to explain?
    - eridius 10y ago
      I don't know the details, but I don't see why power efficiency has to be the same thing as speed. For example, various patterns of memory access or I/O may run at the same speed but could very plausibly have different amounts of energy consumption. Similarly, it's conceivable that different CPU instructions that run in the same time might have different energy demands. CPUs also have different speeds they run at which have different energy usage, it's possible that LZFSE might be designed to avoid putting the CPU into its highest-power mode. But as I said before, I don't know the details about what LZFSE does, I just know that there are various reasons why energy usage is not the same thing as CPU time.

kvestyn 10y ago

Quoting the github page: "This is a reference C implementation". I read that as "not the optimized version used in Apple's libCompression."