Fastest textual decompression in C
-
Guys, for 25 or so days I have been wrestling with the most simple approach in LZSS. Seeing how demanding (criticizing) are some fellow members, here I would like to hear from all interested in this topic programmers what one good article about LZSS should feature. So, please share here your point on what has to be covered what to be emphasized and other must-be-s in the article. Maybe I will write an article, the thing that stops me is the unappreciativeness. My way of doing things is all about enjoying the speeds of small etudes in C, that's why I ask preemptively: Does CODEPROJECT need the article 'Fastest textual decompression in C'?. Here you can see my etude heavily benchmarked against the best in the world: http://www.sanmayce.com/Nakamichi/[^]
-
Guys, for 25 or so days I have been wrestling with the most simple approach in LZSS. Seeing how demanding (criticizing) are some fellow members, here I would like to hear from all interested in this topic programmers what one good article about LZSS should feature. So, please share here your point on what has to be covered what to be emphasized and other must-be-s in the article. Maybe I will write an article, the thing that stops me is the unappreciativeness. My way of doing things is all about enjoying the speeds of small etudes in C, that's why I ask preemptively: Does CODEPROJECT need the article 'Fastest textual decompression in C'?. Here you can see my etude heavily benchmarked against the best in the world: http://www.sanmayce.com/Nakamichi/[^]
Sanmayce wrote:
Does CODEPROJECT need the article 'Fastest textual decompression in C'?.
If you think your article covers a subject better than existing articles, or is the first one to describe the problem, then go ahead. But before you start, please spend time reading A Guide To Writing Articles For Code Project[^] and the Posting Guidelines[^]. You should also look at some of the articles by people such as Pete O'Hanlon[^], Sacha Barber[^] etc, to see the sort of submission that is likely to get good reviews.
-
Sanmayce wrote:
Does CODEPROJECT need the article 'Fastest textual decompression in C'?.
If you think your article covers a subject better than existing articles, or is the first one to describe the problem, then go ahead. But before you start, please spend time reading A Guide To Writing Articles For Code Project[^] and the Posting Guidelines[^]. You should also look at some of the articles by people such as Pete O'Hanlon[^], Sacha Barber[^] etc, to see the sort of submission that is likely to get good reviews.
Thanks, I checked all the links you gave me, also searched for LZ, LZSS, compression in article names. Strange, not a single article on LZ/LZSS, not to mention fast, let alone fastest. You see Mr.MacCutchan, I want to share a stand-alone file-to-file compressor written in C featuring fastest decompression on textual data. I don't see it as utility but rather as an illustration/sample how to decompress some needed text-like data at speeds 18%-40% of memcpy(). The focus I want to be precisely on DECOMPRESSION, I don't want to be dragged into mumbo-jumbisms as "How do I compress? The LZSS is not explained. This is not an article. Poor description and similar complains." Seeing some fellow members' articles on LZW and Huffman I see my approach in different light, I like benchmarks real-world ones, disassembly listings and comparisons with the best decompressors today. That's why I ask for some preemptive feedback/directions. Personally, it is annoying for me to want to share some code etude and instead of making some interesting place/topic for sharing ideas/benching with fellow coders to receive complains "THIS ARTICLE IS NOT GOOD", I am not a journalist to write articles, after all the CP logo says 'For those who code' not 'write articles'. My point, new ideas/improvements are to be easily shareable, I think.
-
Thanks, I checked all the links you gave me, also searched for LZ, LZSS, compression in article names. Strange, not a single article on LZ/LZSS, not to mention fast, let alone fastest. You see Mr.MacCutchan, I want to share a stand-alone file-to-file compressor written in C featuring fastest decompression on textual data. I don't see it as utility but rather as an illustration/sample how to decompress some needed text-like data at speeds 18%-40% of memcpy(). The focus I want to be precisely on DECOMPRESSION, I don't want to be dragged into mumbo-jumbisms as "How do I compress? The LZSS is not explained. This is not an article. Poor description and similar complains." Seeing some fellow members' articles on LZW and Huffman I see my approach in different light, I like benchmarks real-world ones, disassembly listings and comparisons with the best decompressors today. That's why I ask for some preemptive feedback/directions. Personally, it is annoying for me to want to share some code etude and instead of making some interesting place/topic for sharing ideas/benching with fellow coders to receive complains "THIS ARTICLE IS NOT GOOD", I am not a journalist to write articles, after all the CP logo says 'For those who code' not 'write articles'. My point, new ideas/improvements are to be easily shareable, I think.
-
Thanks, I checked all the links you gave me, also searched for LZ, LZSS, compression in article names. Strange, not a single article on LZ/LZSS, not to mention fast, let alone fastest. You see Mr.MacCutchan, I want to share a stand-alone file-to-file compressor written in C featuring fastest decompression on textual data. I don't see it as utility but rather as an illustration/sample how to decompress some needed text-like data at speeds 18%-40% of memcpy(). The focus I want to be precisely on DECOMPRESSION, I don't want to be dragged into mumbo-jumbisms as "How do I compress? The LZSS is not explained. This is not an article. Poor description and similar complains." Seeing some fellow members' articles on LZW and Huffman I see my approach in different light, I like benchmarks real-world ones, disassembly listings and comparisons with the best decompressors today. That's why I ask for some preemptive feedback/directions. Personally, it is annoying for me to want to share some code etude and instead of making some interesting place/topic for sharing ideas/benching with fellow coders to receive complains "THIS ARTICLE IS NOT GOOD", I am not a journalist to write articles, after all the CP logo says 'For those who code' not 'write articles'. My point, new ideas/improvements are to be easily shareable, I think.
Sanmayce wrote:
I don't want to be dragged into mumbo-jumbisms as "How do I compress?
it's unlikely that many people are going to be familiar with the LZSS algorithm. and people are going to ask you for the compression side of it. so, i'd suggest including a simpler compressor with a description of the algorithm. you have to at least get the readers up to the point where they can follow your discussion of the decompressor. otherwise, you're starting the story in the middle.
-
Sanmayce wrote:
I don't want to be dragged into mumbo-jumbisms as "How do I compress?
it's unlikely that many people are going to be familiar with the LZSS algorithm. and people are going to ask you for the compression side of it. so, i'd suggest including a simpler compressor with a description of the algorithm. you have to at least get the readers up to the point where they can follow your discussion of the decompressor. otherwise, you're starting the story in the middle.
Mr.Losinger, have you seen the Wikipedia's article on LZSS: http://en.wikipedia.org/wiki/LZSS[^] Now check my amateurish attempt to shed light on LZSS: http://www.sanmayce.com/Nakamichi/[^] LZSS is simple enough yet writing an article is not easy, my wish is to contribute to the decompression part with one of the fastest (in top 3) etudes, benchmarks, C/Assembly snippets, not to define/explain the algorithm. For a start, I need modern machine to test on, sadly I own only Core2, that's a nasty break for me since I use DWORD fetching (sucks on Core2), XMM and even ZMM which is so interesting to be seen what can bring to the table. My naive expectations were that some fellow coders will help me at least with its benchmarking, sadly I see no interested coders on this topic. One of my wishes is to show an etude, Nakamichi 'Sanagi' to be exact, 512bit targeted, luckily Intel C optimizer v14 (which I used) supports them but still no computer in my reach can run the executable. "Tianhe-2 the world's fastest supercomputer according to the TOP500 list for June and November 2013 utilizes Xeon Phi accelerators based on Knights Corner." /Wikipedia/ In my view such an benchmark is both important and interesting, thus the incoming Knights Corner/Landing processors will show the power of ZMMWORD moves. "... Far more interesting is that Intel's Knights Landing not only will be an expansion card but also will serve as a standalone platform or processor ..." /http://www.admin-magazine.com/Articles/Exploring-the-Xeon-Phi/ Simply, the near future will bring monstrous bandwidths, not utilizing them is just ... lame. I see how some 30 years old algorithms are/have to be 'pimped' and pumped. >it's unlikely that many people are going to be familiar with the LZSS algorithm. Agreed, but it is with everything like that, isn't it! >i'd suggest including a simpler compressor with a description of the algorithm. Sure. >you have to at least get the readers up to the point where they can follow your discussion of the decompressor. otherwise, you're starting the story in the middle. Of course, I am not some villain wanting to obscure information, but as I said my focus is entirely on textual decompression speed boosts, they alone took a lot of my tim