Page 57 of 58 FirstFirst ... 74755565758 LastLast
Results 1,681 to 1,710 of 1718

Thread: paq8px

  1. #1681
    Member Gotty's Avatar
    Join Date
    Oct 2017
    Location
    Hungary
    Posts
    378
    Thanks
    259
    Thanked 263 Times in 142 Posts
    A bit of enwik8 history to see how far we came from.

    Code:
    paq8px_v49   -8          17'733'057
    paq8px_v77   -8          17'629'076
    paq8px_v122  -8[et]      17'481'434
    paq8px_v123  -8?         17'461'019
    Paq8px_v124  -s8[eta]    17'301'948
    Paq8px_v136  -s9[eta]    17'181'903
    Paq8px_v136b -s9[eta]    17'013'211
    Paq8px_v138  -s9[eta]    16'984'529
    Paq8px_v141  -s9eta      16'872'591
    paq8px_v144  -9ta        16'806'829
    paq8px_v147  -9ta        16'791'924
    Paq8px_v149  -9eta       16'742'288
    Paq8px_v153  -9eta       16'736'395
    Paq8px_v154a -9eta       16'737'358
    Paq8px_v165  -s9eta      16'618'525
    Paq8px_v166  -s9eta      16'619'686
    Paq8px_v167  -s9eta      16'625'547
    Paq8px_v170  -s9eta      16'518'653
    Paq8px_v171  -s9eta      16'520'179
    Paq8px_v172  -s9eta      16'471'210
    Paq8px_v173  -s9eta      16'461'020
    paq8px_v179  -s9eta      16'456'797
    Paq8px_v181  -9ta        16'446'172
    Paq8px_v182  -9ta        16'428'290
    Last edited by Gotty; 11th September 2019 at 12:28. Reason: Added paq8px_v179

  2. The Following 4 Users Say Thank You to Gotty For This Useful Post:

    Darek (11th September 2019),LucaBiondi (11th September 2019),Mike (11th September 2019),schnaader (11th September 2019)

  3. #1682
    Member
    Join Date
    Dec 2008
    Location
    Poland, Warsaw
    Posts
    940
    Thanks
    558
    Thanked 379 Times in 283 Posts
    Here are scores for my testset for paq8px v182 - about 0.18% of gain = 18KB less -> that means new record overall for my testset, best ever score for 0.WAV and L.PAK!
    Besides good improvements for bigger files there also some loses for smaller textual files.

    And to Gotty's table my scores for paq8px v179 for enwik8:

    16'456'797 - enwik8 -s9eta -Paq8px_v179
    16'079'926 - enwik8.drt -s9eta -Paq8px_v179

    One calculation more - based on my full enwik scores for paq8px v172:

    16'471'210 - enwik8 -s9eta -Paq8px_v172
    16'081'924 - enwik8.drt -s9eta -Paq8px_v172
    133'708'688 - enwik9_1423 -s9eta -Paq8px_v172
    129'893'797 - enwik9_1423.drt -s9eta -Paq8px_v172

    I've estimate scores of paq8 v182 for enwik9. It should be about:

    133'3xx'xxx for non-preprocessed enwik9 and
    129'6xx'xxx for preprocessed file -it's 6'th place on LTCB benchmark!
    Attached Thumbnails Attached Thumbnails Click image for larger version. 

