32bit vs 64bit: komprese audia [3] (diskuse)

[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.