Results 1 to 6 of 6

Thread: orz - an optimized ROLZ data-compressor written in rust

  1. #1
    Member RichSelian's Avatar
    Join Date
    Aug 2011
    Location
    Shenzhen, China
    Posts
    156
    Thanks
    18
    Thanked 50 Times in 26 Posts

    Smile orz - an optimized ROLZ data-compressor written in rust

    https://github.com/richox/orz
    rewriting old libzling with rust-lang (just learned it for less than a month ) with some optimizations, now decoding speed is 30% faster than libzling

  2. The Following 3 Users Say Thank You to RichSelian For This Useful Post:

    Bulat Ziganshin (7th March 2019),Mike (11th March 2018),Simorq (11th March 2018)

  3. #2
    Member
    Join Date
    Jun 2009
    Location
    Kraków, Poland
    Posts
    1,471
    Thanks
    26
    Thanked 120 Times in 94 Posts
    Written in Rust, but lots of code is marked as unsafe :]

  4. #3
    Member RichSelian's Avatar
    Join Date
    Aug 2011
    Location
    Shenzhen, China
    Posts
    156
    Thanks
    18
    Thanked 50 Times in 26 Posts
    due mainly to avoid runtime boundary checking, rust has no option to disable it

  5. #4
    Member
    Join Date
    May 2008
    Location
    Germany
    Posts
    410
    Thanks
    37
    Thanked 60 Times in 37 Posts
    sounds interesting
    can you please upload a binary for windows x64 ?

  6. #5
    Member RichSelian's Avatar
    Join Date
    Aug 2011
    Location
    Shenzhen, China
    Posts
    156
    Thanks
    18
    Thanked 50 Times in 26 Posts
    cross-compiled under Mac, not tested. hopee it works
    orz-v0.1.0-x86_64-pc-windows-gnu.exe

  7. The Following User Says Thank You to RichSelian For This Useful Post:

    Simorq (12th March 2018)

  8. #6
    Member
    Join Date
    Jan 2017
    Location
    Selo Bliny-S'edeny
    Posts
    14
    Thanks
    6
    Thanked 3 Times in 2 Posts
    So RichSelian, do you think that reducing offsets with 1-byte preceding context is the most practical option? I.e. you have the match finder with (256 buckets * a lot of entries). If you reduce offsets with 2 preceding bytes, you could instead have (65,536 buckets * a few entries). This second scheme could yield smaller reduced offset, that is, if you manage to find a match predicated on a two-byte preceding context (which must be harder than finding a match predicated on a one-byte context).

    A compressor targeting high ratio can actually run both match finders: the cost of introducing another kind of match, to wit, predicated on a two-byte context, is roughly 1 bit per match, but the offset can be reduced by much more than one bit. This reminds me of Christian Martelock's RAZOR: he confirmed (more or less) that RAZOR runs separate match finders and encodes LZ and ROLZ matches with different symbols. I now suspect that he secretly runs three match finders.

Similar Threads

  1. LZ4X - An Optimized LZ4 Compressor
    By encode in forum Data Compression
    Replies: 100
    Last Post: 26th March 2019, 19:46
  2. Grouped (ROLZ) LZW compressor
    By Marco_B in forum Data Compression
    Replies: 19
    Last Post: 5th April 2018, 14:39
  3. Optimized LZSS compressor
    By encode in forum Data Compression
    Replies: 11
    Last Post: 13th February 2014, 23:51
  4. A nooblike ROLZ compressor
    By RichSelian in forum Data Compression
    Replies: 11
    Last Post: 10th October 2012, 23:13
  5. xp a rolz compressor
    By pmcontext in forum Data Compression
    Replies: 40
    Last Post: 9th December 2010, 10:04

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •