32bit vs 64bit: komprese audia [3]

12.11.2007 01:15 | Přečteno: 1705× | Linux | poslední úprava: 12.11.2007 01:17

Vítejte ve třetím dílu seriálu věnujicímu se srovnávání výkonu 32bit a 64bit verzí aplikací a knihoven. Tentokráte bude měřena rychlost komprimace audia do mp3, ogg/vorbis a flac. Jako v každé části se i dnes pokusím propašovat nějaké výsledky zrychlení díky quadcore procesoru.

Zdrojová data

Náhodným výběrem CD z kolekce byl za pokusného králika zvolen Leonard Cohen. Jeho CD bylo zneuctěno vložením do počítačové DVD mechaniky a nagrabováno pomocí cdparanoia. Vstupem je tedy klasické CD audio ve formátu 44100 Hz, 2 ch, s16le, 1411.2 kbit. Komprimujeme celkem 4 skladby s celkovou délkou 19:20 a výsledek násobime třemi abychom získali čas odpovídající kompresi celého alba.

Verze aplikací

flac - Command-line FLAC encoder/decoder version 1.2.1
OggEnc v1.0.2
LAME 64bits version 3.97
LAME 32bits version 3.97

Lame není žádná lama

lame -q 2 -V 4 --quiet track01.cdda.wav

-q 2 značí vysokou algoritmickou kvalitu a -V 4 implicitní kvalitu (bitrate ~140kbit)

64bit sekvenčně: 5:06
32bit sekvenčně: 5:15

64bit paralelně: 1:27
32bit paralelně: 1:31

Minutu a půl čekat na kompresi alba? Pff, to je opříliš dlouho Pokusíme se dobu zkrátit nastavením implicitní algoritmické vality tedy -q 5.

64bit paralelně: 0:55
32bit paralelně: 1:00

Test ukázal jen malé rozdíly ve výkonu obou verzí. Zato paralelní kompresí dokážeme zkrátit čas až 3,5x.

OGG/vorbis

oggenc -q 5 --quiet track01.cdda.wav

Implicitní -q 3 je příliš slabá proto jsem zvolil -q 5 což dává v tomto případě bitrate zhruba 143kbit, tedy podobně jako lame mp3 při implicitním nastavení.

64bit sekvenčně: 1:26
32bit sekvenčně: 1:58

64bit paralelně: 0:25
32bit paralelně: 0:33

Zde jsou rozdíly patrnější. Paralelním během operaci opět urychlime zhruba 3,5x.

flac- bezeztrátová komprese nejen pro audiofily

flac -fs8 track01.cdda.wav

-8 znamená nejlepší kompresi. Oproti nekomprimovanému wav souboru nagrabovanému z CD učetříme pouhých 40 % místa. získáme tím ale audio v originální kvalitě- bez psychoakustických vylepšováků a artefaktů. Bitrate je cca 850kbit.

64bit sekvenčně: 1:27
32bit sekvenčně: 1:07

64bit paralelně: 0:25
32bit paralelně: 0:19

32bit verze je výrazně rychlejší- zhruba o 33 %. Zde je třeba poznamenat, že při implicitní kvalitě komprese nepříjdeme téměř o žádné místo zato ušetříme více než polovinu času. Tento kodek je tedy obecně velmi rychlý. Pokud vytížíme všechny jádra urychlíme tím celý proces opět 3,5x.

Příští díl se bude věnovat kryptografii, především pak openssl.

       

Komentáře

[msk]

Hmm, uz ani neviem kde, ale tusim na nejakom faq-u internetoveho vysielania nejakeho cz radia som narazil na otazku, preco nestreamuju v ogg. Odpoved bola, ze encoding do ogg je niekolkonasobne vypocetne narocnejsi a ze na to nemaju hw. Ktovie, aky encoder pouzivali, lebo z tych nameranych vysledkov vidim jasny naskok ogg voci mp3.

[miho]

