Jan, Kaitz (I suppose you're also Kaido), first of all I want to thank you for PAQs you have made. Good job!
Now, here are some tests I've conducted on speed optimized\sse p, p1, p3, px versions. Unfortunately I wasn't able to find speed optimized version of p1 so don't look too much into its time results. Tests have been performed on various types of files with both speed and resulting size measured. -6 level have been used. The value in brackets after a filename is the original size. Columns are PAQ version, time, size. After each test I gaved a little comment. Let's go...
EXE test
Code:
FreePascal.exe (5 392 896)
--------------------------
paq8p_sse2 640.188 1 228 793
paq8px_speed 742.881 1 226 706
paq8p1 483.468 1 248 517
paq8p3_speed 456.052 1 245 152
All clear here. px better and slower than p\p1\p3. p3 surprisingly not only faster but also better that p1. But I know one drawback of p3 for PE files and will show it in another thread.
BSP test
Code:
d1_trainstation_03.bsp (5 909 064)
----------------------------------
paq8p_sse2 602.452 1 277 647
paq8px_speed 706.456 1 272 868
paq8p1 505.017 1 283 404
paq8p3_speed 419.189 1 283 911
The test file is from the HL2 game. Same situation here except the fact that p3 now little bit larger.
TXT test
Code:
l200903.txt (3 964 732)
-----------------------
paq8p_sse2 423.205 83 146
paq8px_speed 503.735 82 363
paq8p1 349.203 89 304
paq8p3_speed 296.982 89 494
No comments.
JPEG test
Code:
DSC02315.JPG (4 828 816)
------------------------
paq8p_sse2 140.151 3 657 757
paq8px_speed 137.702 3 651 709
paq8p1 155.294 3 658 651
paq8p3_speed 134.589 3 651 767
Hmmm... In this test px not only faster than p but also best on size. p3 shows the best time.
WAV test
Code:
Squarepusher - My Red Hot Car.wav (4 769 440) (27 sec. loop)
------------------------------------------------------------
paq8p_sse2 ******* *********
paq8p 121.126 2 721 473
paq8px_speed 185.152 2 709 594
paq8p1 165.332 2 721 467
paq8p3_speed 133.727 2 721 466
This test brings up some unpleasant and strange things. First of all sse2 of p just crashes on .wav files so I've done a test with plain compile.
px is best on size. p3 is fastest and 1 byte
smaller than p1.
BMP test
Code:
Back.bmp (3 120 656)
--------------------
paq8p_sse2 53.646 315 486
paq8px_speed 48.408 275 871
paq8p1 50.376 320 204
paq8p3_speed 51.266 313 206
Nice! px not only the best on size but also the fastest ! Just look at the size gap.
The good thing I love in tests is the possibility to find out some interesting issues. The BMP test made it for me. I'm not talking about good results of px, just listen...
I'm always thought that BMP format have fixed-lenght header but seems I was wrong. Looks like "ever live - ever learn" situation. When I was searching for test file I found 4 different file sizes for files with same 24 bit depth and same 1024x768 resolution. It was 2 359 296, 2 359 350, 2 359 352 and 2 359 362 bytes. The only clue I have is that only one file (2 359 352) showed up 72x72 DPI value while others showed unknown value in XnView.
The worst thing about it, is that not all of the files have been correctly detected and accepted. I suppose PAQ8 BMP detection is little bit unoptimal. So let's test. Yes\No means if file detected as BMP or not.
Code:
| paq8p_sse2 | paq8px_speed | paq8p1 | paq8p3_speed |
----------------------------------------------------------------
2 359 350 | yes | yes | yes | yes |
----------------------------------------------------------------
2 359 352 | yes | yes | yes | yes |
----------------------------------------------------------------
2 359 362 | no | yes | no | no |
----------------------------------------------------------------
EDIT 26 Apr 2009 21:20 :
- Updated JPEG results for px
- Modified BMP parsing table. Removed 2 359 296 file since its just corrupted one.
OBSOLETE:
Furthermore, for p and px 2 359 296 file gaved the following message:
Code:
Transform fails at 2359296, input=11 decoded=11, skipping...
Well. that is all