[#91] Re: XPK problem

@cholok, post #90

PWPK, czyli suport dla powerpackera miał 1 problem:
1. po wybraniu mode=fast widzimy guru

Drugi problem to w rzeczywistości problem samej powerpacker.library, a w zasadzie tej niby poprawionej (020+) przez kogoś innego. Procedura szyfrująca ma błąd i czasami niepoprawnie
deszyfruje, więc lepiej używać oryginalnej wersji. Poza tym nie sprawdza wersji cpu (guru na 68k).

Więc teraz PWKP ma wewnętrzne procedury, nie wymaga biblioteki powerpacker. Zawsze używa speedup=large. Generalnie nie ma co poprawiać samej powerpacker.library, gdyż wydajność pp
w tej klasie pakerów jest najsłabsza (porównując choćby do Implodera, Crunchmanii (normal) czy Stonecrackera).
[#92] Re: XPK problem

@cholok, post #91

IMPL, czyli turbo imploder, a w zasadzie fimp. Mimo nazwy turbo, paker z szybkością nie ma nic wspólnego. Jest strasznie wolny, pamięciożerny. Biblioteka jest jakby nieskończona, zawiera procedury nie potrzebne, a używane w fimpie. Usunąłem je, tak jak tryb wyszukiwania sekwencyjnego. Trybów było 5, a fump posiada ich 12. Poprawiłem to. Zwiększyłem też domyślny rozmiar bloku na większy, gdyż IMPL ogranicza maksymalny tryb kompresji w zależności od bloku.

Teraz IMPL wydawać może się wolniejszy, ale tak nie jest, ponieważ teraz pakuje sporo lepiej, wykorzystuje mocniejszy tryb, który wcześniej nigdy nie był dostępny. Niemniej i tak przyśpieszyłem wyszukiwanie dwukrotnie. Druga wada to pamięciożerność w wyższych trybach kompresji (max 1.3 MB). Fimp jest sprytny i w razie braku pamięci wyłącza tryb turbo i pakuje bardzo długo. Generalnie można zmienić całkowicie system hashowania, ale nie warto. Jest NUKE. Poza tym Imploder depakuje od tyłu co zaburza nieco system xpk (marginesy są z tyłu, a nie z przodu).
[#93] Re: XPK problem

@cholok, post #92

NUKE.
Prawie doskonały, ale i tak przyśpieszyłem nieco pakera, bo używał np. memset w części napisanej w C.

DUKE.
Jak wyżej, ale depaker niepotrzebnie używał dodatkowej pamięci, więc usunąłem tę usterkę.

RAKE.
Również wysoce zoptymalizowany, więc roboty nie było w ogóle. Ciekawostką jest, że istnieje paker xpkFRHT, który używa tego samego algorytmu, chociaż w wersji 1.0, a autor jest inny.
[#94] Re: XPK problem

@cholok, post #93

Przydałby się link do archiwum z najnowszymi wersjami, bo się pogubiłem - na własne życzenie mam taki bajzel, że nie ogarniam już, który backup zawiera które sublibsy...
[#95] Re: XPK problem

@APC74, post #94

Wchodzisz na stronę PekDara i już masz. Lub też wchodzisz na stronę Wanted Team i klikasz test.
Archiwum zawiera wszystkie sublibsy aż do LINx. Nie ma jeszcze PWPK, IMPL. NUKE, DUKE i RAKE. Następna aktualizacja jest planowana po obadaniu MASH (ten posiada błędy) i SQSH (nie sprawdza CPU). Potem planuję przerwę (chociaż jeszcze obadam LHLB i CRM2/S), bo chcę się zająć deliplayerem do IFF-SMUS (aktualny mnie nie satysfakcjonuje), ale nie wiem czy mi się to uda.
[#96] Re: XPK problem

@cholok, post #95

MASH
Paker przy zwiększeniu bloku posiadał błąd objawiający się "martwą" pętlą lub nieprawidłowym spakowaniem. Posiada on wewnętrznie 2 pakery, jeden dla bloków 64 KB, a drugi dla większych. Ten drugi może pakować także małe bloki i robi to, jeśli ten pierwszy paker nie zaalokuje pamięci. Ten drugi paker jest właśnie błędny, zaś bloki do 64 KB pakuje gorzej niż ten pierwszy paker. Z racji lenistwa zablokowałem możliwość użycia bloków >64 KB, a ten drugi paker usunąłem.
MASH posiadał także ukryte tryby (10), ale, że korzystał z nich tylko ten drugi paker (redukował ilość pamięci, ale też kompresję) też je usunąłem.
[#97] Re: XPK problem

@cholok, post #96

SQSH
Wersja 020 wieszała się na niższych prockach. Teraz się nie wiesza i korzysta w xpkPackFree, a więc allocmem i freemem raz na plik, a nie jak wcześniej, raz na blok.

Aktualizacja archiwum.
[#98] Re: XPK problem

@cholok, post #97

ARTM
Znalazłem taką bibliotekę nieznanego autora. Jest to książkowy przykład kompresji arytmetycznej. Bardziej przykład niż paker, ale co tam, niech jest.

DMCB
Jest to packer na FPU żywo oparty na kompresji dmc i źródłach dmc.c. Z racji tego, że paker tego typu pakuje dobrze od 16 MB pamięci, a autor ustawił max 2 MB to kompresja nie jest dobra, a jest tylko wolna. Ale tak poprawiłem wiele błędów.

DMCU
Jest to ulepszony paker autora DMCB. Używa maksymalnie 16 MB pamięci i zmodyfikowanej formy dmc. Pakuje całkiem dobrze, ale jest to wersja tylko dla PowerUP, która nie działała pod emulatorem w odróżnieniu od BZIP tego samego autora. Z racji dostępności źródeł przekompilowałem bibliotekę pod 68k, no i działa. Użyłem FPU z racji, że nawet pod emulatorem jest szybciej. Niemniej użyteczność tej biblioteki jest zerowa. Kompresja jest symetryczna względem czasowym i zużycia pamięci. Ale na niej nauczyłem się kompilować biblioteki w C co dało doświadczenie na rozprawienie się z GZIP.

GZIP
Dla sportu przekompilowałem ze źródeł zlib 1.2.8. Po porównaniu z xpkGZIP 1.2 było zbyt wolno, nawet 2 razy. Więc konwersja na assembler i już było dobrze, a i rozmiar się skurczył 3-krotnie. Z pewnych względów użyłem formatu raw deflate, zaś poprzednia wersja używa formatu zlib. Moja biblioteka rozpoznaje i dekoduje format zlib dla zachowania kompatybilności, zaś zapisuje tylko w formacie raw deflate dynamic trees.

LZCB, PPMQ
Oba pakery autorstwa C. Blooma. Oba błędne. PPMQ z racji powolności i tak nieużywalny. LZCB jeszcze by był używalny, ale niewarty naprawy z racji braku źródeł, trudno zlokalizować, których użyto (są na stronie Blooma). Odradzam ich używanie.

Przy pracy na GZIP odkryłem błąd xpkmaster oraz jej niedoskonałość. Błędem jest brak zapisu do spakowanego pliku wersji kompresora, więc depaker zawsze dostaje 0 jak parametr xsp_SubVersion. Powoduje to pewien problem przy produkcji nowszych wersji bibliotek o zmienionym formacie jak moja GZIP (obeszłem ten problem inaczej).

Co do niedoskonałości jest problem z xpkPackReset. Jest to funkcja, która została niezaimplementowana w xpkmaster (jak wiele innych rzeczy). Okazuje się, że xpkmaster nigdy nie wywoła tej funkcji.
[#99] Re: XPK problem

@cholok, post #98

BLZW
Dokładniejsze testy wykazały błędy w tej bibliotece. Były one oczywiście w oryginale (wersje 3.0 i 3.2). Objawiały się przy wyborze trybów <15, aczkolwiek algorytm jest ten sam, więc "nie ufam" temu pakerowi. Póki co zablokowałem możliwość używania wątpliwych trybów.

LHLB
Ten paker korzysta z lh.library. Tu nie ma problemów. Biblioteka lh.library bazuje na algorytmie użytym w Lha -lh1, ale jest niekompatybilna.

CRM2/CRMS
Tu jest problem. Crunchmania (LZH) jest po prostu zbugowana. Bugi wyskakują głównie przy użyciu sample mode. Jako, że algorytm jest ten sam, tylko dane wejściowe zmieniają, więc wnioskuję, że paker LZH jest błędny. Najprościej sprawdzić na exeku AmigaVisionPro i CRMS.
[#100] Re: XPK problem

@cholok, post #99

Zacząłem sprawdzać jakie szanse ma LZMA na klasyku. No i takie sobie.
Dekoder w C dekoduje plik:
pksize: 247036
upsize: 594712
time: 0:34.99 s
Wymaga 16 KB pamięci. Po optymalizacji do asma może byłoby to o połowę szybciej. Np. SHR3 rozpakowuje w 10 s, zaś BZP2 20 s, GZIP 2 s.

Paker ma 2 algorytmy: szybki i normalny. Co ważne, jest efektywny nawet dla 12-bitowego słownika. Dodatkowo obsługuje 2 rodzaje szybkiego wyszukiwania fraz w słowniku (hash chains i binary trie). Zużycie pamięci jest rzędu od 800 KB (słownik 12-bit) do 1,3 MB (słownik 16-bit), czyli w miarę akceptowalne. Paker normalny pakuje testowy plik w 3 minuty do 247 KB (12-bit) lub 233 KB (16-bit) co raczej dla klasyka jest nieużywalne. Paker szybki pakuje w minutę do 257 KB (12-bit) lub 250 KB (16-bit). Tu się można zastanawiać. Duży słownik nie daje już dużego przyrostu, a pewna optymalizcja zmniejszyłaby czas pakowania może o 25 %. Dla porównania SHR3-45 s, GZIP-40 s. Wklejenie kompletnej tabelki byłoby nieczytelne, więc nie wklejam.

Testy przeprowadzałem pod emulatorem w trybie cycle-exact (28 Mhz), co nie daje możliwości porównania z prawdziwym sprzętem, ale daje jakiś realny obraz zwłaszcza przy porównaniu z innymi pakerami.
[#101] Re: XPK problem

@cholok, post #100

Czyli wkrótce będzie nowa wesja Twoich poprawionych bibliotek xpk ?
[#102] Re: XPK problem

@HanSolo, post #101

Na pewno nie wkrótce. Nie będę już niczego poprawiał, bo już nic nie zostało wartego uwagi. BZP2 jest zbyt skomplikowany (zbyt dużo algorytmów, depaker pamięciożerny i stosunkowo wolny) i raczej nie będzie tu dużego przyśpieszenia, lepiej skupić się na LZMA. SASC, SHSC są nieużywalne, wolne, a wcale dobre. Tak więc, jeśli już to będzie nowa xkpLZMA, ale to na pewno nie wkrótce.
Na stronie www.PPA.pl, podobnie jak na wielu innych stronach internetowych, wykorzystywane są tzw. cookies (ciasteczka). Służą ona m.in. do tego, aby zalogować się na swoje konto, czy brać udział w ankietach. Ze względu na nowe regulacje prawne jesteśmy zobowiązani do poinformowania Cię o tym w wyraźniejszy niż dotychczas sposób. Dalsze korzystanie z naszej strony bez zmiany ustawień przeglądarki internetowej będzie oznaczać, że zgadzasz się na ich wykorzystywanie.
OK, rozumiem