Name:	paq8px_v182.jpg 
Views:	22 
Size:	641.9 KB 
ID:	6849  

  4. The Following 2 Users Say Thank You to Darek For This Useful Post:

    Gotty (11th September 2019),LucaBiondi (11th September 2019)

  5. #1683
    Member Gotty's Avatar
    Join Date
    Oct 2017
    Location
    Hungary
    Posts
    378
    Thanks
    259
    Thanked 263 Times in 142 Posts
    Darek, again your scores helped me understand something.
    I don't use pre-training during my tests in order to see how the models can handle file content on their own - without the initial boost. My results show nice gains for almost all text files due to the changes in WordModel. With pre-training "on" there is almost always a significant loss - and I now know why. I'm gonna fix that in the next release.
    Thanx!

  6. The Following 2 Users Say Thank You to Gotty For This Useful Post:

    Darek (17th September 2019),LucaBiondi (16th September 2019)

  7. #1684
    Member
    Join Date
    Dec 2008
    Location
    Poland, Warsaw
    Posts
    940
    Thanks
    558
    Thanked 379 Times in 283 Posts
    Quote Originally Posted by Gotty View Post
    A bit of enwik8 history to see how far we came from.

    Code:
    paq8px_v49     -8           17'733'057
    paq8px_v69kzu  -s8          17'693'476
    paq8px_v77     -8           17'629'076
    Paq8px_v93     -s8          17'604'178
    Paq8px_v95     -s8          17'569'155
    Paq8px_v96     -s8          17'568'078
    Paq8px_v99     -s8          17'592'129
    Paq8px_v112    -s8          17'562'376
    paq8px_v122    -8[et]       17'481'434
    paq8px_v123    -s8[eta]     17'461'019
    Paq8px_v124    -s8[eta]     17'301'948
    Paq8px_v136    -s9[eta]     17'181'903
    Paq8px_v136b   -s9[eta]     17'013'211
    Paq8px_v138    -s9[eta]     16'984'529
    Paq8px_v139    -s9[eta]     16'973'268
    Paq8px_v140    -s9[eta]     16'919'232
    Paq8px_v141    -s9eta       16'872'591
    Paq8px_v142    -s9[eta]     16'813'905
    paq8px_v144    -9ta         16'806'829
    paq8px_v147    -9ta         16'791'924
    Paq8px_v149    -9eta        16'742'288
    Paq8px_v153    -9eta        16'736'395
    Paq8px_v154a   -9eta        16'737'358
    Paq8px_v165    -s9eta       16'618'525
    Paq8px_v166    -s9eta       16'619'686
    Paq8px_v167    -s9eta       16'625'547
    Paq8px_v168    -s9eta       16'601'224
    Paq8px_v169    -s9eta       16'586'693
    Paq8px_v169a   -s9eta       16'534'816
    Paq8px_v170    -s9eta       16'518'653
    Paq8px_v171    -s9eta       16'520'179
    Paq8px_v172    -s9eta       16'471'210
    Paq8px_v173    -s9eta       16'461'020
    paq8px_v179    -s9eta       16'456'797
    Paq8px_v181    -9ta         16'446'172
    Paq8px_v182    -9ta         16'428'290
    I've added some my older scores and the chart with enwik8 scores history.
    I have a little different scores for v122 and v124 versions - I'll check it.
    Attached Thumbnails Attached Thumbnails Click image for larger version. 

