Date: Sat, 5 May 2012 03:09:04 +0300 From: Milen Rangelov <gat3way@...il.com> To: john-dev@...ts.openwall.com Subject: Re: New RAR OpenCL kernel Well, there are two cases here, a PPM block or a LZ block. The PPM case would very quickly give you an error if stream is invallid and unpack29 would switch back to the pure LZSS case. Then for Lempel-Ziv it's highly unlikely that you'd get the same result from rar_decode_number() several times at a row unless the stream is bad. The key point here being "several" and that's where my concerns are. On Sat, May 5, 2012 at 2:45 AM, magnum <john.magnum@...hmail.com> wrote: > On 05/04/2012 08:19 PM, Milen Rangelov wrote: > > OK, my tests are all successful until now. Speed is relatively the same, > > doesn't matter whether the compressed file is a 4KB text file, or a 50MB > > avi movie :) Unfortunately there is still overhead as compared to the HE > > case, speed being somewhat 20% slower. I am still not 100% whether this > > would hold true in all cases and if I am wrong, it might happen that for > > some archives we can get false negatives. > > > > I am not yet 100% convinced I am correct yet though. The approach is > based > > on 2 assumptions, first one can easily be proved, the second one is > related > > to the LZ algorithm and I cannot yet prove what I check is safe and can't > > occur in a valid LZ stream. > > This is good news Milen, just what I hoped for. I am SURE there are such > short-cuts because cRARk runs full speed no matter what you throw at it. > Please do share your findings, you know I would. > > magnum > > Content of type "text/html" skipped
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.