Vyznam dual core

[THX]

Zacal som debatu o tom v tomto threade podobne ako ty. Selskym rozumom su multimedia totizto jedna z mala spolahlivo paralelizovatelnych veci.
U LAMEu a navrhu MP3 ako takom je to vdaka bit reservoir a samotnej specifikacii MP3 s 3ma typmi blokov nerealizovatelne bez straty kvality (bud lupanec v strede alebo v strede znizena/zvysena kvalita => vysledny subor iny)

ja tvrdim zvysena kvalita, lebo novy keyframe a preto aj vacsi vysledny subor

Vysledny subor bude bud mensi alebo vacsi... Kvalita rovnaka nebude. Zhodli sme sa tu na tom, ze prvy pass je lahko paralelizovatelny (aspon u XviDu), pretoze tam ide kodek na maximalnu velkost... Druhy uz ma opat problem podobny ako u MP3, no v x264 kodeku to uz nejako vyvojari tusim okaslali.

OK, vysledna kvalita, ani subor rovnaky nebude. Ja tvrdim ze sa to bude lisit zanedbatelne, naproti comu sa rychlost enkodovania bude lisit vyrazne a teda mi to za tu malu zmenu stoji. Tak ci tak - je to stratova kompresia, takze ma vobec nezaujima ci na dvoch pocitacoch bude ten subor presne rovnaky.

Vysledna velkost suboru je vacsia. Je to teda ZISK kvality alebo STRATA kvality?

Program Files MT WinRAR 2,50MB/s (317MB, 127sec) (117% vykonu ST) (affinity CPU0 + CPU1) (vyslednej soubor 95,702,859 bytes)
Program Files ST WinRAR 2,12MB/s (317MB, 149sec) (100% vykonu ST) (affinity CPU0) (vyslednej soubor 95,851,150 bytes)

Podla mna je 851 150 viac ako 702 859 a teda mutithreaded verzia okrem toho ze bola rychlejsia, v tomto pripade este aj lepsie spakovala. Ale opat opakujem - tie rozdiely su tak male, ze su (podla mna) zanedbatelne.

Zasadna otazka pre mna je ale ta, ze dostanem uplne iny subor... Proste spustim tu istu vec na roznych pocitacoch a dostanem iny vysledok. To je na pozastavenie sa.

to je ako keby si si pustil dva rozne verzie wordu a napisal tam presne uplne rovnaky text a saveol to a vadilo by ti ze to ma roznu velkost. Aj ked je to korektne ulozene a korektne precitatelne. Co ti vadi na tom ze multithreaded winrar produkuje ine vysledky ako single threaded? Preco by to malo byt zle? Co ak ma problem viacero spravnych rieseni a nie len jedno?

Programoval si niekedy?

ano

[PiT]

ja tvrdim zvysena kvalita, lebo novy keyframe a preto aj vacsi vysledny subor

To zalezi od toho, ako to vide. Ak vide dobre, kvalitu toho frejmu zvysi, ak zle, znizi

OK, vysledna kvalita, ani subor rovnaky nebude. Ja tvrdim ze sa to bude lisit zanedbatelne, naproti comu sa rychlost enkodovania bude lisit vyrazne a teda mi to za tu malu zmenu stoji. Tak ci tak - je to stratova kompresia, takze ma vobec nezaujima ci na dvoch pocitacoch bude ten subor presne rovnaky.

Ak to bude nepostrehnutelne, tak je to v podstate jedno. V sucasnej dobe to ale bud nejde alebo to postrehnutelne je (lupanec). Uvidime u buducich kodekov.

Foxov test: Na nete je zasa presny opak Co uz.

Word: Nezmyselny argument.

WinRAR: Pokial budu mutlithreaded vysledky vzdy lepsie, tak nic

Programovanie: A programoval si aj pre viacprocesorove systemy resp. vies ako funguje linker a kompilator, ked si myslis, ze kompilatorom to vyriesis?

[THX]

Programovanie: A programoval si aj pre viacprocesorove systemy resp. vies ako funguje linker a kompilator, ked si myslis, ze kompilatorom to vyriesis?

kompilatorom sa to v niektorych pripadoch moze ciastocne zlepsit - optimalizovat pre instrukcie je samozrejme jednoduchsie. Intel teraz chysta nejaky novy optimalizovany kompiler pre DC. Chcel som tym len povedat to, ze skutocne optimalizacie, ci uz na SSE alebo DC sa nakoniec robia tak ci tak "rucne" a automatickymi optimalizaciami kompilatora mozno dosiahnut ciastocne uspechy, ale velmi to zavisi na tom, co sa kompiluje.

Ad. foxov test - ide len o to, ze ktosi tu tvrdil ze to bude VZDY horsie a to sice takym sposobom, ze nestoji za to to vyuzivat.