FLAC párhuzamos tömörítés

Ezt a napot is megéltük. Vagyis pár napja már kijött a FLAC 1.5.0, amely végre támogatja a többszálúságot. Igaz, hogy csak betömörítésnél, de ott legalább sok szálon is lineárisan skálázódik, egészen 128 szálig, afölött le van tiltva, a fejlesztő szerint afölött romlik a teljesítmény. Kitömörítésnél is megoldhatták volna, az lassabb maradt, néha teszteknél, transzkódolásnál számít ennek is a sebessége.

Mindegy, nem lehet elégedetlennek lenni, ez nagy adósság volt már. Negyed évszázadot kellett rá várni. Reméljük, hogy egyszer a LAME, oggenc, opusenc is eljut erre a szintre, és nem újabb 25 évet kell rá várni.

( ricsip v | 2025. 02. 23., v – 10:28 )

ffmpeg is felkészül, v. ott már megoldott?

Az ffmpeg az tudja, bár ez kódekfüggő is, hogy épp milyen kódekkel dolgozol benne. Jellemzően az elterjedtebb videókódekeknél, pl. x264, x265, stb., szokta tudni.

“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”

( lacos | 2025. 02. 23., v – 12:31 )

Kitömörítésnél is megoldhatták volna, az lassabb maradt

A kitömörítés párhuzamosítása sokkal bonyolultabb, főleg akkor, ha úgy is mennie kell, hogy (a) a tömörítést pipe-ba végeztük, (b) a kitömörítést szintén pipe-ból végezzük, (c) a tömörített folyam tetszőelgesen nagy lehet. Ilyenkor az encoder nem tud a stream elejére a stream egészére vonatkozó információt írni (sem buffereléssel, sem random access írással), max a végére tud valamit írni, a decoder pedig csak a stream legvégén láthatja ezt az információt (ameddigre már mindenen túl kell lennie).

Ez elég jellemző probléma; többek között sem az xz, sem a pigz, sem a pbzip2 [*] nem támogatja.

[*] ha az eredeti bz2 file-t a normál bzip2 programmal hoztuk létre.

Amikor megcsináltam az lbzip2-t, akkor viszont pont ez a feature volt a lényeg, a motiváció. A stream szintjén két kritérium van: (a) a tömörített blokkoknak legyen egy méretbeli felső korlátja, (b) a tömörített blokkokat határolja el egymástól egy olyan meta-adat bitminta, amelynek előfordulási esélye a tömörített adatban (vagyis a blokkok belsejében) nagyon kicsi. Ha ez a két feltétel adott, akkor a tömörített stream-ben meghatározhatók olyan belépési pontok, amelyek között garantáltan lesz legalább egy blokkhatár, és így mind a tömörített blokkok rekonstrukciója, mind a kitömörítésük párhuzamosítható. Bővebben: https://git.sr.ht/~lersek/lbzip2-0.23-history

Ha a flac bitstream formátumra igaz a fenti két kritérium, akkor nincs elvi akadálya annak, hogy legyen hozzá párhuzamos kitömörítő.

(Az lbzip2-t a 0.23 után átvette Mikołaj Izdebski, aki a bzip2 alapformátumnak világklasszis szakértője; pl. az általa írt decoder ("yambi") a standard libbz2-nél lényegesen gyorsabb. Az általa készített és karbantartott lbzip2 2.* verzió többek között jó pár tervezési hibát is javít a 0.* sorozathoz képest; például trükkös bz2 input esetén sem igényel csillagászati mennyiségű memóriát.)

Nyilván pipe-ból, pipe-ba nem is várnám el, de ha a kimenet, bemenet rendes fájl, ott lehetne párhuzamosítani. Abban viszont igazad lesz, hogy emiatt nem támogatja a többi tömörítő sem a több szálú kibontást.

Egyébként rosszul írtam, nem 25 évet késtek vele, csak 21-et, előtte nem voltak elérhetők a home/office usernek 2 magos gépek, bár ha úgy vesszük, egyes P4-ek már 2002-ben tudták a Hyper-Threading-et, de akkor is „csak” 23 év.

“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”

OT

Elfeledkezel az SMP lehetőségről. A Compaq SystemPro - ami valóban nem kifejezett home desktopnak lett szánva, már '89-ben létezett. Sosem volt itthon csúcskategóriás gépem, de 2 procis masinám nekem is volt. Amúgy rémlik valami olyasmi, hogy az architektúra 4-cpus rendszert támogatna, de valamelyik gyártó ezt kitrükközte 6-ra azzal a megoldással, hogy 2 x 3 proci volt összekötve úgy, hogy mind a 2 hármas úgy "érzékelte" a másik hármast, hogy az ott 1 processzor.

Sőt a Hyper-threadinget is kihagytad a számításból.

/OT

tl;dr
Egy-két mondatban leírnátok, hogy lehet ellopni egy bitcoin-t?

A HTT-ről írtam, de az SMP-ben igazad van, már a Pentium Pro korszakból is rémlik dupla foglalatos alaplap, úgyhogy lehetett 89 is, ahogy te írod. Amit ki akartam hozni az egészből, hogy akkor ez még nem volt mainstream, nem csak azért, mert drága volt az alaplap, meg ECC memória kellett bele, meg duplán költeni procira, hanem mivel semmi nem volt ráoptimalizálva, nem érte meg. Mainframe-eknél, szuperszámítógépeknél meg még több évtizede volt már több CPU.

23 éve viszont egyre elérhetőbb mindenkinek, mégis sokáig tart implementálni szoftverekben. Simán fejlesztői lustaság. Azt se értem, hogy pl. gzip-ből is miért azt telepítik minden rendszerre alapértelmezettként, ha egyszer jó ideje létezik már a pigz, ami támogat többszálúságot, meg pl. sok másik tömörítőben már van (zstd, lz4, xz/lzma, bzip3, 7-zip, rar, stb.). Nyugodtan lehetne már minden disztrónak pigz-t használni, legfeljebb symlinkelik gzip-re, hogy régi szoftverek, szkriptek elérjék. Persze az infozip, lha, zoo, arj, bzip2 se támogatja még.

“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”

Erre az lbzip2-re rá fogok nézni, nem hallottam még róla. Valahogy kimaradt.

Szerk.: eddig sima többszálú bzip2-nek tűnik, de még nem mértem vele. A projekt oldala viszont iszonyat gáz, tartalmában és megjelenésében is.

“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”

( lacos | 2025. 02. 23., v – 12:38 )

Reméljük, hogy egyszer a LAME, oggenc, opusenc is

A GNU parallel gyakran ki tudja váltani a utility-n belüli többszálú tömörítést. Ha sok kis file-od van (pl. ha egy albumon 6-20 szám van), akkor a mai többmagos gépeken a GNU parallel nagyon jól jön. Én szoktam használni sox-szal és LAME-mel, illetve saját script-ekkel jpeg file-ok optimalizálásához, átméretezéséhez, forgatásához.

Igen, tudom, akár még GNU parallel nélkül is, simán szkriptben ütemezve & végződéssel a háttérbe küldve, de ez egyrészt extra szopás, másrészt nem leszel vele kisegítve, ha csak egy darab, nagy fájlod van.

“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”