Name:	paq8px_enwik8_history.jpg 
Views:	28 
Size:	154.7 KB 
ID:	6850  

  8. The Following 2 Users Say Thank You to Darek For This Useful Post:

    Gotty (11th September 2019),LucaBiondi (11th September 2019)

  9. #1685
    Member Gotty's Avatar
    Join Date
    Oct 2017
    Location
    Hungary
    Posts
    378
    Thanks
    259
    Thanked 263 Times in 142 Posts
    My source for v122 and v124:

    Quote Originally Posted by Darek View Post
    mpais scores:
    File: enwik8
    paq8px_v122 17.481.386 bytes
    paq8px_v123 17.461.019 bytes

    my scores:
    File: enwik8
    paq8px_v122 17.481.434 bytes -8[et]
    paq8px_v123 run
    paq8px_v124 17.301.948 bytes -8[eta] - very nice improvement - I'll check v123 scores then

  10. The Following User Says Thank You to Gotty For This Useful Post:

    LucaBiondi (11th September 2019)

  11. #1686
    Member
    Join Date
    Dec 2008
    Location
    Poland, Warsaw
    Posts
    940
    Thanks
    558
    Thanked 379 Times in 283 Posts
    I've checked v122 and v124 versions - I've compressed it again - and:

    paq8px v122 - enwik8 -8[ta] = 17'481'434 -> your score is ok, my score was identical to mpais but it could be score w/o header (48b??)
    paq8px v124 - enwik8 -8[eta] = 17'461'692 -> same as my previous score - maybe there were two versions of v124 or different compiles (linux/Windows...) because there are "e" option. But if there be as big difference? Strange.
    paq8px v123 - score mpais is the same as my score

  12. The Following User Says Thank You to Darek For This Useful Post:

    LucaBiondi (11th September 2019)

  13. #1687
    Member Alexander Rhatushnyak's Avatar
    Join Date
    Oct 2007
    Location
    Canada
    Posts
    235
    Thanks
    38
    Thanked 85 Times in 46 Posts
    Quote Originally Posted by Gotty View Post
    A bit of enwik8 history to see how far we came from.
    Code:
    paq8px_v49   -8          17'733'057
    paq8px_v77   -8          17'629'076
    ...
    Paq8px_v181  -9ta        16'446'172
    Paq8px_v182  -9ta        16'428'290
    This table would be more valuable if it included compression time for at least some of the entries.

    I started testing v182 on LPCB images, and as far as I can see now, compression is going to take ~200 hours... And then there's the decompression half of it.
    To build a 32-bit Windows executable with MinGW 8.1, I had to remove "64i32" from the line with #define STAT _stat64i32

    This newsgroup is dedicated to image compression:
    http://linkedin.com/groups/Image-Compression-3363256

  14. The Following 2 Users Say Thank You to Alexander Rhatushnyak For This Useful Post:

    Gotty (12th September 2019),Hakan Abbas (11th September 2019)

  15. #1688
    Member Gotty's Avatar
    Join Date
    Oct 2017
    Location
    Hungary
    Posts
    378
    Thanks
    259
    Thanked 263 Times in 142 Posts
    Quote Originally Posted by Alexander Rhatushnyak View Post
    This table would be more valuable if it included compression time for at least some of the entries.
    It's true. Although I have runtimes in the logs paq8px records during compression, unfortunately they are unreliable: I always run tests in parallel or sometimes pause one or more of the command line windows to give the others some air. My runtimes are useless. As far as I know Darek also runs tests in parallel. Most of the above results came from him.
    I could reproduce the results with runtimes on an idles system, but I don't have any idle system

    Quote Originally Posted by Alexander Rhatushnyak View Post
    I started testing v182 on LPCB images, and as far as I can see now, compression is going to take ~200 hours... And then there's the decompression half of it.
    Thanx! Awaiting for the results!

    Quote Originally Posted by Alexander Rhatushnyak View Post
    To build a 32-bit Windows executable with MinGW 8.1, I had to remove "64i32" from the line with #define STAT _stat64i32
    Thanx for the info, I'll look into it.
    A 32-bit executable would be very slow compared to a 64-bit one due to emulated 64 bit operations (there are a lot 64-bit multiplications in hashing for example). Also I'm not sure if level -8 and -9 would work as expected: they need 2GB+ RAM. I hope you don't do anything serious with a 32 bit executable.

  16. #1689
    Member
    Join Date
    Dec 2008
    Location
    Poland, Warsaw
    Posts
    940
    Thanks
    558
    Thanked 379 Times in 283 Posts
    > As far as I know Darek also runs tests in parallel.
    Yes, then most of times are not reliable due to this or the fact that I've changed my laptop, but I could test it in free time.
    Now I've started to test enwik9 for paq8px v182 - after that I could test some entries - if you have some propositions then let me know. Otherwise I'll choose some versions to test.
    DRT version of enwik8 was tested by paq8px v182 in 8k sec then It would be about 11-13k sec by one test of pure file = 6-8 entries by day.

  17. #1690
    Member Gotty's Avatar
    Join Date
    Oct 2017
    Location
    Hungary
    Posts
    378
    Thanks
    259
    Thanked 263 Times in 142 Posts
    How about measuring enwik7 runtimes for all versions, and enwik8 runtimes only for some versions (maybe for the oldest, the newest and one in between)? This way we can calculate/interpolate an approximated runtime for the missing enwik8 ones? Anyway, we don't need precise measurements, just to be able to plot a curve.

  18. #1691
    Member
    Join Date
    Dec 2008
    Location
    Poland, Warsaw
    Posts
    940
    Thanks
    558
    Thanked 379 Times in 283 Posts
    Good idea. I didn't think about it. For me it looks much more reasonable.

  19. #1692
    Member Gotty's Avatar
    Join Date
    Oct 2017
    Location
    Hungary
    Posts
    378
    Thanks
    259
    Thanked 263 Times in 142 Posts

    paq8px_v182fix1

    Code:
    - Text pre-training is applied to WordModel
    - Fixed 32-bit compilation issue (_stat64i32->_stat)
    No change in compression except when using text pre-training: -t

    So the issue with text training in v182 was that I removed a "text" context from NormalModel, and merged it (along with the DistanceModel) to WordModel. But then text training was not applied any more to this context and in most cases compression of text files degraded significantly when running with text pre-training.

    With this minor version I have a simple fix, I apply text pre-training not only to NormalModel, but to WordModel as well.
    This will not only fix the issue of v182, but will give additional boost when compressing text files with pre-training.
    Attached Files Attached Files

  20. The Following 3 Users Say Thank You to Gotty For This Useful Post:

    Darek (13th September 2019),kaitz (16th September 2019),Mike (13th September 2019)

  21. #1693
    Member
    Join Date
    Sep 2014
    Location
    Italy
    Posts
    35
    Thanks
    54
    Thanked 22 Times in 13 Posts
    Hi!

    Gotty this time you have got a great great job! wow!

    Theese are results from my big testset V181 vs V182

    Click image for larger version. 