lame v defaultnim nastaveni alg. kvality je skutecne o neco pomalejsi nez oggenc. To si ostatne muzete vyzkouset sam. Je pravdepodobne, ze v tom radiu pouzivaji jine kodeky pro kompresi mp3 (je jich mnoho a lame nepatri k nejrychlejsim ale dava kvalitni vystup) nebo pouzivaji nizsi algoritmickou kvalitu. A nebo to je, jak rikaji bratri slovaci, vyhovorka. Staci se podivat na vysledky jak by asi zatizila komprese streamu do ogg, kdyz komprese souboru probiha desitkykrat rychleji nez realtime...

[Ctirad Feřtr]

Zajímavější by bylo zkompilovat to bez všech MMX/SSE (a vůbec všech ASM optimalizací), které budou pro každou architekturu jiné (patrně výrazně lepší pro 32bit).

[miho]

Tohle jsou prakticke testy. Synteticke budou v jinem dilu. BTW zajimavejsi? Opravdu? Pro koho? Podle me se nenajde teoretik dosti odvazny aby z vysledku zmrzaceneho kodeku chtel vyvozovat nejake obecne zavery.

[Ctirad Feřtr]

To je otázka, co mělo být výsledkem. Jestli benchmarkovat procesory nebo programátory.

[zde]

Haha. Benchmark ve stylu Prakticky to funguje tak a tak, ale to nás nezajímá. Co říká teorie?

[Ctirad Feřtr]

Mě zajímá poměr výkonu 64bit a 32bit režimu a ne poměr optimalizací nějakého programu (který díky náskoku 32bit dnes vypadá nějak, ale za měsíc může vypadat úplně jinak).

[miho]

Mě zajímá poměr výkonu 64bit a 32bit režimu

Pokud myslite nejaky obecny pomer tak ten neexistuje, v kazde aplikaci bude nutne jiny. A uz vubec by se nedal poznat z vami navrhovaneho testu.

a ne poměr optimalizací nějakého programu (který díky náskoku 32bit dnes vypadá nějak, ale za měsíc může vypadat úplně jinak).

A pak vyjde nove gcc a vese vysledky budou take uplne jinak. Berte to z praktickeho hlediska. Rozhuduju se zda jit do 64bit nebo 32bit distribuce. Vykon je jednym z kriterii vyberu. Aplikace a prekladace se meni ale nedokazu odhadnout jak, kristalova koule se mi rozbila. Nejrozumnejsi v takove situaci je IMO vyjit z aktualnich verzi aplikaci a prekladace.

[Miloslav Ponkrác]

A naprosto jiné výsledky budou mezi 32 a 64 bit verzí téhož hw pod jiným operačním systémem. A naprosto jiné výsledky budou při použití kvalitně optimalizujícího překladače, ne gcc, mám dojem, že nyní měříte spíše kvalitu optimalizátoru gcc, než skutečnou rychlost 32 a 64 bit provesorů.

[miho]

A naprosto jiné výsledky budou mezi 32 a 64 bit verzí téhož hw pod jiným operačním systémem.

Pokud pujde o aplikaci ze stejnych zdrojaku, ktera nebude travit spoustu casu v jadru tak nevidim duvod proc by tomu tak melo byt.

A naprosto jiné výsledky budou při použití kvalitně optimalizujícího překladače, ne gcc

Tady souhlas. Ovsem pomoci gcc je v praxi kompilovana vetsina aplikaci. Pouzitim icc bych se zase vzdalil od bezne praxe.

mám dojem, že nyní měříte spíše kvalitu optimalizátoru gcc, než skutečnou rychlost 32 a 64 bit provesorů.

Buh chran, do takoveho projektu jako urceni skutecne rychlosti 32bit vs 64bit bych se nikdy nepustil. To by bylo nad lidske sily. Jen nez by nejaka komise slozena z odborniku pres rozne obory schvalila nejaky reprezentaticvni kod tak by byl mereny procesor obsolete

