Vyznam dual core

[P@pi]

eee ... ja udelam vlastni test ..
hezky naklikano, komprese best, solid archiv a tot asi tak vsechno ...
dekompresi premerim posleze ...
a taky porovnam md5 vzniklejch archivu

Souhlasim, chce to test praktickýho použití, nikoliv upravenej.

[Eagle]

Souhlasim, chce to test praktickýho použití, nikoliv upravenej.

Co to je upravenej test ?

[tomase]

moj test mi dal vysledok aky dal. To je pre mna podstatne - real world vysledky. Zaujimave, ze nepotvrdzuju co tvrdis ty, ze?

[P@pi]

Co to je upravenej test ?

Promiň ehm, upravený nastavení. IMHO teda aspoň já, když balim soubory ve winraru, tak prostě nastavim nejvyšší kvalitu a je to a tak to dělá i většina uživatelů, kterým si psal ty články na živě, osobně neznam nikoho, kdo by se ve WinRARu nějak mnohem víc hrabal. Podle mě nemá příliš význam upravovat nastavení, když to stejně nikdo nepoužívá.

[Eagle]

moj test mi dal vysledok aky dal. To je pre mna podstatne - real world vysledky. Zaujimave, ze nepotvrdzuju co tvrdis ty, ze?

Přečti si ještě jednou, co jsem napsal. Pokud v obou testech nezachováš stejné podmínky, nemá smysl to jakkoli řešit.

Promiň ehm, upravený nastavení. IMHO teda aspoň já, když balim soubory ve winraru, tak prostě nastavim nejvyšší kvalitu a je to a tak to dělá i většina uživatelů, kterým si psal ty články na živě, osobně neznam nikoho, kdo by se ve WinRARu nějak mnohem víc hrabal. Podle mě nemá příliš význam upravovat nastavení, když to stejně nikdo nepoužívá.

A co to je to upravený nastavení? Mnou použité přepínače reprezentují zcela standardní nastavení na max. kompresi. Takže kde je problém?

[P@pi]

A co to je to upravený nastavení? Mnou použité přepínače reprezentují zcela standardní nastavení na max. kompresi. Takže kde je problém?

V tom případě, proč nepoužít Compression method: Best, jak to používají i ostaní , proč přepínače, které stejně víceméně nikdo nepoužívá (opravte mě jesli se mýlim).

[Eagle]

V tom případě, proč nepoužít Compression method: Best, jak to používají i ostaní , proč přepínače, které stejně víceméně nikdo nepoužívá (opravte mě jesli se mýlim).

Grrr, navrhuju moderátorovi tyto příspěvky smazat, jsou tady úplně off-topic.

Co si myslíš, že je přepínač -m5 ?
m<0..5> Set compression level (0-store...3-default...5-maximal)
md<size> Dictionary size in KB (64,128,256,512,1024,2048,4096 or A-G)
cfg- Disable read configuration
r Recurse subdirectories
ri<P>[:<S>] Set priority (0-default,1-min..15-max) and sleep time in ms
s[<N>,v[-],e] Create solid archive
t Test files after archiving

[Fox!MURDER]

V tom případě, proč nepoužít Compression method: Best, jak to používají i ostaní , proč přepínače, které stejně víceméně nikdo nepoužívá (opravte mě jesli se mýlim).

BFU ani netusi, co to prepinac je ... a ja jsem taky linej je vymejslet ... kdyz to neni nutny ...

[tomase]

Přečti si ještě jednou, co jsem napsal. Pokud v obou testech nezachováš stejné podmínky, nemá smysl to jakkoli řešit.


A co to je to upravený nastavení? Mnou použité přepínače reprezentují zcela standardní nastavení na max. kompresi. Takže kde je problém?

preco by som mal zachovavat stejne podmienky? Ja chcem "real world scenario" podmienky a tie som zachoval. Alebo nie?

[P@pi]

Ok dobře jsem idiot, moje narážka byla jen na to, proč dělat něco způsobem, který neni moc lidí nepoužívá, ale jestli je to to samý, tak se omlouvam.

[Eagle]

preco by som mal zachovavat stejne podmienky? Ja chcem "real world scenario" podmienky a tie som zachoval. Alebo nie?

Chápeš tenhle graf?

[tomase]

nie, a hlavne nechapem o co sa tu cely cas snazis. Mna nezaujimaju testy a cisla grafov, mna zaujima ako sa to chova u mna...