Name:	image001(3).png 
Views:	21 
Size:	103.3 KB 
ID:	6857

    JPEG achieve 10 KB!
    PDF gain 134 KB!
    TXT gain 30KB!
    ISO gain 50KB!
    MP3 AND XML loose some.

    Click image for larger version. 

Name:	image002(1).png 
Views:	20 
Size:	148.5 KB 
ID:	6858

    New Overall record!
    New record for PDF, MP4,TXT, BAK, EXE and ISO files!


    Thank you!!!
    Luca

  22. The Following 2 Users Say Thank You to LucaBiondi For This Useful Post:

    Darek (13th September 2019),Gotty (13th September 2019)

  23. #1694
    Member Gotty's Avatar
    Join Date
    Oct 2017
    Location
    Hungary
    Posts
    378
    Thanks
    259
    Thanked 263 Times in 142 Posts
    Code:
    Paq8px_v181     -9ta         16'446'172
    Paq8px_v182     -9ta         16'428'290
    Paq8px_v182fix1 -9ta         16'411'564

  24. The Following User Says Thank You to Gotty For This Useful Post:

    Darek (13th September 2019)

  25. #1695
    Programmer schnaader's Avatar
    Join Date
    May 2008
    Location
    Hessen, Germany
    Posts
    551
    Thanks
    206
    Thanked 182 Times in 87 Posts
    Quote Originally Posted by Gotty View Post
    Code:
      - WordModel now extracts text from pdf files and processes it as it would be a separate text file
    Good work on this! Tried to do this as a separate transformation tool recently, and it didn't work out. Problems were: The length of the strings between brackets had to be coded, so e.g. replacing them with spaces does this, but adds information instead of just moving the text. Also, for many files, the kerning numbers between the brackets correlate with the previous and next character in the brackets, so separating them hurts compression. So context modelling is the way to go here.

    Another PDF thing that is relatively easy to implement would be xrefs. This is the big table at the end of PDF files. It encodes all the offsets of "x 0 obj" (where x is a incrementing number) and sorting this list by x leads to the xref table (although there can be some deleted objects between entries that don't appear in the previous part). Not a big saving as xref tables compress well anyway, but some KB per PDF.
    http://schnaader.info
    Damn kids. They're all alike.

  26. The Following User Says Thank You to schnaader For This Useful Post:

    Gotty (13th September 2019)

  27. #1696
    Member
    Join Date
    Dec 2008
    Location
    Poland, Warsaw
    Posts
    940
    Thanks
    558
    Thanked 379 Times in 283 Posts
    Scores for my testset for paq8px v182fix1 - very good work for smaller files - > average gain for my textual files is on the level of 2.1%!
    That means my testset textual files lose now to best cmix (v17) only 1.1%! It's very, very close now.
    This version also get best overall scores (and beat best cmix scores) for O.APR, T.DOC and Y.CFG!
    Attached Thumbnails Attached Thumbnails Click image for larger version. 

Name:	paq8px_v182_fix1.jpg 
Views:	22 
Size:	724.1 KB 
ID:	6865  

  28. The Following 2 Users Say Thank You to Darek For This Useful Post:

    Gotty (13th September 2019),kaitz (16th September 2019)

  29. #1697
    Member
    Join Date
    Dec 2008
    Location
    Poland, Warsaw
    Posts
    940
    Thanks
    558
    Thanked 379 Times in 283 Posts
    Scores of 4 Corpuses for paq8px v182fix1 - amazing improvements especially for smaller files (Calgary and Canterbury corpuses) - almost all the best scores for paq8px and the biggest gain I've ever seen for paq8px during the next versions (0.8-0.9%)! For ob1, progb, progc (Calgary), fields.c, grammar.lsp, sum, xargs.1 (Canterbury), FlashMX.pdf (MaximumCompression) this version have the best overall scores and beat latest cmix v18 version!

    I have one insight (maybe I'm wrong) but most of changes on fix1 versions gives 200-500 bytes of gain independent to file size (it's similar on R.DOC and G.EXE or even smaller for K.WAD) - it looks like this improvement works only or mostly for first 100-200KB or I'm wrong...

    One tip to more improve on Silesia corpus (I know it's tuning mostly for this corpus) -> there are some changes in paq8pxd version by Kaitz which a) adds DEC Alpha parser/model - it's gives about 500KB of gain on Mozilla file. b) There are model which gives about 60KB of gain for NCI file. Files oofice, osdb and x-ray are also better compression but maybe it's specific for this version of paq.

    Additionaly there are scores of enwik8 and enwik9 for paq8px v182 (w/o fix yet):
    16'838'907 - enwik8 -s7eta -Paq8px_v182
    16'435'259 - enwik8.drt -s7eta -Paq8px_v182
    16'428'290 - enwik8 -s9eta -Paq8px_v182
    16'086'695 - enwik8.drt -s9eta -Paq8px_v182
    133'672'575 - enwik9 -s9eta -Paq8px_v182
    129'948'994 - enwik9.drt -s9eta -Paq8px_v182
    133'591'653 - enwik9_1423 -s9eta -Paq8px_v182 - best score for all paq8px version (except paq8pxd)
    129'809'666 - enwik9_1423.drt -s9eta -Paq8px_v182 - best score for all aq8px version (except paq8pxd)
    Attached Thumbnails Attached Thumbnails Click image for larger version. 

Name:	paq8px_v182fix1_4Corpuses.jpg 
Views:	13 
Size:	2.06 MB 
ID:	6871  

  30. The Following User Says Thank You to Darek For This Useful Post:

    Gotty (16th September 2019)

  31. #1698
    Member Gotty's Avatar
    Join Date
    Oct 2017
    Location
    Hungary
    Posts
    378
    Thanks
    259
    Thanked 263 Times in 142 Posts
    Quote Originally Posted by Darek View Post
    I have one insight (maybe I'm wrong) but most of changes on fix1 versions gives 200-500 bytes of gain independent to file size (it's similar on R.DOC and G.EXE or even smaller for K.WAD) - it looks like this improvement works only or mostly for first 100-200KB or I'm wrong...
    Yes, you are absolutely right! Fix1 contains the extended text-pretraining.
    Any pre-training helps only during the first some kilobytes (of text files of course), when the NormalModel and WordModel of paq8px doesn't know anything about words and their morphology. As soon as the NormalModel and WordModel has learnt enough from the real data the effect of pre-training fades away and the model takes on. It means that the larger the file, the less text-pretraining helps proportionally. I don't know when it happens, but your feeling of 100K-200K seems right.

    The truth is: text-pretraining is not advantageous. Look:

    paq8px_v182fix1 -9a : 16'456'404 (no pre-training)
    paq8px_v182fix1 -9at: 16'411'564 (with pre-training)
    The difference is 41'840 bytes

    In order to decompress you'll need paq8px_v182fix1.exe (it's size must be added to the size of both results), and for the second case with pre-training, you'll need the pre-training files as well. So how large are they? Let's see.

    paq8px_v182fix1 -9a: 109'701 (input file is a list file containing: english.dic, english.emb, english.exp)
    16'411'564+109'701= 16'521'265
    We lost 64'861 bytes! The result without pre-training is better!

    I suggest that we don't use pre-training at all in any benchmarks - or when we use pre-training we must add the compressed size of the pre-training files to the final result. If we don't take into account these files, the result gives us a false sense that paq8px has beaten cmix.
    I suppose if you don't use pre-training neither for paq8px nor for cmix, cmix would still beat paq8px. When you have some time, could you run a test only on the files in your testset where paq8px has beaten cmix? I wounder what the results would be.

  32. #1699
    Member
    Join Date
    May 2008
    Location
    Estonia
    Posts
    395
    Thanks
    148
    Thanked 225 Times in 123 Posts
    Quote Originally Posted by Darek View Post

    One tip to more improve on Silesia corpus (I know it's tuning mostly for this corpus) -> there are some changes in paq8pxd version by Kaitz which a) adds DEC Alpha parser/model - it's gives about 500KB of gain on Mozilla file. b) There are model which gives about 60KB of gain for NCI file. Files oofice, osdb and x-ray are also better compression but maybe it's specific for this version of paq.
    nci improvement comes from wrt filter, as all other large files.
    DEC Alpha main improvement comes mostly from byte order swap and call filter.
    osdb improvment comes from Wordmodel i think, cant remember what context/check it was.
    not sure about others.

    As for testing with option -t
    I always test without it on files. At least when comparing with pxd versions.
    KZo


  33. The Following 2 Users Say Thank You to kaitz For This Useful Post:

    Darek (17th September 2019),Gotty (16th September 2019)

  34. #1700
    Member Gotty's Avatar
    Join Date
    Oct 2017
    Location
    Hungary
    Posts
    378
    Thanks
    259
    Thanked 263 Times in 142 Posts
    Quote Originally Posted by kaitz View Post
    As for testing with option -t
    I always test without it on files. At least when comparing with pxd versions.
    I noticed that when you posted the results last time and it matched to my results exactly (I also run tests on level -8 ) - except for some files where I used "-a" (adaptive learning rate). We are on the same wavelength.

  35. The Following User Says Thank You to Gotty For This Useful Post:

    LucaBiondi (16th September 2019)

  36. #1701
    Member Gotty's Avatar
    Join Date
    Oct 2017
    Location
    Hungary
    Posts
    378
    Thanks
    259
    Thanked 263 Times in 142 Posts
    Quote Originally Posted by kaitz View Post
    nci improvement comes from wrt filter, as all other large files.
    DEC Alpha main improvement comes mostly from byte order swap and call filter.
    osdb improvment comes from Wordmodel i think, cant remember what context/check it was.
    not sure about others.
    Thanx! I have it on my to do list for a long time - since Darek suggested, and you gave these hints.

  37. The Following User Says Thank You to Gotty For This Useful Post:

    LucaBiondi (16th September 2019)

  38. #1702
    Member
    Join Date
    May 2008
    Location
    Estonia
    Posts
    395
    Thanks
    148
    Thanked 225 Times in 123 Posts
    More ...
    JPEG -> what if you removed final APM in SSE class for JPEG. Will compression be better?
    KZo


  39. The Following User Says Thank You to kaitz For This Useful Post:

    LucaBiondi (16th September 2019)

  40. #1703
    Member
    Join Date
    Sep 2014
    Location
    Italy
    Posts
    35
    Thanks
    54
    Thanked 22 Times in 13 Posts
    Quote Originally Posted by kaitz View Post
    More ...
    JPEG -> what if you removed final APM in SSE class for JPEG. Will compression be better?
    If you want add an option i will be happy to test it!
    Luca

  41. #1704
    Member Gotty's Avatar
    Join Date
    Oct 2017
    Location
    Hungary
    Posts
    378
    Thanks
    259
    Thanked 263 Times in 142 Posts
    Line 11105 in v182fix1?
    pr = (pr+pr0+1)>>1;
    Hmmm.. It's worse if a remove it (just tested with smaller and larger files as well).
    Is this the line you meant?

    Edit: @Luca: I tested it on your 3 large files Of course. That is my large test set

  42. #1705
    Member
    Join Date
    May 2008
    Location
    Estonia
    Posts
    395
    Thanks
    148
    Thanked 225 Times in 123 Posts
    In SSE class like this:
    Code:
    case JPEG: {
            pr = pr0;
            break;
          }
    In pxd i dont have final APM, it really hurts compression.
    KZo


  43. The Following User Says Thank You to kaitz For This Useful Post:

    Gotty (16th September 2019)

  44. #1706
    Member Gotty's Avatar
    Join Date
    Oct 2017
    Location
    Hungary
    Posts
    378
    Thanks
    259
    Thanked 263 Times in 142 Posts
    Aham, that helps indeed (with larger jpegs), and it's logical, too!
    Going in the next release.
    Thanx so much! Luca will be happy.

    "Preview" attached.
    Luca, it's all yours.
    Attached Files Attached Files

  45. The Following 3 Users Say Thank You to Gotty For This Useful Post:

    Darek (17th September 2019),kaitz (16th September 2019),LucaBiondi (17th September 2019)

  46. #1707
    Member
    Join Date
    May 2008
    Location
    Estonia
    Posts
    395
    Thanks
    148
    Thanked 225 Times in 123 Posts
    Code:
    IMG080.jpg (967711 bytes)
    paq8px_182.fix1 -8    737230 Time 23.43 sec, used 2372 MB (2487680938 bytes) of memory
    paq8px_v182fix2 -8    736736 Time 21.69 sec, used 2372 MB (2487680938 bytes) of memory
    paq8pxd_v68_AVX2 -s8  736627 Time 19.29 sec, used 2209 MB (2316655105 bytes) of memory
    KZo


  47. The Following 3 Users Say Thank You to kaitz For This Useful Post:

    Darek (17th September 2019),Gotty (16th September 2019),LucaBiondi (17th September 2019)

  48. #1708
    Member
    Join Date
    Sep 2014
    Location
    Italy
    Posts
    35
    Thanks
    54
    Thanked 22 Times in 13 Posts
    Quote Originally Posted by Gotty View Post
    Aham, that helps indeed (with larger jpegs), and it's logical, too!
    Going in the next release.
    Thanx so much! Luca will be happy.

    "Preview" attached.
    Luca, it's all yours.

    Thanks Gotty ...ready, just started to test!

    Luca

  49. #1709
    Member
    Join Date
    Dec 2008
    Location
    Poland, Warsaw
    Posts
    940
    Thanks
    558
    Thanked 379 Times in 283 Posts
    enwik7 test scores with timings - in Excel file. I've made it for all versions that I've had on the laptop.
    And the two charts - scores and timings by version and scores in time (based on files dates).
    I think it could be good also input into Jarek's database.
    Attached Thumbnails Attached Thumbnails Click image for larger version. 

