27.07.2013 14:44
[#61]
Re: XPK problem
@APC74, post #59
Tfu, jednak nie może być nieparzysty. W swoich libsach zmienię to. xpkKatana jest sprytny i zawsze podmienia rozmiar na parzysty, ale xpkKnight czy xbench nie. Jeśli używasz CPU>000 to w ogóle jest to nieważne. Zwiecha wystąpi bardzo rzadko bo muszą być spełnione warunki: CPU000, nieparzysty chunksize, plik zawierający niespakowane chunki raw, tylko podczas rozpakowywania.
27.07.2013 15:13
[#62]
Re: XPK problem
@APC74, post #53
Nie pijąc do nikogo, trzeba jeszcze zwrócić uwagę na jedną rzecz, zwłaszcza testując na jednym pliku lub kilku plikach tego samego typu. Różne pakery zwracają tzw. expansion po przekroczeniu rozmiaru wejściowego. Może być to na 100% lub na %120. Dzieje się to w plikach, które nie chcą się już spakować, ale może to być lokalnie, gdzie plik podzielony na 10 chunków posiada 8 typu raw. Może to zafałszować wyniki, gdzie rozpakowanie dotyczy 20% pliku, a reszta copy. Podobnie przy wydajności, jeden paker przy 100% wyrzuci expansion, a drugi dopiero przy 120% i okaże się, że ten pierwszy jest wydajniejszy, co jest absolutną nieprawdą.
27.07.2013 16:19
[#63]
Re: XPK problem
@cholok, post #62
Nie pijąc do nikogo 
Jaaasne :P
Co najlepiej było widać na tym teście, gdzie pakowany jest plik tekstowy o rozmiarze 0,5MB, wypełniony losowymi danymi z generatora haseł.
Tak przy okazji - poprawiłem te testy i teraz są bez JIT itd. chociaż i tak wyniki nijak się mają do oryginalnej A3000 (są znacznie szybsze oczywiście), to chyba bardziej odpowiadają rzeczywistości. No i biję się w piersi i biję pokłony, bo miałeś rację a ja się myliłem - GZIP vs. PWPK w teście ogólnym (nasz "spór" w postach #51, #53 i dalej).
Jaaasne :PCo najlepiej było widać na tym teście, gdzie pakowany jest plik tekstowy o rozmiarze 0,5MB, wypełniony losowymi danymi z generatora haseł.
Tak przy okazji - poprawiłem te testy i teraz są bez JIT itd. chociaż i tak wyniki nijak się mają do oryginalnej A3000 (są znacznie szybsze oczywiście), to chyba bardziej odpowiadają rzeczywistości. No i biję się w piersi i biję pokłony, bo miałeś rację a ja się myliłem - GZIP vs. PWPK w teście ogólnym (nasz "spór" w postach #51, #53 i dalej).
27.07.2013 17:06
[#64]
Re: XPK problem
@APC74, post #63
W testach zabrakło kilku bibliotek, może nieistotnych, ale dla testu z losowymi danymi dość istotnych. Taki plik ogłupia metody słownikowe, ale zawiera ograniczony zbiór znaków co stawia go doskonałym kandydatem dla metod statystycznych: HFMN, HUFF. Jest co prawda SMPL, ale delta tutaj zmniejsza entropię.
27.07.2013 18:44
[#65]
Re: XPK problem
@cholok, post #64
Tak mi się wydawało, że czegoś brakuje. :) Teraz są wszystkie, jakie mam - nie licząc CRM2/CRMS czy ELZX/SLZX, które działają pod Diavolo ale już pod XPKataną nie bardzo itd.
27.07.2013 21:02
[#66]
Re: XPK problem
@APC74, post #65
Jedna ciekawostka odnośnie xpkPPMQ.library, którą zauważyłem. Biblioteka pakuje pliki o rozmiarach do 0,5MB. Jeżeli plik ma większy rozmiar to kończy się to guru:
- dla domyślnego chunka (50000) i pliku powyżej 600KB :
O CODE przestało działać...
No to link
lub (niestety tylko screenshot - system całkiem się zawiesza przy plikach powyżej 1MB):
Dla chunka 100000 mam od razu czerwone guru (na szczęście MCP je przechwyciło):
Error : 80000004 (DEADEND)
Cause : Illegal instruction
I na koniec cała historia "walki" z PPMQ:
Ostatnia aktualizacja: 27.07.2013 21:08:54 przez APC74
- dla domyślnego chunka (50000) i pliku powyżej 600KB :
O CODE przestało działać...
No to link
lub (niestety tylko screenshot - system całkiem się zawiesza przy plikach powyżej 1MB):
Dla chunka 100000 mam od razu czerwone guru (na szczęście MCP je przechwyciło):
Error : 80000004 (DEADEND)
Cause : Illegal instruction
I na koniec cała historia "walki" z PPMQ:
Ostatnia aktualizacja: 27.07.2013 21:08:54 przez APC74
27.07.2013 21:35
[#67]
Re: XPK problem
@APC74, post #66
Użyj może wersji cosmosa, chociaż ona też jest niedobra, ale przynajmniej nie guruje. Odnośnie zrąbanych libsów to jest ich całkiem sporo (patrz post 1). Z nowo odnalezionych to jeszcze ZENO. Ja do testowania używam xpkKnight, ponieważ po spakowaniu odpakowuje plik i porównuje ze źródłowym i dopiera nagrywa. Dzięki temu odkryłem sporo złych libsów. Jeszcze jest DMCB, ale trzeba używać wersji cosmosa, bo ta z aminetu źle wykrywa FPU. Na emulatorze źle pakuje na 881, dobrze na 882, ale to daleka przyszłość.
28.07.2013 18:59
[#68]
Re: XPK problem
@cholok, post #67
Update:
CBR0, RLEN: przyśpieszone pakowanie (procedura oparta na FRLE).
FRLE: poprawione błędy w pakerze, nie były to błędy krytyczne, ale niesmak pozostał. Depaker pozostał z oryginalnej wersji, bo u cosmosa został całkiem zmieniony.
FBR2: dodany tryb AutoSize, który w oryginale istniał tylko jako napis, ale paker wybór tego trybu całkowicie ignorował.
Poza tym sporo fixów itd.
CBR0, RLEN: przyśpieszone pakowanie (procedura oparta na FRLE).
FRLE: poprawione błędy w pakerze, nie były to błędy krytyczne, ale niesmak pozostał. Depaker pozostał z oryginalnej wersji, bo u cosmosa został całkiem zmieniony.
FBR2: dodany tryb AutoSize, który w oryginale istniał tylko jako napis, ale paker wybór tego trybu całkowicie ignorował.
Poza tym sporo fixów itd.
28.07.2013 22:59
[#71]
Re: XPK problem
@APC74, post #69
Libsy od cosmosa:
cosmos blog
z tym, że te zrąbane są zoptymalizowane, ale dalej zrąbane:
FBR2, ZENO, ILZR. Dziwne, że PPMQ nie ma.
cosmos blog
z tym, że te zrąbane są zoptymalizowane, ale dalej zrąbane:
FBR2, ZENO, ILZR. Dziwne, że PPMQ nie ma.
30.07.2013 12:53
[#72]
Re: XPK problem
@cholok, post #71
LZW2 - koszmarek, bo autor nie powinien tej wersji wypuszczać. No, ale nadałem jej sens istnienia. Teraz będzie pakować podobnie jak oryginał (ale nieco lepiej), ale z mniejszym zużyciem pamięci i zdecydowanie szybciej. Ruszy na na CPU000. Czyli pakuje teraz nieco gorzej niż moja poprzednia wersja, ale tak ma być, ponieważ ta lepsza LZW3 musi być po prostu lepsza. Należy traktować LZW2 i LZW3 jako jeden paker z dwoma trybami pakowania: szybki i lepszy.
LZW2/3/4 - mają zmieniony depaker, teraz depakuje bajt po bajcie, jest to nieco wolniejsze (niewiele), ale pozwala na większą kompresję (LZW5 już to miało).
LZW4/5 i TDCS - mają dodatkowe tryby uwzględniające szukanie zachłanne. Oryginalne wersje miały to, ale teraz można to wyłączyć co przyśpieszy pakowanie kosztem kompresji.
LZW2/3/4 - mają zmieniony depaker, teraz depakuje bajt po bajcie, jest to nieco wolniejsze (niewiele), ale pozwala na większą kompresję (LZW5 już to miało).
LZW4/5 i TDCS - mają dodatkowe tryby uwzględniające szukanie zachłanne. Oryginalne wersje miały to, ale teraz można to wyłączyć co przyśpieszy pakowanie kosztem kompresji.
04.08.2013 14:34
[#75]
Re: XPK problem
@APC74, post #63
Ktore biblioteki xpk maja porownywalna albo lepsza kompresje niz SHRI dla danych?
I nie chodzi mi tutaj o ten test, bo z moich wlasnych testow wynika, ze GZIP jest gorszy niz SHRI, wiec to trzeba porownywac normalne dane (grafika, muza, sample, exeki) , a nie dane generowane, bo to prawie to samo jakby spakowac drugi raz juz spakowane dane za pomoca xpk albo spakowac MP3. Owszem to sie da zrobic w niektorych przypadkach, tyle ze to nie ma sensu.
I nie chodzi mi tutaj o ten test, bo z moich wlasnych testow wynika, ze GZIP jest gorszy niz SHRI, wiec to trzeba porownywac normalne dane (grafika, muza, sample, exeki) , a nie dane generowane, bo to prawie to samo jakby spakowac drugi raz juz spakowane dane za pomoca xpk albo spakowac MP3. Owszem to sie da zrobic w niektorych przypadkach, tyle ze to nie ma sensu.
04.08.2013 15:20
[#76]
Re: XPK problem
@Don_Adan, post #75
Przecież jest test parę postów wcześniej dla normalnych danych. Wszędzie przoduje SHRI, ale jest z nim problem. Jest wolny, także w czasie dekompresji (koder arytmetyczny), więc czasami nie warto. Druga sprawa to jego niepewność. Zmiana chunka z domyślnego powoduje problemy.
Wracając do konkretów. Na tapecie HUFF. Parę rzeczy poprawiono. Jest tam kodowanie na hasło (szyfrowaniem bym tego nie nazwał). Był tam dziwny błąd. HUFF najpierw koduje dane, a potem ewentualnie "szyfruje". Problem występował, gdy danie nie dają się spakować, wtedy występuje błąd expansion i dane są po prostu kopiowane bez zmian, ale przy rozpakowywaniu żądane jest hasło. Wtedy wystarczyło podać obojętnie jakie. Teraz już tego nie ma.
Wracając do konkretów. Na tapecie HUFF. Parę rzeczy poprawiono. Jest tam kodowanie na hasło (szyfrowaniem bym tego nie nazwał). Był tam dziwny błąd. HUFF najpierw koduje dane, a potem ewentualnie "szyfruje". Problem występował, gdy danie nie dają się spakować, wtedy występuje błąd expansion i dane są po prostu kopiowane bez zmian, ale przy rozpakowywaniu żądane jest hasło. Wtedy wystarczyło podać obojętnie jakie. Teraz już tego nie ma.
04.08.2013 15:55
[#78]
Re: XPK problem
@cholok, post #76
Nie zauwazylem. Sorry. Ale z tego co widze to sa jeszcze ze trzy inne: SHSC, SASC i BZP2. ktore sa porownywalne w kompresji. Masz gdzies zdeasemblowany depaker od xpkSHRI, chetnie bym go obejrzal i moze troche zoptymalizowal. Mozesz go gdzies wrzucic albo podeslac na donadan@wp.pl.
04.08.2013 16:50
[#79]
Re: XPK problem
@Don_Adan, post #78
SHSC i SASC są oparte na HA, strasznie wolne, ale kod w C jest.
Podesłałem źródła shrinka, CDAF-moduł do xadmastera, dwa moje bardzo dawno zrobione depakery, aczkolwiek wzorowane na P-Compress 2 (HILH). xpkSHRI.s służył do testowania prostych plików xpk, a więc prawdopodobnie 1-chunkowych. Zdaje się, że ten paker użyty jest też w modcrusherze.
Tu jest też nowsza wersja cosmosa 2.5.
Podesłałem źródła shrinka, CDAF-moduł do xadmastera, dwa moje bardzo dawno zrobione depakery, aczkolwiek wzorowane na P-Compress 2 (HILH). xpkSHRI.s służył do testowania prostych plików xpk, a więc prawdopodobnie 1-chunkowych. Zdaje się, że ten paker użyty jest też w modcrusherze.
Tu jest też nowsza wersja cosmosa 2.5.
30.09.2013 13:17
[#86]
Re: XPK problem
@cholok, post #85
Poprzednie libsy miały całkiem nieszkodliwy błąd związany z funkcją Expunge.
Z Donem zoptymalizowaliśmy SHRI i na 68000 jest szybszy o około 20%.
Dodatkowo powstała wersja SHR3, bo uzyskaliśmy przyśpieszenie o 30%
kosztem niekompatybilności wstecznej. Póki co jeszcze nie udostępniam,
bo powstaje wersja na 020.
Z Donem zoptymalizowaliśmy SHRI i na 68000 jest szybszy o około 20%.
Dodatkowo powstała wersja SHR3, bo uzyskaliśmy przyśpieszenie o 30%
kosztem niekompatybilności wstecznej. Póki co jeszcze nie udostępniam,
bo powstaje wersja na 020.
20.10.2013 17:31
[#88]
Re: XPK problem
@cholok, post #87
BLZW - dość poprawna i zoptymalizowana biblioteka, więc tylko nieco zretuszowałem.
ZENO - też oparta na LZW, ale dużo wolniejsza od BLZW i mniej wydajna (14 vs 15 bit)
Miała błąd prowadzący do utraty danych ujawniający się w specyficznym przypadku.
Ostatnia aktualizacja: 20.10.2013 17:32:42 przez cholok
ZENO - też oparta na LZW, ale dużo wolniejsza od BLZW i mniej wydajna (14 vs 15 bit)
Miała błąd prowadzący do utraty danych ujawniający się w specyficznym przypadku.
Ostatnia aktualizacja: 20.10.2013 17:32:42 przez cholok
26.10.2013 16:39
[#89]
Re: XPK problem
@cholok, post #88
Zripowałem xpkLIN1 i xpkLIN3 z packera Lino.
Oba to te same pakery (depakery są identyczne), różnią się kompresją.
LIN1 pakuje podobnie do FAST, jest wolniejszy w depakowaniu, ale szybszy w pakowaniu.
LIN3 pakuje podobnie do PowerPackera, ale znacznie szybciej.
Wszystkie pakery LIN1-4 i ZENO są tego samego autora i obsługują hasło. Jednak hasło jest sprawdzane na zasadzie sumy kontrolnej, a dane nie są szyfrowane.
Lino jest programem shareware, więc kto chce używać tych bibliotek jest zobowiązany do opłaty autorowi.
Przy okazji testów okazało się, że xpkPWPK pakuje strasznie wolno (ala shrink), a przecież korzysta z zewnętrznej biblioteki. Prawdopodobnie xpkPWPK ustawia speedup buffer na średni, a nie na max.
Oba to te same pakery (depakery są identyczne), różnią się kompresją.
LIN1 pakuje podobnie do FAST, jest wolniejszy w depakowaniu, ale szybszy w pakowaniu.
LIN3 pakuje podobnie do PowerPackera, ale znacznie szybciej.
Wszystkie pakery LIN1-4 i ZENO są tego samego autora i obsługują hasło. Jednak hasło jest sprawdzane na zasadzie sumy kontrolnej, a dane nie są szyfrowane.
Lino jest programem shareware, więc kto chce używać tych bibliotek jest zobowiązany do opłaty autorowi.
Przy okazji testów okazało się, że xpkPWPK pakuje strasznie wolno (ala shrink), a przecież korzysta z zewnętrznej biblioteki. Prawdopodobnie xpkPWPK ustawia speedup buffer na średni, a nie na max.