[Eagle]

nie, a hlavne nechapem o co sa tu cely cas snazis. Mna nezaujimaju testy a cisla grafov, mna zaujima ako sa to chova u mna...

Musel bych říct něco o tvé inteligenci, a proto tuto debatu s tebou raději ukončím.

(fakt se mi to snad jenom zdá)

[P@pi]

Vzhledem k tomu, že to tu stejně někdo brzy smaže, tak se musim přiklonit proti Eaglovi.

Tomase jednoznacne ukázal, že při velkých souborech může být nárůst až 100%. Nevidim důvod, proč to zpochybňovat.

Co má dělat bufferování s SC a DC?? Normálně to taky nenabufferuješ napřed nebo snad jo?
Toť muj názor, klidně mě ukamenuj.

[Fox!MURDER]

Vzhledem k tomu, že to tu stejně někdo brzy smaže, tak se musim přiklonit proti Eaglovi.

Tomase jednoznacne ukázal, že při velkých souborech může být nárůst až 100%. Nevidim důvod, proč to zpochybňovat.

Co má dělat bufferování s SC a DC?? Normálně to taky nenabufferuješ napřed nebo snad jo?
Toť muj názor, klidně mě ukamenuj.

chjo. jste nepochopili smysl toho benchmarku ...

[P@pi]

Ok teda. Můžeš to srozumitelně znova napsat? Bez narážek pls.

[Eagle]

Tomase jednoznacne ukázal, že při velkých souborech může být nárůst až 100%. Nevidim důvod, proč to zpochybňovat.

Co má dělat bufferování s SC a DC?? Normálně to taky nenabufferuješ napřed nebo snad jo?
Toť muj názor, klidně mě ukamenuj.

Další, který nechápe základní souvislost mezi rychlostí RARu a bufferováním souborů. Prosím tě, radši mlč. Tomase nedokázal vůbec nic a ten jeho 100% nárůst je vzhledem k paměťové náročnosti RARu víc než pochybný (to by ten program musel mít dokonalou škálovatelnost a to určitě nemá). Pokud mezi testy upravím podmínky, tak je jasné, že můžu vykouzlit libovolná čísla.

[SajmoN]

Eagle > ja byt tebou tak sa tu na to vykaslem, bojujes tu s veternymi mlynmi .. chapes buras tu velkym odbornikom sny, navazas sa do ich dualcores .. ano aj ja planujem kupit dualcore, ale bude to len koli epenisu

[Eagle]

Ok teda. Můžeš to srozumitelně znova napsat? Bez narážek pls.

Tohle je můj testovací batch:

@echo off
rar a -md4096 -m0 -cfg- -r -ri10 -s Archiv CapPlus
cls
if exist timeq del timeq
timeq
rar a -md4096 -m5 -cfg- -r -ri10 -s -t Archiv CapPlus
timeq
if exist Archiv.rar del Archiv.rar
if exist timeq del timeq
echo.
pause

V první fázi natáhnu soubory do paměti, abych eliminoval čtení z HDD. Zároveň nesmáznu výstupní soubor, abych eliminoval zápis na HDD. V druhém průchodu už se pracuje jen se soubory v RAM. Takto jsem docílil co největší přesnosti měření a postaral se "o jinak stejné podmínky".

Pokud bych udělal pouze druhý průchod, tak proběhne podstatně pomaleji (viz graf - 36 vs. 26 vteřin). Pokud bych ale tento druhý průchod spustil znovu, data už budou v RAM, tj. ten samý příkaz provedený znovu bude proveden podstatně rychleji. Chápeš? Takže abych mohl zkoušet dual-core vs. single-core, tak buďto musím vždy bufferovat (což dělám v testech já, protože mi to přijde čistší než vnášet chybu měření zapříčiněnou diskem) anebo musím mezi testy restartovat, abych data dostal z RAM.

[Fox!MURDER]

Ok teda. Můžeš to srozumitelně znova napsat? Bez narážek pls.

smysl konkretne tohohle testu bylo ukazat, ze zrovna tady by rychlejsi disk pomohl vic, nez dvoujadrovej procesor.


