I understand why one could consider the benchmarks unfair to bzip3 because they're single-threaded (depending on exactly one defines "faster"), but why do you say they are not fair towards bzip3 because of the bigger block size it uses? Do the benchmarks not use the optimal block size for each compression tool?
Lzip usage code#
I have paper published from it, and still planning to re-implement and open it, since the PoC was beyond bad from a code quality perspective.įirst, I don't understand what the block size has to do with the number of threads used. It had a deterministic and fast hyphenation engine for the language, and used embedded dictionary to minimize bit-flip damage during transit. : The algorithm I developed was working on syllables rather than bytes.
Lzip usage zip#
On the other side, official repository of zstd lists zlib and other libraries which use DEFLATE in one way other, pointing back to Ziv's ZIP at the same time.Īt the end of the day, it might be tipping its hat directly to "ZIP" per se, but to general direction of DEFLATE which is used by ZIP format too. I'm well aware of the Ziv, Lempel & Welch's work, since I've developed a compression algorithm and did extensive research on the family before, however the usage of extension is a rather new information for me. > The LZ77, LZ78, and LZW algorithms all predate the zip format. > I'm not saying that it definitely isn't, but the only connection I know of myself is that they both begin with the letter Z, and the letter Z has a long association with data compression that goes back before the zip format / pkzip program. Or more generally, DEFLATE family of algorithms used by zlib and ZIP. Rough timeline of letter Z in data compression: But interestingly, the Unix "pack" program uses a ".z" suffix even though its algorithm is just Huffman (not one of the Lempel-Ziv family of algorithms), so the letter Z somehow came to signify data compression more generally. In those algorithm names, the L and Z stand for Lempel and Ziv, respectively.
As do two very old, obsolete Unix compression programs: "pack", which is uses a ".z" suffix for compressed files, and "compress", which uses a ".Z" suffix for compressed files. The LZ77, LZ78, and LZW algorithms all predate the zip format. I'm not saying that it definitely isn't, but the only connection I know of myself is that they both begin with the letter Z, and the letter Z has a long association with data compression that goes back before the zip format / pkzip program. > I don't think PKWARE feels bad because ZSTD is a homage to ZIP. Either case, if the original developer returns to the game, it can create a BZIP4 and points to the diversion as, "hey, somebody liked BZIP2 too much and created this, give him/her a kudos", and continue. If a completely different implementation advertises itself as a newer iteration of a format because it's built on the same theory, I think it's ethical if the developer is not intending to capitalize name.
Lzip usage software#
Open source software is designed to be mangled, modified, shared and leapfrogged. Similarly if someone created a follow-up file format to something I've designed, I'd just want credit or a link to my version as a homage and pointer for history continuity, nothing else. I don't think PKWARE feels bad because ZSTD is a homage to ZIP. I think it boils down to the feelings of the author (of the previous format). While the author of bzip2 doesn't seem to plan to release a follow-up, I feel it is bad manner to take over a name like this. I am not sure how I feel about you "stealing" the bzip name.
0 kommentar(er)
