Page 6 of 22 FirstFirst ... 4567816 ... LastLast
Results 151 to 180 of 642

Thread: Paq8pxd dict

  1. #151
    Member
    Join Date
    Sep 2014
    Location
    United States
    Posts
    5
    Thanks
    0
    Thanked 0 Times in 0 Posts
    Hello. I'm coming in late on this but I am interested in the development of this program. What is the most recent stable version? I've been playing around with version 5 (as posted on Matt Mahoney's website) but it seems that I'm woefully out of date.

    My day job is in working with Java but I've always liked the speed C/C++ affords. I'm gonna study the code during my spare time and if I have time, perhaps contribute/branch.

    Additionally, how does this version compare to the other PAQ* compression algorithms (as seen on here http://mattmahoney.net/dc/) when it comes to compression ratio? I don't mind slow speed as much. I can run these things overnight. I'm more intersted in maximum compression just for the hell of it.

  2. #152
    Member Skymmer's Avatar
    Join Date
    Mar 2009
    Location
    Russia
    Posts
    681
    Thanks
    37
    Thanked 168 Times in 84 Posts
    Hello. I'm coming in late on this but I am interested in the development of this program. What is the most recent stable version?
    Hi! Well, I think that the v13 is the one. Latest v14 currently has some problems with compilers compatibility and (potentially) stability.

    Additionally, how does this version compare to the other PAQ* compression algorithms (as seen on here http://mattmahoney.net/dc/) when it comes to compression ratio?
    http://mattmahoney.net/dc/silesia.html
    http://www.squeezechart.com/bitmap.html
    http://mattmahoney.net/dc/text.html

    I don't mind slow speed as much. I can run these things overnight. I'm more intersted in maximum compression just for the hell of it.
    Nice to hear that




    Seems that v14 is a natural problematic child. During this week I tried to build the working binary with mingw. And I failed.
    Compression is OK but either I got "out of memory" message during decompression (even on -4:2), either process crashes during decompression.
    Its possible to create a binary which is compresses\decompresses without any errors but decompressed file is differ to original.
    I tried a lot of different math and floating point related options, used different builds of mingw and its branches including exotic ones, and..... and still no luck.
    I almost close to give up but I will not do it cause there are some good news. I managed to build the EXE which is compresses\decompresses without errors and decompressed file is identical to original.
    But its only valid for -1:8
    The option is: -DWINDOWS -v -static -s -march=pentium4 -O3 -msse2 -mlong-double-128 -ffloat-store -Xlinker --large-address-aware
    Last edited by Skymmer; 7th September 2014 at 00:35.

  3. The Following User Says Thank You to Skymmer For This Useful Post:

    Stephan Busch (7th September 2014)

  4. #153
    Member
    Join Date
    Sep 2014
    Location
    United States
    Posts
    5
    Thanks
    0
    Thanked 0 Times in 0 Posts
    Quote Originally Posted by Skymmer View Post
    Hi! Well, I think that the v13 is the one. Latest v14 currently has some problems with compilers compatibility and (potentially) stability.


    http://mattmahoney.net/dc/silesia.html
    http://www.squeezechart.com/bitmap.html
    http://mattmahoney.net/dc/text.html


    Nice to hear that




    Seems that v14 is a natural problematic child. During this week I tried to build the working binary with mingw. And I failed.
    Compression is OK but either I got "out of memory" message during decompression (even on -4:2), either process crashes during decompression.
    Its possible to create a binary which is compresses\decompresses without any errors but decompressed file is differ to original.
    I tried a lot of different math and floating point related options, used different builds of mingw and its branches including exotic ones, and..... and still no luck.
    I almost close to give up but I will not do it cause there are some good news. I managed to build the EXE which is compresses\decompresses without errors and decompressed file is identical to original.
    But its only valid for -1:8
    The option is: -DWINDOWS -v -static -s -march=pentium4 -O3 -msse2 -mlong-double-128 -ffloat-store -Xlinker --large-address-aware
    Is there a github or a sourceforge for the most recent code? This would be a good project to browse so that my C++ skills don't atrophy. I am not asked to call upon them much now that I've graduated college. Just Java these days.

    The squeeze chart is comprehensive, but can be a bit nebulous in some places. The color coding isn't well explained. Additionally, the use of decimal points instead of my preferred comma to delimit large numbers threw me off a bit. An Excel or Open office spreadsheet would be nice. I could probably write a quick HTML parser to go through and at least convert it to a .csv format for easy processing into an excel spreadsheet. I guess it's something to keep me busy on the few days I do have off work...

  5. #154
    Member
    Join Date
    May 2008
    Location
    Estonia
    Posts
    385
    Thanks
    142
    Thanked 213 Times in 115 Posts
    Quote Originally Posted by Skymmer View Post
    Seems that v14 is a natural problematic child. During this week I tried to build the working binary with mingw. And I failed.
    Compression is OK but either I got "out of memory" message during decompression (even on -4:2), either process crashes during decompression.
    Its possible to create a binary which is compresses\decompresses without any errors but decompressed file is differ to original.
    I tried a lot of different math and floating point related options, used different builds of mingw and its branches including exotic ones, and..... and still no luck.
    I almost close to give up but I will not do it cause there are some good news. I managed to build the EXE which is compresses\decompresses without errors and decompressed file is identical to original.
    But its only valid for -1:8
    The option is: -DWINDOWS -v -static -s -march=pentium4 -O3 -msse2 -mlong-double-128 -ffloat-store -Xlinker --large-address-aware
    http://en.wikipedia.org/wiki/Long_double

    To get compression/decompression work you need to replace long double with double in wavModel or it will not work. And compile like this(GCC):
    -DWINDOWS -DMT -ffloat-store -mfpmath=sse -mno-fancy-math-387 -msse2 -Ofast -s -march=pentium4

    To be sure that code is sse do assembly output and look at wavmodel code. If long double is used with above options then it still generates 387 math.

    In Visual C++ if SSE is enabled set floating point model to /fp:precise
    KZo


  6. #155
    Member
    Join Date
    May 2008
    Location
    Estonia
    Posts
    385
    Thanks
    142
    Thanked 213 Times in 115 Posts
    I think using TTA as a filter it is possible to compress without using floating point math. Compression is slightly worse (1-5%) but identical.
    I haven't implemented this into paq8pxd yet, only as external filter.

    Last version has problems in level 1-3. There is no compression.
    KZo


  7. #156
    Programmer Bulat Ziganshin's Avatar
    Join Date
    Mar 2007
    Location
    Uzbekistan
    Posts
    4,497
    Thanks
    733
    Thanked 660 Times in 354 Posts
    Monkey Audio has better compression and GPL sources. although it may need more work to extract just the code you need

  8. #157
    Member
    Join Date
    May 2008
    Location
    Estonia
    Posts
    385
    Thanks
    142
    Thanked 213 Times in 115 Posts
    paq8pxd_v15
    -cleaned up predictors
    -4bit image compression about 40% faster compresses about 5% better
    -large text block stream
    -do actual compression on levels 1,2,3
    -tta filter for audio (now compression lossless)
    -fast and slow mode on de/compression
    -other fixes

    Changed minimum text length to 64kb in detection. If whole file is detected as text and is less then 64kb then it is still added to text stream.

    There is no speacial model for audio only tta filter.
    tta filter first expands audio data and then its compressed. I used tta 2.0 but it failed on x64 but was better on x86. So i left in v3.4.1.
    Not the best solution.

    New command line when compressing:
    paq8pxd_v15 -s4:2 file (use slow mode level 4 threads 2).

    Fast mode is only active on levels 4 and above. Compression speed is same as on levels 1-3.
    So -s3 is same as -f3. But -f4 is faster then -s4 and uses less memory and some models are not used.
    Attached Files Attached Files
    Last edited by kaitz; 17th September 2014 at 19:21. Reason: typo
    KZo


  9. The Following 4 Users Say Thank You to kaitz For This Useful Post:

    Matt Mahoney (17th September 2014),Sportman (18th September 2014),Stephan Busch (17th September 2014),surfersat (17th September 2014)

  10. #158
    Programmer Bulat Ziganshin's Avatar
    Join Date
    Mar 2007
    Location
    Uzbekistan
    Posts
    4,497
    Thanks
    733
    Thanked 660 Times in 354 Posts
    tta 2.0 also had some bug with 32-bit audio data, i've fixed it in freearc

  11. #159
    Tester
    Stephan Busch's Avatar
    Join Date
    May 2008
    Location
    Bremen, Germany
    Posts
    873
    Thanks
    462
    Thanked 175 Times in 85 Posts
    Thank you very much for all your efforts, Kaido.

    Trying -s8 and -f8:2 switches I can't see the progress indicator and archive size doesn't get bigger during 20 minutes of compression -
    does this version use a temp file or is compression only working if the archive size increases (as it was the case with earlier versions)?

  12. #160
    Member
    Join Date
    May 2012
    Location
    United States
    Posts
    323
    Thanks
    178
    Thanked 52 Times in 37 Posts
    Quick test at -8 (and -s8 for v15)
    Each test is of one TAR file.

    CompressionRatings.com's Reference Files (http://compressionratings.com/files/...ence_files.zip)

    pxd_v4 (5,741,735
    pxd_v5 (5,740,640
    pxd_v7 (5,742,864
    pxd_v11 (6,037,838
    pxd_v12 (6,041,739
    pxd_v13 (6,042,435
    pxd_v15 (5,793,709
    px_v69 (5,741,144

    MaximumCompression.com's SFC Test

    pxd_v4 (8,706,099
    pxd_v5 (8,704,545
    pxd_v7 (8,707,567
    pxd_v11 (8,673,534
    pxd_v12 (8,682,858
    pxd_v13 (8,697,443
    pxd_v15 (8,676,419
    px_v69 (8,749,669


    Quote Originally Posted by Stephan Busch View Post
    Thank you very much for all your efforts, Kaido.

    Trying -s8 and -f8:2 switches I can't see the progress indicator and archive size doesn't get bigger during 20 minutes of compression -
    does this version use a temp file or is compression only working if the archive size increases (as it was the case with earlier versions)?
    I also do not have a progress indicator when compressing.

    I will assume it is running and post benchmark results here when compression completes.

    PS: As Stephen said, thank you for all your efforts.
    Last edited by comp1; 18th September 2014 at 04:52.

  13. #161
    Member
    Join Date
    Sep 2014
    Location
    Italy
    Posts
    26
    Thanks
    33
    Thanked 18 Times in 11 Posts
    Hi!

    This is my first post.
    I have compiled the source with mingw 64bit (i have used... g++ paq8pxd_v15.cpp -DWINDOWS -DNOASM -Ofast -msse2 -s -march=native -fpermissive -o paq8pxd_v15_x64.exe) and i noticed that the progress indicator now appears.

    ....

    C:\Bin\paq8pxd_v15>paq8pxd_v15_x64 -s8 c:\bin\paq8pxd_v15\test.bck
    Creating archive c:\bin\paq8pxd_v15\test.bck.paq8pxd15 with 1 file(s)...

    File list (20 bytes)
    Compressed from 20 to 22 bytes.

    1/1 Filename: c:/bin/paq8pxd_v15/test.bck (22112768 bytes)
    Block segmentation:
    0 | default | 20904572 b [0 - 20904571]
    1 | text | 101361 b [20904572 - 21005932]
    2 | default | 1106835 b [21005933 - 22112767]

    Segment data size: 27 bytes

    TN |Type name |Count |Total size
    -----------------------------------------
    0 |default | 2 | 22011407
    10 |text | 1 | 101361
    -----------------------------------------
    Total level 0 | 3 | 22112768

    Compressing default stream. Total 22011407
    50.30%
    Last edited by LucaBiondi; 18th September 2014 at 01:46.

  14. #162
    Member
    Join Date
    May 2008
    Location
    Estonia
    Posts
    385
    Thanks
    142
    Thanked 213 Times in 115 Posts
    Quote Originally Posted by Stephan Busch View Post
    Trying -s8 and -f8:2 switches I can't see the progress indicator and archive size doesn't get bigger during 20 minutes of compression -
    does this version use a temp file or is compression only working if the archive size increases (as it was the case with earlier versions)?
    In multithreading mode/compile it only shows progress on decompression. It can be shown on compression but current implementation has problem. If multiple streams are present and more then one thread is used then progress is overlapped. As for archive size, it has allways been like this.
    Edit: It will increase if all streams are compressed.

    I can enable this overlaping indicator if its not to confusing.
    Quote Originally Posted by LucaBiondi View Post
    I have compiled the source with mingw 64bit (i have used... g++ paq8pxd_v15.cpp -DWINDOWS -DNOASM -Ofast -msse2 -s -march=native -fpermissive -o paq8pxd_v15_x64.exe) and i noticed that the progress indicator now appears.
    -DNOASM has no effect and -DMT enables multithreading support witch disables progress indicator.


    If someone gets error: Detect wav sr. And program exits then let me know sample-rate if possible.
    Last edited by kaitz; 18th September 2014 at 09:14.
    KZo


  15. #163
    Member
    Join Date
    Aug 2008
    Location
    Planet Earth
    Posts
    778
    Thanks
    63
    Thanked 273 Times in 191 Posts
    enwik8 (v15 LucaBiondi parameters compile):

    17,896,933 bytes 363.23 sec. -f8
    16,571,676 bytes 3,023.19 sec. -s8

    enwik9:
    146,239,601 bytes 3,482.56 sec. -f8
    134,778,365 bytes 30,170.30 sec. -s8
    Last edited by Sportman; 19th September 2014 at 13:24. Reason: Added enwik9

  16. #164
    Member
    Join Date
    May 2012
    Location
    United States
    Posts
    323
    Thanks
    178
    Thanked 52 Times in 37 Posts
    @Kaido,

    Perhaps I missed this in the discussion on this thread but why do the later versions of paq8pxd compress wav audio so poorly? I see that you have implemented the tta filter in the latest v15 but the wav compression is still worse than older paq8pxd versions and worse than even paq8px_v69.

    Why the loss in compression with newer versions? Is the ultimate goal to achieve same or better compression ratio on wav files than the older paq8pxd versions?

    Here is a comparison of many paq8pxd versions compression a 44.1khz/2 ch/16-bit WAV file that uncompressed is: 2,646,044 bytes.

    Code:
     pxd_v7  1,367,838 
     pxd_v4  1,367,842 
     pxd_v5  1,367,842 
     px_v69  1,368,189 
    pxd_v15  1,425,761 
    pxd_v11  1,665,518 
    pxd_v12  1,665,977 
    pxd_v13  1,666,092

  17. #165
    Member
    Join Date
    Feb 2013
    Location
    ARGENTINA
    Posts
    81
    Thanks
    220
    Thanked 26 Times in 18 Posts
    What about FLAC?

  18. #166
    Member
    Join Date
    May 2008
    Location
    Estonia
    Posts
    385
    Thanks
    142
    Thanked 213 Times in 115 Posts
    Quote Originally Posted by comp1 View Post
    Why the loss in compression with newer versions? Is the ultimate goal to achieve same or better compression ratio on wav files than the older paq8pxd versions?
    I am sure that if tta was model instead of current filter then results were better.

    Code:
    Developers2.wav (16b stereo) (3691852 bytes)
                     Compressed  Time (sec)  Mem (MB)
    paq8pxd_v15 -s8  1679707     79.78       1629     (tta v3.4.1)
    paq8pxd_v15 -s8  1500627     83.19       1629     (tta v2.0)
    paq8pxd_v15 -f8  1678451     28.02        756     (tta v3.4.1)
    paq8pxd_v15 -f8  1501458     28.61        756     (tta v2.0)
    paq8pxd_v13 -8   2439261    238.34       1638     (wavmodel bug)
    paq8pxd_v7  -8   1498014    377.19       1558     (wavmodel)
    paq8px_v69  -8   1498097    405.32       1583     (wavmodel)
    
    
    pcm0844m.wav (8b mono) (294954 bytes)
                   Compressed  Time (sec)  Mem (MB)
    paq8pxd_v15 -s8 83054     10.39        1629     (tta v3.4.1)
    paq8pxd_v15 -s8 82685     10.84        1629     (tta v2.0)
    paq8pxd_v15 -f8 82873      3.98         756     (tta v3.4.1)
    paq8pxd_v15 -f8 82477      4.20         756     (tta v2.0)
    paq8pxd_v13 -8  71734     27.59        1638     (wavmodel bug)
    paq8pxd_v7  -8  71624     50.20        1558     (wavmodel)
    paq8px_v69  -8  71559     52.67        1583     (wavmodel)

    To replace current with tta v2.0 https://drive.google.com/file/d/0B0l...2xkdDJsdFZwUEE
    Fails on x64 compile.


    tta is only a filter. v2.0 splits channels. In v3.4.1 there is no split.


    And then there is this age-old problem http://encode.su/threads/613-FP8-(-F...ll=1#post29112


    Quote Originally Posted by surfersat View Post
    What about FLAC?
    It has some degree of floating point math.
    KZo


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

    surfersat (19th September 2014)

  20. #167
    Programmer Bulat Ziganshin's Avatar
    Join Date
    Mar 2007
    Location
    Uzbekistan
    Posts
    4,497
    Thanks
    733
    Thanked 660 Times in 354 Posts
    i've catched the bug in tta 2.0 - it lacks parens around "array + num" expression :

    int **malloc2d (int num, unsigned int len)
    {
    int i, **array, *tmp;


    array = (int **) BigAlloc (num * (sizeof(int *) + len * sizeof(int)));
    if (array == NULL) tta_error (MEMORY_ERROR, NULL);


    for(i = 0, tmp = (int *) array + num; i < num; i++)
    array[i] = tmp + i * len;


    return (array);
    }


    also, you need to replace long with int everywhere, although on windows it will work even with longs

  21. The Following User Says Thank You to Bulat Ziganshin For This Useful Post:

    kaitz (19th September 2014)

  22. #168
    Expert
    Matt Mahoney's Avatar
    Join Date
    May 2008
    Location
    Melbourne, Florida, USA
    Posts
    3,255
    Thanks
    306
    Thanked 778 Times in 485 Posts
    Tested Silesia with -s9. Still verifying decompression but so far OK. http://mattmahoney.net/dc/silesia.html
    To test, I compiled in 64 bit Ubuntu with g++ 4.8.2 -O3

  23. The Following User Says Thank You to Matt Mahoney For This Useful Post:

    kaitz (19th September 2014)

  24. #169
    Member
    Join Date
    May 2008
    Location
    Estonia
    Posts
    385
    Thanks
    142
    Thanked 213 Times in 115 Posts
    Quote Originally Posted by Bulat Ziganshin View Post
    i've catched the bug in tta 2.0 - it lacks parens around "array + num" expression
    It works. Thanks again.
    Quote Originally Posted by Bulat Ziganshin View Post
    also, you need to replace long with int everywhere, although on windows it will work even with longs
    I looked also this stackoverflow question. I was not sure so i added assert check to test if long is 4 bytes.
    KZo


  25. #170
    Programmer Bulat Ziganshin's Avatar
    Join Date
    Mar 2007
    Location
    Uzbekistan
    Posts
    4,497
    Thanks
    733
    Thanked 660 Times in 354 Posts
    kaitz, just replace every long with int. otherwise it will fail on linux x64

  26. #171
    Expert
    Matt Mahoney's Avatar
    Join Date
    May 2008
    Location
    Melbourne, Florida, USA
    Posts
    3,255
    Thanks
    306
    Thanked 778 Times in 485 Posts
    Silesia decompressed OK. Also tested enwik8 with -s9 and -f9, both OK. http://mattmahoney.net/dc/text.html#1302

  27. The Following User Says Thank You to Matt Mahoney For This Useful Post:

    kaitz (23rd September 2014)

  28. #172
    Member
    Join Date
    Sep 2014
    Location
    United States
    Posts
    5
    Thanks
    0
    Thanked 0 Times in 0 Posts
    This compression program has specialized compression algorithms for various formats, yes? Have you thought about making the framework extensible so that a developer could introduce algorithms for different kinds of file formats that they use more often? For example, it's good that jpegs are supported, but what about .png files. Being able to introduce classes for new formats would make this easier.

  29. #173
    Member
    Join Date
    Aug 2014
    Location
    Argentina
    Posts
    468
    Thanks
    203
    Thanked 81 Times in 61 Posts
    Quote Originally Posted by freelancer91 View Post
    This compression program has specialized compression algorithms for various formats, yes? Have you thought about making the framework extensible so that a developer could introduce algorithms for different kinds of file formats that they use more often? For example, it's good that jpegs are supported, but what about .png files. Being able to introduce classes for new formats would make this easier.

    From http://cs.fit.edu/~mmahoney/compression/


    "
    ZPAQ

    ZPAQ is a proposed standard format for highly compressed data that allows new compression algorithms to be developed without breaking compatibility with older programs.

    • zpaq.pdf - Specification.
    • unzpaq102.cpp - Reference decoder.
    • zpaq102.zip contains a ZPAQ compatible archiver (not part of the standard), the above two documents, and Windows executables.

    ZPAQ solves the compatibility problem by encoding a description of the decompression algorithm in the compressed data. ZPAQ is based on PAQ-like context mixing algorithms which are top ranked on many benchmarks. The format supports archivers, single file compressors, and memory to memory compression.
    The current standard is Level 1 (ZPAQ-1). It is anticipated that future levels (ZPAQ-2, ZPAQ-3, etc.) will be backward compatible, such that newer levels can read archives produced by older programs.
    "
    Further documentation at that page.

  30. #174
    Expert
    Matt Mahoney's Avatar
    Join Date
    May 2008
    Location
    Melbourne, Florida, USA
    Posts
    3,255
    Thanks
    306
    Thanked 778 Times in 485 Posts
    That page hasn't been maintained since 2009. It has a link to the current page at http://mattmahoney.net/dc/zpaq.html
    The current version of the specification is http://mattmahoney.net/dc/zpaq203.pdf
    The current version of the reference decoder is http://mattmahoney.net/dc/unzpaq200.cpp
    And a test case that should decode to the Calgary corpus: http://mattmahoney.net/dc/calgarytest2.zpaq

  31. #175
    Expert
    Matt Mahoney's Avatar
    Join Date
    May 2008
    Location
    Melbourne, Florida, USA
    Posts
    3,255
    Thanks
    306
    Thanked 778 Times in 485 Posts
    I tested (actually by accident) compressing 2 copies of enwik9 together:

    paq8pxd_v15 -s9 enwik9 -> 131,992,226, 54993 sec.
    paq8pxd_v15 -s9 enwik9 enwik9 -> 257,244,942, 112127 sec (2.67 GHz M620, 64 bit Ubuntu, compiled with g++ 4.8.2 -O3)

    It seems like there is an opportunity to identify long string matches during preprocessing.

  32. #176
    Member
    Join Date
    Aug 2014
    Location
    Argentina
    Posts
    468
    Thanks
    203
    Thanked 81 Times in 61 Posts
    Oh. Sorry. Intention is what counts .

  33. #177
    Member
    Join Date
    May 2012
    Location
    United States
    Posts
    323
    Thanks
    178
    Thanked 52 Times in 37 Posts
    Quote Originally Posted by kaitz View Post
    If someone gets error: Detect wav sr. And program exits then let me know sample-rate if possible.
    On vm.dll, I get an error and exit right after default segment 3154. It says the following:

    Code:
    Detect wav sr 15625

  34. #178
    Member
    Join Date
    May 2008
    Location
    Estonia
    Posts
    385
    Thanks
    142
    Thanked 213 Times in 115 Posts
    I am working newer version. tta v2.0 filter works fine on x86/x64 Windows/Linux.
    Added 32b IEEE wav detection. Added tta fix pointed out by Bulat. But compression is worse with current implementation (2x larger then input). Still no luck. Probably input is expanded to much and because of minimal modeling.

    Quote Originally Posted by Matt Mahoney View Post
    paq8pxd_v15 -s9 enwik9 enwik9 -> 257,244,942, 112127 sec (2.67 GHz M620, 64 bit Ubuntu, compiled with g++ 4.8.2 -O3)

    It seems like there is an opportunity to identify long string matches during preprocessing.
    When i was working on v11 or v12 i thought about this problem. That was it.


    Quote Originally Posted by comp1 View Post
    On vm.dll, I get an error and exit right after default segment 3154. It says the following:
    Code:
    Detect wav sr 15625
    Thanks for pointing out. In newer version wav detection is more strict.

    Quote Originally Posted by Sportman View Post
    enwik9:
    134,778,365 bytes 30,170.30 sec. -s8
    In LTCB enwik9 is compressed to 134,452,453 b (-8 v12), so changes in predictor for text made it worse, but not on enwik8.
    I made changes and on smaller files results are good, enwik8 is same. Haven't tested on enwik9.

    I may add EOL coding used in Calgary challange and pasqda for text that benefits from it.
    KZo


  35. #179
    Member Skymmer's Avatar
    Join Date
    Mar 2009
    Location
    Russia
    Posts
    681
    Thanks
    37
    Thanked 168 Times in 84 Posts
    I have a good news. Shortly speaking I found a way to make the OptimFrog based WAV model to work correctly.
    It means that it provides identical output for x86 and x64 binaries and identical to MSVC /fp:precise output.
    The solution was too close that it actually looks like natural mockery but lets go from beggining.
    Previously it was suggested to change long double to double and to use: -march=pentium4 -Ofast -msse2 -ffloat-store -mfpmath=sse -mno-fancy-math-387
    It helped to make output from x86 and x64 to be identical but didnt solved the compatibility with MSVC. After some days I just set the -O3 instead of -Ofast and it started to work as expected.
    The difference between o3 and ofast is simple:
    Code:
    -funsafe-math-optimizations		en
    -ffinite-math-only			en
    -fmath-errno				dis
    -fsigned-zeros				dis
    -ftrapping-math				dis
    -fcx-limited-range			en
    All these six options together are equal to alias: -ffast-math. So seems everything OK, isn't it?
    No, its dont. Suboptimal performance - thats what I started to noticing. You'll see it in tests below.
    So I started to search for another approach. So here is how the final solution looks:
    Code:
    -march=pentium4 -O3 -msse2 -mfpmath=sse -frounding-math
    And here are couple of tests which show the difference in performance.
    Code:
                       x86		    x64
    -------------------------------------------
    msvc		 73.296s
    rounding	 83.687s	 69.984s
    store		133.562s	119.203s
    
    msvc		52.250s
    rounding	52.359s		 46.578s
    store		72.828s		 75.187s
    I attached a binaries so tests of WAV compression are welcome.
    Attached Files Attached Files
    • File Type: 7z bin.7z (561.4 KB, 105 views)

  36. The Following 2 Users Say Thank You to Skymmer For This Useful Post:

    comp1 (28th September 2014),Stephan Busch (28th September 2014)

  37. #180
    Member
    Join Date
    May 2012
    Location
    United States
    Posts
    323
    Thanks
    178
    Thanked 52 Times in 37 Posts
    Quote Originally Posted by Skymmer View Post
    I have a good news. Shortly speaking I found a way to make the OptimFrog based WAV model to work correctly.
    It means that it provides identical output for x86 and x64 binaries and identical to MSVC /fprecise output.
    The solution was too close that it actually looks like natural mockery but lets go from beggining.
    Previously it was suggested to change long double to double and to use: -march=pentium4 -Ofast -msse2 -ffloat-store -mfpmath=sse -mno-fancy-math-387
    It helped to make output from x86 and x64 to be identical but didnt solved the compatibility with MSVC. After some days I just set the -O3 instead of -Ofast and it started to work as expected.
    The difference between o3 and ofast is simple:
    Code:
    -funsafe-math-optimizations        en
    -ffinite-math-only            en
    -fmath-errno                dis
    -fsigned-zeros                dis
    -ftrapping-math                dis
    -fcx-limited-range            en
    All these six options together are equal to alias: -ffast-math. So seems everything OK, isn't it?
    No, its dont. Suboptimal performance - thats what I started to noticing. You'll see it in tests below.
    So I started to search for another approach. So here is how the final solution looks:
    Code:
    -march=pentium4 -O3 -msse2 -mfpmath=sse -frounding-math
    And here are couple of tests which show the difference in performance.
    Code:
                       x86            x64
    -------------------------------------------
    msvc         73.296s
    rounding     83.687s     69.984s
    store        133.562s    119.203s
    
    msvc        52.250s
    rounding    52.359s         46.578s
    store        72.828s         75.187s
    I attached a binaries so tests of WAV compression are welcome.
    Tried your version with -0 option on vm.dll. Result was a 528,099,698 byte file.

    When trying to decompress, result is as follows:

    Code:
    C:\>paq8pxd64 -d vm.dll.paq8pxd14
    DeCompressing default stream.
    DeCompressing jpeg stream.
    DeCompressing image1 stream.
    DeCompressing image4 stream.
    DeCompressing image8 stream.
    DeCompressing image24 stream.
    DeCompressing audio stream.
    DeCompressing exe stream.
    DeCompressing text0 wrt stream.
    DeCompressing text wrt stream.
    Not enough memory!
    Good news is that it did not fail on audio stream like before.

Page 6 of 22 FirstFirst ... 4567816 ... LastLast

Similar Threads

  1. FreeArc compression suite (4x4, Tornado, REP, Delta, Dict...)
    By Bulat Ziganshin in forum Data Compression
    Replies: 554
    Last Post: 26th September 2018, 02:41
  2. Dict preprocessor
    By pat357 in forum Data Compression
    Replies: 5
    Last Post: 2nd May 2014, 21:51

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
  •