Page 2 of 2 FirstFirst 12
Results 31 to 38 of 38

Thread: CompressionRatings.com

  1. #31
    Programmer Bulat Ziganshin's Avatar
    Join Date
    Mar 2007
    Location
    Uzbekistan
    Posts
    4,483
    Thanks
    719
    Thanked 653 Times in 349 Posts
    Cyan, it's effictively large-dictionaries test. something like srep+... will handle it best

  2. #32
    Administrator Shelwien's Avatar
    Join Date
    May 2008
    Location
    Kharkov, Ukraine
    Posts
    2,966
    Thanks
    153
    Thanked 802 Times in 399 Posts
    Code:
    <sami> "If I didn't miss something, there isn't comment about how many cores 
    does compressors used in each test cases. I think it is technical important."
    <sami> this is not correct
    <sami> the full tables show the cpu utilization
    <sami> separately for compression and decompression
    <sami> it's the percentage right beside the times
    <sami> "Why random ? And not the usual TAR ?"
    <sami> because the point was to force all comrpessors to treat this as just a file
    <Shelwien> well, in theory somebody could parse the tar and still sort it :)
    <sami> i will explain more once i get the site running again. 
    there would be a lot to write about the decisions
    <sami> some compressors parse tar files
    <sami> maniscalco compressors and to my knowledge winrk
    <Shelwien> :)
    <sami> just to make it clear. i'm not using tar in that file, 
    the files are copied into a single file in random order
    <sami> i'd rather copy chunks of random size instead, 
    but that would break the file formats

  3. #33
    Administrator Shelwien's Avatar
    Join Date
    May 2008
    Location
    Kharkov, Ukraine
    Posts
    2,966
    Thanks
    153
    Thanked 802 Times in 399 Posts
    Code:
    <Shelwien> Also new column layout is better I guess, 
    <Shelwien> but imho many people (including me) would
    <Shelwien> prefer the "output" swapped with "size" (even with ratings by "size")
    <Sami> Who?
    So, do you prefer Sami's version with "size" that includes decoder size
    (which is the whole compressor in most cases), or plain output size
    for the size column? http://compressionratings.com/sort.cgi?txt1.full+6n
    Last edited by Shelwien; 20th April 2010 at 02:48.

  4. #34
    Member
    Join Date
    Sep 2008
    Location
    France
    Posts
    853
    Thanks
    441
    Thanked 244 Times in 101 Posts
    I guess the idea is probably to avoid decoders which would have parts of the object to decode in them ... This matters for ranking.

    The size used for the ranking calculation needs to be mentioned. Whatever the name given to it.

    So if the question is more about the column titled "size", this is more a matter of choice. I have none personally, and imho both Sami and yours proposals seem perfectly understandable.

  5. #35
    Administrator Shelwien's Avatar
    Join Date
    May 2008
    Location
    Kharkov, Ukraine
    Posts
    2,966
    Thanks
    153
    Thanked 802 Times in 399 Posts
    Ok, let's make it more specific:

    Code:
                  "output" "size"
    slug 1.24      309919 317263
    etincelle b4   313590 352475
    Here I added the size of 7z-compressed executables to the
    size of compressed book1.
    So, which column seems more fair to you?

    Sure, for most of Sami's benchmarks it doesn't really matter,
    but recently there're some with small files too.

    Also, while it makes sense for some cases like HP, but in general,
    having a built-in dictionary is still an advantage to
    the compressor/archiver, even if the benchmark sizes become
    the worst possible when decoder size is included.
    Last edited by Shelwien; 20th April 2010 at 05:19.

  6. #36
    Member m^2's Avatar
    Join Date
    Sep 2008
    Location
    Ślůnsk, PL
    Posts
    1,612
    Thanks
    30
    Thanked 65 Times in 47 Posts
    Quote Originally Posted by Shelwien View Post
    Ok, let's make it more specific:

    Code:
                  "output" "size"
    slug 1.24      309919 317263
    etincelle b4   313590 352475
    Here I added the size of 7z-compressed executables to the
    size of compressed book1.
    So, which column seems more fair to you?

    Sure, for most of Sami's benchmarks it doesn't really matter,
    but recently there're some with small files too.

    Also, while it makes sense for some cases like HP, but in general,
    having a built-in dictionary is still an advantage to
    the compressor/archiver, even if the benchmark sizes become
    the worst possible when decoder size is included.
    IMO output is more fair.
    In most cases where compression matters, decompressor size is negligible.
    The only exceptions that I see are installers and compressors that have the benchmark file built-in. But Sami's benchmarks aren't popular enough yet.

  7. #37
    Programmer Bulat Ziganshin's Avatar
    Join Date
    Mar 2007
    Location
    Uzbekistan
    Posts
    4,483
    Thanks
    719
    Thanked 653 Times in 349 Posts
    Sami removed App2 from main testset

  8. #38
    Member Fu Siyuan's Avatar
    Join Date
    Apr 2009
    Location
    Mountain View, CA, US
    Posts
    176
    Thanks
    10
    Thanked 17 Times in 2 Posts
    Quote Originally Posted by Bulat Ziganshin View Post
    Sami removed App2 from main testset
    yes, but he is still considering if testset like this is useful or how much weight should it be to measure applied compression performance.any others include nondevelopers have advices?

Page 2 of 2 FirstFirst 12

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
  •