Page 63 of 65 FirstFirst ... 13536162636465 LastLast
Results 1,861 to 1,890 of 1938

Thread: paq8px

  1. #1861
    Member Gotty's Avatar
    Join Date
    Oct 2017
    Location
    Switzerland
    Posts
    466
    Thanks
    320
    Thanked 308 Times in 165 Posts
    Quote Originally Posted by DZgas View Post
    I still not clear why folder compression was remove in paq8px_v137, the default compression parameter was remove, the creation of the default archive in the same place as the compressed file...
    Sorry that those changes caused you inconvenience.

    Folder compression was not removed but changed. The pre-v137 solution was unfortunately not deterministic, and that caused headaches. Also nobody seemed to use folder compression at that time. Darek uses per-tarred files, for example, that also gives deterministic results.
    Since v137 you'll need to create a list of files you wish to add to the archive. You can build this list of files ahead of time, and use that for all your subsequent tests. Since the list is fixed, the result is deterministic. Use "paq8px.exe -9 @listoffiles.txt" for compression. See the command line help for more. Or if you are for GUI solutions use https://github.com/moisespr123/PAQCompress.
    I hope it helps.

    The default compression (level 5) was removed, because *really* nobody used it. The default compression level was only there because with drag and drop you can not specify a compression level yourself. And level 5 is safe enough: if you don't have the necessary gigabytes of RAM it would still run. But noone really uses level 5.

    Creating the archive in the same place as the original file is a no-go. When I try to compress the same file with different options and run the test simultaneously one archive overwrites the other. I can understand that with the drag and drop functionality the best for you is when the file is created in the original folder and not on your desktop, but using the command line and running parallel tests the optimal default archive location is the location where you run your command, and not where the original file resides. But this is just the default. However you can still specify any destination folder for the archive for the command line so having the archive in the folder of the original file is still easily achievable. It's just not the default.

    @To all: is there anyone else that needs any of the above functionality to be reverted back to how it was before?

    Related: https://github.com/hxim/paq8px/issues/111

  2. #1862
    Member Gotty's Avatar
    Join Date
    Oct 2017
    Location
    Switzerland
    Posts
    466
    Thanks
    320
    Thanked 308 Times in 165 Posts
    Quote Originally Posted by moisesmcardona View Post
    Yes. The CMake file compiles using the native architecture. It was compiled on a Ryzen 9 3950X CPU.
    Usually we provide exes for the public with no specific instruction set and let the cpu dispacher do its thing during runtime.
    In order to be able to publish a general build for the next release again, I will modify the current behavior a little bit.

  3. Thanks:

    Mauro Vezzosi (6th June 2020)

  4. #1863
    Member Gotty's Avatar
    Join Date
    Oct 2017
    Location
    Switzerland
    Posts
    466
    Thanks
    320
    Thanked 308 Times in 165 Posts
    @Eppie, in the root folder there is a test.cpp file you created earlier. I looks like it is still under development (?).
    Could you please finalize it sometime? For now I think I'm gonna removed it so compilation is simpler (= "compile all cpp files").
    Placing it to a "test" subfolder would also work, but it looks like you may have a test folder since it's excluded in .gitignore.
    Can we place it there?

  5. #1864
    Member Gotty's Avatar
    Join Date
    Oct 2017
    Location
    Switzerland
    Posts
    466
    Thanks
    320
    Thanked 308 Times in 165 Posts
    Quote Originally Posted by DZgas View Post
    I wonder why the compressing "nothing" takes 1.20 seconds for paq8px, when for any other archive it takes 0.02 and 0.01 seconds
    Code:
    bsc         0.02
    bcm         0.0
    mcm         0.15
    paq8k       0.01
    paq8kx_v7   0.15
    paq8pxd_v71 0.8
    paq8px_v183 1.2
    
    paq8px_v71  0.03
    paq8px_v90  0.06
    paq8px_v126 0.1
    paq8px_v141 0.2
    paq8px_v156 0.5
    paq8px_v167 0.6
    paq8px_v172 1.2
    paq8px_v173 1.2
    Can't reproduce. I don't think that my system is 5x faster than yours.
    Could you try again?
    Could you also try disabling your antivirus when run timing tests?

    Code:
    >>paq8px_v187.exe -8 nothing.txt
    paq8px archiver v187a (c) 2020, Matt Mahoney et al.
    
    Creating archive nothing.txt.paq8px187 in single file mode...
    
    Filename: nothing.txt (0 bytes)
    Block segmentation:
    -----------------------
    Total input size     : 0
    Total archive size   : 10
    
     Time 0.26 sec, used 2172 MB (2278028105 bytes) of memory
    Code:
    >>paq8px_v183fix1.exe -8 nothing.txt
    paq8px archiver v183fix1 (C) 2019, Matt Mahoney et al.
    
    Creating archive nothing.txt.paq8px183fix1 in single file mode...
    
    Filename: nothing.txt (0 bytes)
    Block segmentation:
    -----------------------
    Total input size     : 0
    Total archive size   : 10
    
     Time 0.25 sec, used 2172 MB (2278036266 bytes) of memory

  6. #1865
    Member Gotty's Avatar
    Join Date
    Oct 2017
    Location
    Switzerland
    Posts
    466
    Thanks
    320
    Thanked 308 Times in 165 Posts
    Quote Originally Posted by Eppie View Post
    I've created a pull request for a major refactoring of paq8px: https://github.com/hxim/paq8px/pull/118
    Compression should remain the same as in v183. I only have access to test the code on a macOS machine, so it's possible that I've broken something for Windows.
    The individual classes haven't really been decoupled at all -- this is mostly just a physical refactoring which aims to make the source code more accessible, so that higher level refactoring can be accomplished more easily.
    If folks here approve of what I've done, I will continue down this path with more documentation updates (including searching this thread for information to add to some of the undocumented models, like I've done for the CharGrpModel), more fixes for compiler warnings, actually decoupling various classes, and maybe even some very basic unit tests.
    Quote Originally Posted by Eppie View Post
    I'd welcome feedback from anyone else here, but especially @mpais, @Gotty, and @kaitz.
    Well done, Eppie! That was a huge thing to do!
    Sorry I was away for so long (half a year!), I will gradually return.

  7. Thanks:

    LucaBiondi (7th June 2020)

  8. #1866
    Member
    Join Date
    Sep 2014
    Location
    Italy
    Posts
    70
    Thanks
    76
    Thanked 30 Times in 20 Posts

    Welcome back Gotty!

    Welcome back!
    Quote Originally Posted by Gotty View Post
    Well done, Eppie! That was a huge thing to do!
    Sorry I was away for so long (half a year!), I will gradually return.

  9. #1867
    Member CompressMaster's Avatar
    Join Date
    Jun 2018
    Location
    Lovinobana, Slovakia
    Posts
    188
    Thanks
    50
    Thanked 13 Times in 13 Posts
    Quote Originally Posted by Gotty View Post
    Sorry I was away for so long (half a year!), I will gradually return.
    Welcome back!
    Yeah, I noticed that your current location was altered from Hungary to Switzerland.

    Quote Originally Posted by Gotty View Post
    Please specify what "digits" mean. Do you mean single-digit ASCII decimal numbers one after the other with no whitespace, like "20200602"?
    I'm not sure what you mean by "in detail".
    Yes, I mean exactly that as you said.
    By detail, I mean kinda thoroughly explanation (without the need to read source code), but not fully detailed.
    Please hit the "THANKS" button under my post if its useful for you.

  10. #1868
    Member
    Join Date
    Dec 2008
    Location
    Poland, Warsaw
    Posts
    1,148
    Thanks
    702
    Thanked 455 Times in 352 Posts
    I'm also welcome Gotty!
    Maybe something will go further with paq8px now!

  11. #1869
    Member CompressMaster's Avatar
    Join Date
    Jun 2018
    Location
    Lovinobana, Slovakia
    Posts
    188
    Thanks
    50
    Thanked 13 Times in 13 Posts
    Quote Originally Posted by Darek View Post
    Maybe something will go further with paq8px now!
    Yes, Gotty made the most paq8px alterations.
    Please hit the "THANKS" button under my post if its useful for you.

  12. #1870
    Member Gotty's Avatar
    Join Date
    Oct 2017
    Location
    Switzerland
    Posts
    466
    Thanks
    320
    Thanked 308 Times in 165 Posts
    Quote Originally Posted by moisesmcardona View Post
    Code:
    paq8px_v187:
    2020.04.12
    - Ported ContextMap Bucket find() function to NEON and AVX2.
    Hm. I believe the AVX2 bucket find function is unnecessary.
    The find() function searches for the given checksum in a 7-slot 2-byte checksum array (i.e. 14 bytes). The SSSE3 version is useful, since it can load 16 bytes at once and do the search (ignoring the last 2-byte element). It looks like the AVX2 version does the same thing, just fetches 32 bytes. But we have only 14. So it has no benefit compared to the SSSE3 version.
    I spotted it only because with the AVX2 enabled I got an assert hit from ContextMap.cpp: assert((uintptr_t(cp[i]) & 63) >= 15); and that is exactly it: a pointer returned is over the expected 14.
    Sorry, but I'll need to remove the AVX2 version. Sorry-sorry!

  13. #1871
    Member
    Join Date
    Jun 2009
    Location
    Puerto Rico
    Posts
    223
    Thanks
    121
    Thanked 41 Times in 31 Posts
    Quote Originally Posted by Gotty View Post
    Hm. I believe the AVX2 bucket find function is unnecessary.
    The find() function searches for the given checksum in a 7-slot 2-byte checksum array (i.e. 14 bytes). The SSSE3 version is useful, since it can load 16 bytes at once and do the search (ignoring the last 2-byte element). It looks like the AVX2 version does the same thing, just fetches 32 bytes. But we have only 14. So it has no benefit compared to the SSSE3 version.
    I spotted it only because with the AVX2 enabled I got an assert hit from ContextMap.cpp: assert((uintptr_t(cp[i]) & 63) >= 15); and that is exactly it: a pointer returned is over the expected 14.
    Sorry, but I'll need to remove the AVX2 version. Sorry-sorry!
    That's fine, as long as the NEON code stays, to make it compatible with ARM CPU's. It works quite well on Samsung smartphones running Linux!

  14. #1872
    Member Gotty's Avatar
    Join Date
    Oct 2017
    Location
    Switzerland
    Posts
    466
    Thanks
    320
    Thanked 308 Times in 165 Posts
    Yes, the NEON code stays. As I see it works with 16 bytes like the SSSE3 version. Although I cannot test it, I believe you already did it.

  15. Thanks:

    moisesmcardona (7th June 2020)

  16. #1873
    Member Gotty's Avatar
    Join Date
    Oct 2017
    Location
    Switzerland
    Posts
    466
    Thanks
    320
    Thanked 308 Times in 165 Posts
    Thank you guys, for the warm welcome!
    Yes, a switched country.

  17. #1874
    Member Gotty's Avatar
    Join Date
    Oct 2017
    Location
    Switzerland
    Posts
    466
    Thanks
    320
    Thanked 308 Times in 165 Posts
    The latest version (v187) is still binary compatible with v183fix1. That is an amazing achievement looking at the many changes the source code went through!

    However I found one minor issue (it's not a bug, just an unintentional change). In Image8BitModel the 'U' in here caused a compression difference:

    cm.set(hash(++i, (jump != 0) ? (0x100U | buffer(abs(jump))) * (1 - 2 * static_cast<int>(jump < 0)) : N, line & 3U));

    With the U in place (since v184) the second parameter for the hash function was cast to 32 bit and not 64 bit as originally and with that a different hash key was calculated when "jump" was negative. It caused a small difference in compression. "Fixed it" in 187fix1 (coming soon).
    So all the compression results are binary compatible with 183fix1 again. No more known issues. Well done guys!

    (This is just a verification/proof that probably no more bugs were introduced during the refactoring process since v183fix1.)

  18. #1875
    Member Gotty's Avatar
    Join Date
    Oct 2017
    Location
    Switzerland
    Posts
    466
    Thanks
    320
    Thanked 308 Times in 165 Posts
    Quote Originally Posted by CompressMaster View Post
    Yes, Gotty made the most paq8px alterations.
    I've created the fewest releases. Jan started paq8px, then mpais took over since v76. With his continuous releases paq8px started to have three-digit version numbers. He has the most releases - more than 100 - I think. I've got only around 35
    Last edited by Gotty; 9th June 2020 at 01:38.

  19. #1876
    Member Gotty's Avatar
    Join Date
    Oct 2017
    Location
    Switzerland
    Posts
    466
    Thanks
    320
    Thanked 308 Times in 165 Posts

    paq8px_v187fix1

    Code:
    - Ported "Fix jpeg thumbnail compression" from paq8pxd_v76 - Thank you, Kaitz!
    - Fixed an issue with an Image8BitModel context (cm.set(hash(++i, (jump != 0)...) where a calculation result was cast to 32 bit instead of 64 bit and caused incompatibility with v183fix1
    - Fixed the speed issue with the infinite base64 loop patch from v186fix1
    - Removed the unnecessary AVX2 ContextMap Bucket find() function - it fetches 32 bytes but we need ony 14.
    - Restored Visual Studio / MSVC compatibility + provided solution and project files
    - Zlib is now available through a nuget package for Visual Studio
    - The necessary zlib source files are included in a new folder "zlib" for MinGW-W64 and other (windows) compilers
    - Provided a batch file for building with MINGW-W64 (for those who don't use cmake): "build-mingw-w64-generic-publish.cmd" - in the "build" folder
    - Preprocessor macros:
      - Switched from #ifndef NDEBUG to #ifdef VERBOSE wherever detailed debug information is printed on screen
      - Switched from USE_TEXTMODEL / USE_AUDIOMODEL / USE_ZLIB to DISABLE_TEXTMODEL / DISABLE_AUDIOMODEL / DISABLE_ZLIB so when no options are provided these features are included by default
        When you build paq8px yourself and want maximum performance you need to provide the -DNDEBUG flag only (default in "CMakeLists.txt" and in "Build-mingw64-generic-for-publish.cmd")
    - Fixed CPU/SIMD dispatch to enable building for the general public again
    - Some cosmetic changes
    - Archives are still expected to be binary compatible with v183fix1
    Could you guys try the exe found in the build folder? It should run on all x64 PCs. (Strangely it is somewhat slower than v183fix1 - don't know yet, why.)
    Since it contains compilation fixes, also please try to compile the source with your favorite compiler. I tested the following:

    - Visual Studio 2019 Community Edition (Windows) - using the IDE
    - MinGW-w64 8.1.0 (Windows) - using the batch script
    - GCC 8.3.0 (Lubuntu) - using the makefile
    - clang 8.0.0-3 (Lubuntu) - using the makefile

    @moisesmcardona, could you try to build for arm and run it on arm?

  20. Thanks (4):

    Darek (8th June 2020),Mike (8th June 2020),moisesmcardona (9th June 2020),Sebastian (9th June 2020)

  21. #1877
    Member
    Join Date
    Dec 2008
    Location
    Poland, Warsaw
    Posts
    1,148
    Thanks
    702
    Thanked 455 Times in 352 Posts
    I've noticed that exe model is training even the x86/x64 code was not found (before the segmentation phase) - is it OK?

  22. #1878
    Member Gotty's Avatar
    Join Date
    Oct 2017
    Location
    Switzerland
    Posts
    466
    Thanks
    320
    Thanked 308 Times in 165 Posts
    Yes. Both the text training and exe training happens before any compression begins, and before paq8px would know what may come... The exe model is used for all kind of binary data, not just for exe blocks (as the name would suggest). The exe model turns off only for text blocks for speedup. This is the reason why exe training happens no matter what (when you specify the -e option of course).
    I know, you use exe training with some files in order to achieve maximum compression, so that will cause differences when compared to 183fix1..187 results (maybe excluding 184). If you don't use exe training
    for a file, they should be identical for these releases. If they don't match, then we have a problem
    Sorry for the many "fix" releases lately, I know you are waiting for something to test finally

  23. Thanks:

    Darek (8th June 2020)

  24. #1879
    Member Gotty's Avatar
    Join Date
    Oct 2017
    Location
    Switzerland
    Posts
    466
    Thanks
    320
    Thanked 308 Times in 165 Posts
    Quote Originally Posted by DZgas View Post
    paq8px_v183fix1 is the latest version that runs on my very old cpu AMD Athlon II X4 640
    paq8px_v185 which was placed here does not work on my pc, it is runs but it gives error witch start compression, but it works on my laptop Intel Celeron N3050
    Could you please try running 187fix1 on both your PCs? General CPU support should be back to normal.

  25. #1880
    Member
    Join Date
    Dec 2008
    Location
    Poland, Warsaw
    Posts
    1,148
    Thanks
    702
    Thanked 455 Times in 352 Posts
    I've tested paq8px v187fix1 on my testset and hmmmm...... it looks that there are a some drawbacks there compared to paq8px_v187.

    In general compression loss is about 10.6KB - not to much, not to big, but it always step back to scores between v182 and 182fix1. paq8px_v183 have better score about these 10KB.

    OK, going to more details:

    1) multimedia files are compressed almost at the point - no changes,
    2) non-multimedia but non textual files loss 0.04% (2.8KB), no gains - every file lose or scores are equal to previous versions,
    3) textual files loss about 7.3% - it's huge loss, no gains, every file lose.

    One tip - files wihout lose (E, F, P, Q) - there are files without text pretraining option used. Other multimedia files also didn't use text pretraining
    Attached Thumbnails Attached Thumbnails Click image for larger version. 

Name:	paq8px_187fix1.jpg 
Views:	9 
Size:	777.3 KB 
ID:	7649  

  26. Thanks:

    Gotty (9th June 2020)

  27. #1881
    Member
    Join Date
    Aug 2008
    Location
    Planet Earth
    Posts
    973
    Thanks
    96
    Thanked 391 Times in 273 Posts
    enwik8:
    16,472,882 bytes, 10,459.378 sec., paq8px_v187fix1 -9

  28. Thanks (2):

    Darek (11th June 2020),Gotty (9th June 2020)

  29. #1882
    Member Gotty's Avatar
    Join Date
    Oct 2017
    Location
    Switzerland
    Posts
    466
    Thanks
    320
    Thanked 308 Times in 165 Posts
    Aha, something is broken with text pre-training - again.

    Code:
    paq8px_v183fix1.exe -9ta z.msg
    paq8px archiver v183fix1 (C) 2019, Matt Mahoney et al.
    
    Creating archive z.msg.paq8px183fix1 in single file mode...
    Pre-training models with text... done [english.dic, 465212 bytes]
    Pre-training models with text... done [english.exp, 19652 bytes]
    
    Filename: z.msg (289 bytes)
    Block segmentation:
     0           | text - eol       |       289 bytes [0 - 288]
    -----------------------
    Total input size     : 289
    Total archive size   : 118
    Code:
    paq8px_v187fix1.exe -8at z.msg
    paq8px archiver v187fix1 (c) 2020, Matt Mahoney et al.
    
    Creating archive z.msg.paq8px187fix1 in single file mode...
    Pre-training models with text... done [english.dic, 770049 bytes]
    Pre-training models with text... done [english.exp, 770049 bytes]
    
    Filename: z.msg (289 bytes)
    Block segmentation:
     0           | text - eol       |       289 bytes [0 - 288]
    -----------------------
    Total input size     : 289
    Total archive size   : 132
    
    Time 95.38 sec, used 2172 MB (2278455225 bytes) of memory
    It looks like this is the exe size.
    I never test the-pretarining - this is what I get .
    Let me fix it quickly.

  30. #1883
    Member Gotty's Avatar
    Join Date
    Oct 2017
    Location
    Switzerland
    Posts
    466
    Thanks
    320
    Thanked 308 Times in 165 Posts

    paq8px_v187fix2

    Code:
    - Fixed string copy issue in "OpenFromMyFolder.hpp" that caused text pretraining to malfunction.
    - Enabled compression levels up to 12 (10 => 7-8 GB, 11 => 14-16 GB, 12 => ~ 28-32 GB depending on the models loaded)
    Attached Files Attached Files

  31. Thanks:

    Mike (9th June 2020)

  32. #1884
    Member Gotty's Avatar
    Join Date
    Oct 2017
    Location
    Switzerland
    Posts
    466
    Thanks
    320
    Thanked 308 Times in 165 Posts
    Sorry, Darek for the extra work. Bonus feature added for your inconvenience.

  33. #1885
    Member
    Join Date
    Dec 2008
    Location
    Poland, Warsaw
    Posts
    1,148
    Thanks
    702
    Thanked 455 Times in 352 Posts
    Quote Originally Posted by Gotty View Post
    Sorry, Darek for the extra work. Bonus feature added for your inconvenience.
    Don't be sorry please. I'ts a matter of tests to find sometime an errors or bugs. It's good that I could help
    Thank you for the bonus - I'll try it instantly...

  34. #1886
    Member
    Join Date
    Aug 2008
    Location
    Planet Earth
    Posts
    973
    Thanks
    96
    Thanked 391 Times in 273 Posts
    enwik8:
    16,190,519 bytes, 10,601.407 sec., paq8px_v187fix2 -12

  35. Thanks (2):

    Darek (9th June 2020),Gotty (9th June 2020)

  36. #1887
    Member
    Join Date
    Jun 2009
    Location
    Puerto Rico
    Posts
    223
    Thanks
    121
    Thanked 41 Times in 31 Posts
    Quote Originally Posted by Gotty View Post
    Code:
    - Ported "Fix jpeg thumbnail compression" from paq8pxd_v76 - Thank you, Kaitz!
    - Fixed an issue with an Image8BitModel context (cm.set(hash(++i, (jump != 0)...) where a calculation result was cast to 32 bit instead of 64 bit and caused incompatibility with v183fix1
    - Fixed the speed issue with the infinite base64 loop patch from v186fix1
    - Removed the unnecessary AVX2 ContextMap Bucket find() function - it fetches 32 bytes but we need ony 14.
    - Restored Visual Studio / MSVC compatibility + provided solution and project files
    - Zlib is now available through a nuget package for Visual Studio
    - The necessary zlib source files are included in a new folder "zlib" for MinGW-W64 and other (windows) compilers
    - Provided a batch file for building with MINGW-W64 (for those who don't use cmake): "build-mingw-w64-generic-publish.cmd" - in the "build" folder
    - Preprocessor macros:
      - Switched from #ifndef NDEBUG to #ifdef VERBOSE wherever detailed debug information is printed on screen
      - Switched from USE_TEXTMODEL / USE_AUDIOMODEL / USE_ZLIB to DISABLE_TEXTMODEL / DISABLE_AUDIOMODEL / DISABLE_ZLIB so when no options are provided these features are included by default
        When you build paq8px yourself and want maximum performance you need to provide the -DNDEBUG flag only (default in "CMakeLists.txt" and in "Build-mingw64-generic-for-publish.cmd")
    - Fixed CPU/SIMD dispatch to enable building for the general public again
    - Some cosmetic changes
    - Archives are still expected to be binary compatible with v183fix1
    Could you guys try the exe found in the build folder? It should run on all x64 PCs. (Strangely it is somewhat slower than v183fix1 - don't know yet, why.)
    Since it contains compilation fixes, also please try to compile the source with your favorite compiler. I tested the following:

    - Visual Studio 2019 Community Edition (Windows) - using the IDE
    - MinGW-w64 8.1.0 (Windows) - using the batch script
    - GCC 8.3.0 (Lubuntu) - using the makefile
    - clang 8.0.0-3 (Lubuntu) - using the makefile

    @moisesmcardona, could you try to build for arm and run it on arm?
    Sure thing! I'll test v187fix2 later today.

  37. Thanks:

    Gotty (9th June 2020)

  38. #1888
    Member
    Join Date
    Jun 2009
    Location
    Puerto Rico
    Posts
    223
    Thanks
    121
    Thanked 41 Times in 31 Posts
    Unfortunately, the __attribute__ lines do not work on GCC on ARM, so additional checks needed to be added on Mixer.hpp and Bucket.hpp. Also, another check needed to be added to simd.hpp since ARM doesn't include Intel's vectorization header files.

    Other than the above changes, it compiled and ran fine on ARM.

    Binaries are in the build folder.

    Code:
    paq8px_v187fix3
    2020.06.09
    - Restored compilation on ARM processors using GCC (Must use -DNATIVECPU=ON on cmake).
    Attached Files Attached Files

  39. Thanks:

    Gotty (9th June 2020)

  40. #1889
    Member
    Join Date
    Jun 2009
    Location
    Puerto Rico
    Posts
    223
    Thanks
    121
    Thanked 41 Times in 31 Posts
    @Gotty, it seems PAQ8PX also has another bug.

    From the documentation:
    Code:
     OUTPUTSPEC:
        When omitted: the archive will be created in the same folder where the
        input file resides. The archive filename will be constructed from the
        input file name by appending .paq8px187fix3 extension
        to it.
    But it actually creates the output file in the current working directory

    For example, If I'm in C:\temp, it will save the file in C:\Temp rather than where the input file is.

  41. Thanks:

    Gotty (9th June 2020)

  42. #1890
    Member
    Join Date
    Dec 2008
    Location
    Poland, Warsaw
    Posts
    1,148
    Thanks
    702
    Thanked 455 Times in 352 Posts
    My testset scores curve of scores vs method. Similarly as in paq8pxd for my testset curve have a minimum with -9 option
    But it means that for enwik8/9 and 4 corpuses scores could be better!
    Attached Thumbnails Attached Thumbnails Click image for larger version. 

Name:	paq8px_v187fix2_curve.jpg 
Views:	26 
Size:	47.4 KB 
ID:	7652  

  43. Thanks:

    Gotty (9th June 2020)

Similar Threads

  1. FrontPAQ - GUI frontend for PAQ8PF and PAQ8PX
    By LovePimple in forum Download Area
    Replies: 26
    Last Post: 17th January 2019, 13:36
  2. Alternative paq8px builds
    By M4ST3R in forum Download Area
    Replies: 20
    Last Post: 25th June 2010, 16:19
  3. Optimized paq7asm.asm code not compatible with paq8px?
    By M4ST3R in forum Data Compression
    Replies: 7
    Last Post: 3rd June 2009, 15:34

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
  •