Earlier quoted context omitted.
Surely LZ4 is not in fact more energy efficient, otherwise Apple would be pushing LZ4 as the algorithm to use on mobile devices instead of recommending LZFSE. If you see in that previous discussion, I was asking the same questions there and got no real answer. It looks to me like nobody (outside of Apple) has actually tested the energy efficiency.
LZ4 is a format. All you can say about how energy efficient a format is, is by looking at the average speeds of its implementations. However, zlib for instance (a DEFLATE library) is more energy efficient than zopfli (another DEFLATE library), just by virtue of taking less CPU cycles to crunch data. There is in fact a very high correlation between CPU cycles and energy efficiency, since compression algorithms don't s…
Apple Open-Sources its Compression Algorithm LZFSE
211–219 of 219 posts
Re: Apple Open-Sources its Compression Algorithm LZFSE
#212Oh wow dude you watch Silicon Valley also? Great reference! It sure added a lot to the conversation. Please continue making useful comments like this in the future, you really got us thinking with your pop culture reference. (And I sure patted myself on the back for recognizing such witticism)
Re: Apple Open-Sources its Compression Algorithm LZFSE
#213Oh wow dude you watch Silicon Valley also? Great reference! It sure added a lot to the conversation. Please continue making useful comments like this in the future, you really got us thinking with your pop culture reference. (And I sure patted myself on the back for recognizing such witticism)
We detached this subthread from https://news.ycombinator.com/item?id=12048265 and marked it off-topic.
Re: Apple Open-Sources its Compression Algorithm LZFSE
#214Earlier quoted context omitted.
LZ4 is a format. All you can say about how energy efficient a format is, is by looking at the average speeds of its implementations. However, zlib for instance (a DEFLATE library) is more energy efficient than zopfli (another DEFLATE library), just by virtue of taking less CPU cycles to crunch data. There is in fact a very high correlation between CPU cycles and energy efficiency, since compression algorithms don't s…
If Zstd is better, then how does Apple win by pushing LZFSE? It's not like Apple gets anything from having people use a compression algorithm they wrote. If Apple convinces third-party devs to use an algorithm that is worse all around, then everybody loses.
I think once Zstd gets a bit more mainstream the best they would do is add it as an option.
Re: Apple Open-Sources its Compression Algorithm LZFSE
#215Earlier quoted context omitted.
This is a baseless speculation. First of all, Apple provides LZ4 in libcompression. Secondly, LZFSE uses Lempel–Ziv algorithm and ANS coder invented by Jarek Duda ( https://arxiv.org/abs/1311.2540 ): https://developer.apple.com/library/ios/documentation/Perfor...
Well, many people nowadays pretend that, as if they read Jarek's paper, understood it and came out with a genuine implementation of their own. But Jarek's ANS paper was first out in 2007, and almost no one paid attention to it, because it was plain inscrutable. Many years later, it took an individual to create FSE ( https://github.com/Cyan4973/FiniteStateEntropy ), to prove that it could be transformed into something…
Re: Apple Open-Sources its Compression Algorithm LZFSE
#216Earlier quoted context omitted.
That is my experience. Maths people are not renowned for their ability to write readable or maintainable code. I recently needed an implementation of the Simplex Noise algorithm (that I could port to Common Lisp). I ended up using this one, which works but the code certainly does nothing to help understanding: https://github.com/josephg/noisejs/blob/master/perlin.js Note that the Javscript implementation is also a po…
Hey, someone found those noise functions I ported to JS a few years ago! Sorry for not referencing the original code. The java version I translated from is here: http://webstaff.itn.liu.se/~stegu/simplexnoise/SimplexNoise.... And the paper describing the algorithm is here: http://webstaff.itn.liu.se/~stegu/simplexnoise/simplexnoise.... Glad it was useful to you!
I used it as a base for a map generator for a strategy game. Thanks a lot for the code, it worked perfectly.
Re: Apple Open-Sources its Compression Algorithm LZFSE
#217Earlier quoted context omitted.
> I really appreciate the presence of a no-nonsense Makefile. Indeed, the current version of their Makefile is a great example of how to write a simple yet portable Makefile: https://github.com/lzfse/lzfse/blob/33629bc65f4b356072c9a7d5... > No autoconf, no pkgconfig, just plain and simple make. While I agree with your sentiment, I believe that your statement about pkg-config goes a bit over the top. Yes, the LZFSE pr…
> Indeed, the current version of their Makefile is a great example of how to write a simple yet portable Makefile: Yet it forgets the MOST important thing: make uninstall. Nothing worse than software where I have to reverse engineer a makefile in order to uninstall!
More importantly, who tests it? Most developers using e.g. automake or some other generator don't test this, ever. If you package it, you delegate uninstallation to the package manager.
I'd be very leery of actually running this on my system in case it blew away unrelated bits, or versioned bits shared with other packages or package versions, like shared library symlinks or similar.
Re: Apple Open-Sources its Compression Algorithm LZFSE
#218Earlier quoted context omitted.
The Weissman score is the most moronic compression "metric" ever devised. I put "metric" in quotes because from a mathematical perspective, it is practically gibberish. I'm tired of seeing it mentioned in every HN post on compression.
I also see this kind of response a lot in situations the score is brought up. I don't have a background in compression, what is the current method for measuring compression efficiency? Is it a balance between size reduction and speed to unpack or is measuring compression efficacy far more nuanced?
Normally, any sensible 1D metric would be visualized as isolines in that 2D plane. But the "Weissman score" doesn't even make that much sense, it's a discontinuous, non-monotonic function with singularities right in the middle! It doesn't even make sense from a dimensional analysis perspective… the score will fluctuate wildly based on the units you choose for time and size (minutes? seconds? octets? bits?). There is no conceivable real-world application of the Weissman score. It is just a bit of bad math that appeared on TV once.
Re: Apple Open-Sources its Compression Algorithm LZFSE
#219Earlier quoted context omitted.
Based on Apple's own presentation it looks like energy efficiency is pretty proportional to performance, so it's very likely that a faster algorithm (e.g. LZ4) would also be more efficient. In modern "braniac" processors, 90% of the energy is spent on overhead and doesn't vary based on instruction mix. Memory accesses consume both energy and time, so fewer are better. (From the previous discussion: https://news.ycomb…
Surely LZ4 is not in fact more energy efficient, otherwise Apple would be pushing LZ4 as the algorithm to use on mobile devices instead of recommending LZFSE. If you see in that previous discussion, I was asking the same questions there and got no real answer. It looks to me like nobody (outside of Apple) has actually tested the energy efficiency.