a musim potvrdit nejakej bug ve winraru, protoze ted komprimuju s vyplym multithreadingem a winrarem souplym natvrdo na jedno jadro a odhadovanej cas je cca 1:20h (vytizeni cpu cca 57% ... coz je o 40% min, nez pri DC, ale narust casu je chabejch 20% ...). jeste cca hodinu, nez to skonci, ale odhad u DC byl temer presnej (seklo se to asi o 2 minuty) ...


(jinak jsou to velky, spatne komprimovatelny soubory a je jich cca 5.5GB)

[Fox!MURDER]

anebo musím mezi testy restartovat, abych data dostal z RAM.

a nebo komprimovat vetsi vzorek dat, kterej se ti nevejde do ram ...

[P@pi]

Tohle je můj testovací batch:

@echo off
rar a -md4096 -m0 -cfg- -r -ri10 -s Archiv CapPlus
cls
if exist timeq del timeq
timeq
rar a -md4096 -m5 -cfg- -r -ri10 -s -t Archiv CapPlus
timeq
if exist Archiv.rar del Archiv.rar
if exist timeq del timeq
echo.
pause

V první fázi natáhnu soubory do paměti, abych eliminoval čtení z HDD. Zároveň nesmáznu výstupní soubor, abych eliminoval zápis na HDD. V druhém průchodu už se pracuje jen se soubory v RAM. Takto jsem docílil co největší přesnosti měření a postaral se "o jinak stejné podmínky".

Pokud bych udělal pouze druhý průchod, tak proběhne podstatně pomaleji (viz graf - 36 vs. 26 vteřin). Pokud bych ale tento druhý průchod spustil znovu, data už budou v RAM, tj. ten samý příkaz provedený znovu bude proveden podstatně rychleji. Chápeš? Takže abych mohl zkoušet dual-core vs. single-core, tak buďto musím vždy bufferovat (což dělám v testech já, protože mi to přijde čistší než vnášet chybu měření zapříčiněnou diskem) anebo musím mezi testy restartovat, abych data dostal z RAM.

Ok teď jsem to pochopil, bohužel ty jsi to prostě nenapsal srozumitelně. Příště se pokus to napsat, tak jak jsi to napsal teď a ne příspěvky typu ignorant a IQ.

Nepochopil jsem tě, teď už tomu rozumim.
Peace

Tak tedy počkam na výsledek Fox!MURDERovo testu.

[Eagle]

Ok teď jsem to pochopil, bohužel ty jsi to prostě nenapsal srozumitelně. Příště se pokus to napsat, tak jak jsi to napsal teď a ne příspěvky typu ignorant a IQ.

Bylo to dost dobře popsáno v článku na Živě, o kterém se tady mimo jiné taky už dost debatovalo.

[Eagle]

Kdybyste někdo chtěl testovat ten můj batch, přikládám soubor na měření času. Není to rezident, tudíž nezabírá žádný výkon.

timeq.zip

První spuštění - záznam času na disk
Druhé spuštění - porovnání času přečteného z disku

EDIT: Fórum to nějak pomrvilo, je to dvojitý ZIP (po prvním rozbalení přejmenujte na ZIP a rozbalte znovu).

[THX]

O kolik moc lépe? A kolik to bude stát? U her bych za ty peníze rozhodně volil singlecore + dobrou grafiku než dualcore + špatnou grafiku.

ale ja som prave pisal, ze nemam pocitac len na hry a ze vyssi vykon procesora vyuzijem aj inde a preto je pre mna prijatelnejsia kombinacia procesora a grafiky za priblizne rovnaku cenu

A proč to teda mně na náhodně vybraných datech vyšlo +7 % ? Proč to člověku oponujícímu mi v diskuzi na Živě vyšlo v jednom případě +12 % a ve druhém (u špatně komprimovatelných dat - předpokládám video, což stejně nikdo rozumný komprimovat nebude) +31 % ? Výsledky ve WinRARu jsou tedy velmi variabilní.

pretoze vysledky zavisia od dat, mozno od rychlosti disku atd. a preto je vo winrare moznost benchmark, kde su komprimovane nahodne generovane data. Myslim ze porovnavat by sa malo podla tohto benchmarku, pretoze ten eliminuje aj vplyv disku.

Kde seženu dual-core, který mi za stejnou cenu dá v single-threaded aplikacích výkon jako A64 3200+ ?

nikde, tak ako asi nezozenies v podstate ziadny iny procak ktory ti za rovnaku cenu da rovnaky vykon

Když ho není možné využít, tak není.