Name:	paq8px_enwik7_history_versions.jpg 
Views:	21 
Size:	417.1 KB 
ID:	6877   Click image for larger version. 

Name:	paq8px_enwik7_history_time.jpg 
Views:	13 
Size:	90.1 KB 
ID:	6878  
    Attached Files Attached Files

  50. The Following 2 Users Say Thank You to Darek For This Useful Post:

    Gotty (17th September 2019),schnaader (17th September 2019)

  51. #1710
    Member
    Join Date
    Dec 2008
    Location
    Poland, Warsaw
    Posts
    940
    Thanks
    558
    Thanked 379 Times in 283 Posts
    And my testset scores by paq8px v182fix2 - for F.JPG file this version got the best overall score! That means paq8px variant holds 9 files records at now!

    For A10.JPG from MaximumCompression paq8px v182fix2 got also the best score overall = 628'405 bytes!

    Additioaly there are enwik8 all scores for v182fix1:

    16'832'420 - enwik8 -s7eta -Paq8px_v182fix1
    16'437'368 - enwik8.drt -s7eta -Paq8px_v182fix1
    16'411'564 - enwik8 -s9eta -Paq8px_v182fix1 - best score for paq8px series
    16'086'836 - enwik8.drt -s9eta -Paq8px_v182fix1
    Attached Thumbnails Attached Thumbnails Click image for larger version. 

Name:	paq8px_v182fix2.jpg 
Views:	10 
Size:	722.5 KB 
ID:	6880  
    Last edited by Darek; 17th September 2019 at 18:02.

  52. The Following User Says Thank You to Darek For This Useful Post:

    Gotty (17th September 2019)

Page 57 of 58 FirstFirst ... 74755565758 LastLast

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
  •