Wielowątkowość kompresji Brotli

Question

Rozumiem, że przechowuje informacje o blokach w nagłówku meta-bloku z ostatecznym nieskompresowanym rozmiarem bloku i brak informacji o długości kompresji (9.2). Zgaduję, że trzeba utworzyć opakowanie, aby można było użyć go z wieloma wątkami lub, być może, czegoś podobnego do Mark Adlera: pigz.

Czy te same zasady odnoszą się do Brotli, podobnie jak w przypadku gzip w tym przypadku, czy są jakieś przewidywalne problemy, o których należy pamiętać, jeśli chodzi o implementacje wielowątkowe?

Answer 1

Możesz użyć formatu brotli w tym celu. Mam je dodać opcję umieszczania metadanych w pustych meta-blokach (gdzie "pusty" oznacza, że ​​meta-blok generuje zero nieskompresowanych danych). Możesz umieścić znaczniki w metadanych, aby ułatwić znalezienie meta-bloków. Wstawiony pusty meta-blok także rozpoczyna następny meta-blok na granicy bajtu.

Każdy blok meta-blokowy może być niezależny od innych bloków meta. Jeśli strumień jest skonstruowany w ten sposób, nie ma problemu z łączeniem ich podczas kompresji lub osobnej dekompresji. Obszarami możliwej zależności są bufor pierścieniowy dla czterech ostatnich odległości, a także odniesienia wstecz za początkiem bieżącego meta-bloku. W przypadku zastosowania równoległego, blok meta może i musi być skonstruowany w taki sposób, aby nie zależał od ostatnich czterech odległości, nie odnosząc się do bufora pierścieniowego, dopóki nie zostanie wypełniony odległościami od bieżącego bloku meta. Ponadto odległości, które sięgają wstecz przed bieżącym meta-blokiem, nie byłyby dozwolone (co nie zawiera żadnych odniesień statycznych). Na koniec dołaczysz pusty meta-blok lub meta-blok, aby przenieść sekwencję do granicy bajtów w celu łatwej konkatenacji.

Nawiasem mówiąc, wygląda na to, że łączysz ze starszą wersją wersji roboczej. Oto link to the current version.