kto vravi ze nie je mozne ho vyuzit? To je ako keby si povedal, ze kedze vacsina programov nepouziva SSE, tak tam nie su.
Ale zopar programov (a su to prave tie "pomale" - na ktore treba dlho cakat) ich vie vyuzit.

WinRAR má konkurenci a obsahoval ve verzi 3.60 fatální chybu postihující pouze vícejádrové CPU.

tak niekde som nasiel, ze program 7-zip je tiez multithreaded, takze ak sa nepaci winrar, tak mozes pouzivat 7-zip

Zrovna třeba u her byly provedeny analýzy strojového kódu, ze kterých vyplynulo, že jejich programátoři se ani nenamáhali zapnout optimalizace kompilátoru (činnost, která trvá jednu minutu a kterou lze získat třeba +40 % výkonu navíc).

no bohuzial, nova doba. dnes sa niektory programatori ani neobtazuju opravovat chyby a vydavat patche ale radsej robia hned dalsiu verziu programu (staci spomenut napr. bf2)

Toto by mělo být už teď, neboť je to tak jednodušší naprogramovat. Ale lepší driver ovládající grafickou kartu, která už tak jede na 100 % výkonu, ti toho moc navíc nepřidá.

ale sposobi to, ze v pripadoch kedy je obmedzenim procesor, to pojde lepsie

U spousty lidí to není o tom, že by to neuměli, jen tím nechtějí ztrácet čas.

ak raz pridu do stadia, ze budu chciet aby bol ich program vykonnejsi, tak toto bude dobra moznost ziskania vykonu

Jak jsi sám řekl - některé zátěžové programy nelze paralelizovat.

no to prave nie, povedal som ze nejde paralelizovat pod istu "granularitu", a zatazove programy, ktore trvaju napr. hodinu, myslim ze nemaju problem rozdelit celu ulohu na dva velke podvypocty, z ktorych kazdy potrva pol hodinu

Pokud je ti to nepohodlné nebo to tak dělat nechceš, kup si dual-core. Přesně to jsem psal v článku. Nicméně musíš se smířit s tím, že v takovém případě si za to zaplatíš těch +100 %. Pokud to pro tebe má takovou hodnotu, tak jsi zvolil správně.

podme sa na to pozriet opacne - z pohladu drahsieho procesora. Aky single core si mozem kupit za cenu DC? v pripade x2 3800+ si kupim 4000+. Tento ma o 20% vyssiu freq. Vacsinou bude rychlejsi, aj ked obcas nie. Zavisi to od toho, na co ho pouzijem.
Ale ak sa na celu vec pozriem z pohladu overclockera, tak oba procesory dostanem po OC na priblizne rovnaku frekvenciu. Potom ma ale DC vyhodu este jedneho jadra.
To je ako keby si tvrdil ze e6400 ma lepsi pomer cena vykon ako e6600, lenze 6600vka ma vyssi nasobic a viac cache. Ak aj oba procesory dostanes na 3.6ghz (na co v pripade e6400 potrebujes drahsiu dosku ktora da 514fsb), stale vdaka vacsej cache ma 6600vka vyssi vykon.
Takze pre overclockera ma zmysel procesor, z ktoreho dostane max. vykon, ale tento musi byt za co najnizsiu moznu cenu.
Teda, ano aj z x6800 dostanem 3.6g, ale lepsia volba je e6600. Podobne je to pri DC vs single core. Oba pretaktujem na rovnake max. freq, ale DC bude mat stale vyhodu druheho jadra, ktore moze v pripade potreby vyuzit.

Spousta zaseknutí GUI tě ale ani s dual-core nemine. Až mě to samotného překvapilo.

mal som p4 s HT a tych zasekov bolo menej, takze viem co mozem cakat
skor ja som bol prekvapeny ze po prechode na k8 single core nastali obcas zaseky na miestach, kde som to necakal

A k tomu winraru - zda sa ze na normal kompresii DC pridava viac vykonu, viz http://techreport.com/forums/viewtopic.php?t=43417 (scrollnite asi do stredu stranky, je tam dlhsi post kde je to porovnane) - a tiez nastava otazka, ci ma vobec best kompesia zmysel, ak je o tolko pomalsia a iba o trocha lepsia - ale to sa bude lisit samozrejma podla vstupnych dat a preto je podla mna najlepsia moznost porovnavania vykonu winraru na roznych zostavach vstavana moznost benchmark