Ja merim jen jak pomoci aktualniho prekladace a aktualnich aplikaci a kodeku prevedu audio z wav do mp3, kolik RSA podpisu zvladnu za vterinu a podobne.

[Miloslav Ponkrác]

Pokud pujde o aplikaci ze stejnych zdrojaku, ktera nebude travit spoustu casu v jadru tak nevidim duvod proc by tomu tak melo byt.

Protože prostě i ty aplikace v 64 bit se překládají do dosti jiného strojáku. Protože každý operační systém má režii.

Tady souhlas. Ovsem pomoci gcc je v praxi kompilovana vetsina aplikaci. Pouzitim icc bych se zase vzdalil od bezne praxe.

Na Linuxu ano, tam je většina kompilována pomocí gcc. Pokud chcete dosáhnout praktický výsledek pro Linux a gcc, pak jsou Vaše testy super.

Ale skutečnou rychlost mezi 32 a 64 bit změříte daleko objektivněji pomocí icc - to je kompilátor, který vymáčkne maximum z procesoru - a při testu na icc poznáte, jaký je skutečný potenciál 32 a 64 bit prostředí a kak to v budoucnu půjde. Osobně si myslím, že stejně výsledky z testu v gcc budou v budoucnu pomalu (možná hodně pomalu) konvergovat k tomu co byste naměřil pomocí icc. Takže bych i prakticky považoval test pomocí icc za objektivnější, více vypovídající a po praktické stránce hodnotnější - protože k tomu budeme v budoucnu mířit (snad).

Buh chran, do takoveho projektu jako urceni skutecne rychlosti 32bit vs 64bit bych se nikdy nepustil. To by bylo nad lidske sily. Jen nez by nejaka komise slozena z odborniku pres rozne obory schvalila nejaky reprezentaticvni kod tak by byl mereny procesor obsolete

No to bylo, ale pro praxi prostě stačí přeložit algoritmus nejlepším kompilátorem , co je dnes k dispozici - což je icc - a to by bylo v podstatě velmi vypovídající o skutečné rychlost 32 x 64.

Ono nezlobte se, ale měření pomocí gcc, když vím, že dnešní Microsoft kompilátor bez problémů zvládne vygenerovat o 10% i daleko více procent rychlejší kód oproti gcc na 32 bit platformě - a to ještě není nic proti tomu, co zvládne Intel kompilátor, pak řekněme, že statistická chyba Vašich výsledků s gcc může být klidně i dost mnoho desítek procent. To není kritika, já vím, že to přiznáváte a děláte to i s tímto záměrem - ale Vaše testy nejsou moc vypovídající a za půl roku už může být všechno naprosto, ale naprosto jinak.

[Ctirad Feřtr]

A pak vyjde nove gcc a vese vysledky budou take uplne jinak.

Ale řádově v jednotkách procent. Rozdíl mezi zkompilovaným generickým C kódem a ručně optimalizovaným MMX/SSE může být klidně v řádu stovek procent. Tudíž rozdíly mezi kompilátory/systémy jsou v chybě měření.

Ale to je nakonec fuk. Prostě mě to jenom zajímá, nic víc. Nechápu, proč mě hned někdo musí okřikovat.

[miho]

Ja vas neokrikuju, pouze upozornuju, ze i nasledujici testy budou delany takto v praktickem duchu tzn. na zaklade cinnosti, ktere uzivatele bezne provadeji. Az v posledni casti serialu planuju dat synteticke testy, ktere jsou staveny za tim ucelem aby otestovaly nejcastejsi algoritmy pouzivane v aplikacich. Urcite tam bude tucne upozorneni ze i tyto specialne za timto ucelem vytvorene synteticke testy jsou... no proste synteticke a usuzovat z jejich vysledku neco o vykonu v realnych aplikacich muze byt znacne zavadejici.

[Limoto]

A kdy bude porovnání rychlosti kompilace?

[miho]

Bude. Po kryptografii jsem tam chtel dat povray a blender, nasledne mysql ale asi tam misto toho dam kompilaci.