Vyznam dual core

[mraky]

Programatori ze na zakaznika utoci nizkou cenou? Ale to preci neni pravda. Utoci se bezvyznamnymi featurami...nebo na nas MS utoci cenou? Tomu se fakt musim smat.

[tomase]

preco generalizujes programatorov na M$?

[THX]

Takmer vsetky Vase argumenty boli vyvratene, ale nie, DC MA zmysel, je to super-duper

Zmysel to bude mat, ked pre to bude vacsina aplikacii (a nie jedna-dve), co tak skoro nebude.

ja myslim ze neboli vyvratene. Staci mi pustit dva programy naraz a uz to vyuzivam. Nemusi byt ani jeden z nich optimalizovany pre DC.

MP3 neskodujes bez straty kvality efektivnejsie ako SC.
DivX/XviD neskodujes bez straty kvality efektivnejsie ako SC.
WinRARom nespakujes bez straty kvality v porovnani so SC pakovanim rychlejsie.

nepravda. mp3 skodujem bez straty kvality 2x efektivnejsie na DC - staci skladbu rozdelit na 2 casti. Je ale pravda ze na DC bude vysledny subor asi o promile vacsi.
DivX/Xvid skodujem bez straty kvality 2x efektivnejsie na DC - staci video rozdelit na 2 casti. Opat bude vysledny subor trocha vacsi.
Winrarom spakujem SO ZISKOM KVALITY v porovnani so SC rychlejsie - viz. fox murderov priklad na program files.

Vo vacsine pripadov je zvacsenie vyslednych suborov minimalne. Otazne je teda, ci budete lpiet na usetreni tych par byteov, alebo vam to pojde 2x rychlejsie.

Dnes a rovnako aj v minulosti mal DC vyznam *IBA* v CAD/CAM systemoch a specializovanych systemoch na strih videa obecne. (vynechajme servery, vojenske, technicke simulacie a pod.)

Iba? ale ved sme si tu ukazali mnoho inych pouziti, kde DC vyznam ma.

Dnes z toho tazi iba Doom3 po patchi resp. Q4. Ostatne hry ani popel. V buducnosti je nastastie velka pravedpodobnost, ze to bude inak - ak to tak bude - bude DC vyhodne kupit. Dnes to tak nie je.

driver uz mas multithreaded a uz tu niekto daval link na tomshw fora so zoznamom hier ktore podporuju dc.

a niekto tu spominal winamp... bol som prekvapeny, ale winamp s pustenymi AVS dokazal vytazit HT p4 na 80%, t.j. 60% vykonu druheho "jadra" vedel vyuzit.

Asi by to chcelo pekne spisat vsetky argumenty proti a vsetky argumenty za. Celkovo mi DC pride omnoho uzitocnejsie ako sse8.

Sorry za kratky prispevok, ale

A doporucujem si precitat tento thread odznova.

Teraz to praveze vyznam nema Vyznam to bude mat mozno v buducnosti, ked bude optimalizovany software. Pre SSE8 zoptimalizujes kompilator a ficis. Pre DC/MC treba aby rozmyslal programator a nie vsetko je paralelizovatelne...

podobne si to precitaj ty, mohol by som sa obdobne smiat, bolo tu ukazanych zopar pripadov kedy sa to vyuziva prave teraz....

pre DC zoptimalizujes kompilator a ficis. Skutocne optimalizacie na SSE a SSE2, take ktore mali razantny prinos vykonu, sa robili rucne.

A co sa tyka toho programovania, myslim ze programovat viacvlaknove aplikacie nie je az o tolko tazsie ako jednovlakna.

[Poofy]

me se zda ze tady panove ac tomu zajiste rozumi vic nez ja, tak proste nahlizi na vec stylem, ze kdyz ja pro linux a programovani nepotrebuju DC tak musi byt nahov*o.
Ale pro uz ted pro bezne uzivatele neni! Ve windows ktery vetsina lidi pouziva je prechod na DC dost znat v beznem uzivani i se SC aplikacemi stejne tak dekodovani videa je rychlejsi (o tom ze bych ztracel kvalitu slysim teda prvne) a proto Vase argumenty jsou mozna technicky spravne - ale v praxi a na nejpouzivanejsim OS je to jinak.
To ze programatori budou mit vic prace s optimalizaci je smutne ale pokud budou chtit obstat v konkurenci budou muset optimalizovat at chteji nebo ne.

[Caleb]

nepravda. mp3 skodujem bez straty kvality 2x efektivnejsie na DC - staci skladbu rozdelit na 2 casti. Je ale pravda ze na DC bude vysledny subor asi o promile vacsi.
DivX/Xvid skodujem bez straty kvality 2x efektivnejsie na DC - staci video rozdelit na 2 casti.

OMG, kolikrat se to tu resilo - jak psal Pit, doporucuji ti si opravdu precist tento thread (pripadne nam ukazat jak rozdelujes a pak spojujes MP3)

[THX]

OMG, kolikrat se to tu resilo - jak psal Pit, doporucuji ti si opravdu precist tento thread (pripadne nam ukazat jak rozdelujes a pak spojujes MP3)

ha, to bolo popisane v jednom linku ktory tu tusim dal eagle ako priklad ze sa to neda

Ako to teda rozdelim? Nezkodovany subor bez problemov rozdelim na dve casti. Ako spojim mp3ku? Jednoducho spojim dva skodovane mp3 zasebou a upravim hlavicku. A ak by som bol drsnak, tak ani neupravim tu hlavicku a pojde to prehrat, akurat nebude to asi ukazovat spravnu dlzku a niektore playere s tym mozu mat rozne mensie problemy.

[Caleb]

A ze budes mit uprostred lupanec (v dusledku nedelitelnosti frame) to ti moc nevadi, ze? A to ze ti samotne rozdelovani a spojovani zabere vice casu nez kdyby si to enkodoval na SC (neni mi znam zadny nastroj ktery by tuto cinnost automatizoval) ti take nevadi?
Jiste existuje DC-optimalizovany Lame (s horsi kvalitou nez SC), muzes enkodovat vice WAVu najednou, ale tebou popsany postup je imho nesmyslny. Nebo si to snad zkousel?

[THX]

A ze budes mit uprostred lupanec (v dusledku nedelitelnosti frame) to ti moc nevadi, ze? A to ze ti samotne rozdelovani a spojovani zabere vice casu nez kdyby si to enkodoval na SC (neni mi znam zadny nastroj ktery by tuto cinnost automatizoval) ti take nevadi?
Jiste existuje DC-optimalizovany Lame (s horsi kvalitou nez SC), muzes enkodovat vice WAVu najednou, ale tebou popsany postup je imho nesmyslny. Nebo si to snad zkousel?

Praveze lupanec tam nebude, pretoze sa vytvori novy frame a to je tiez dovod, preco bude vysledny subor trocha vacsi. Rozdelovanie a spajanie ak mi ma zabrat vela castu v porovnani s enkodingom znamena, ze enkodujem kratke skladby - ak su to napr. pesnicky albumu, mozem ich enkodovat paralelne, ak je to jedna dlha hodinova skladba, tak potom mi delenie a spajanie prinesie usporu.

(tento link sem dal eagle) http://forum.doom9.org/showthread.php?t=115822

Quote:
Originally Posted by emmel
Yes. But why not simply split the file in N-parts, and trivially distribute them over N-cores? And finally join the results. That would scale exactly linearly, or does it? Of course, if N is big, exact load balancing may be problematic (one thread could run much longer than the others). But anyways.

I actually made a program that could do that with x264, but it's not quite linear. I got something like 1.95x with 2 processors (although it's been a while since I've used it, so that number may be way off).

The main problem with many processors is with the splitting. There's no easy way to determine where x264 will put an I frames without analyzing each frame, so chances are the split point will be in the middle of a scene. For consistant quality, you need to re-render that scene. Obviously, this will not scale well if your number of processors is greater than the number of scenes in your movie.

I minimized the load-balancing problem by splitting to more parts than cores, then having each core "check out" the next split part. This, of course, increased the number of split frames and therefore the number of re-encoded scenes.

I think the reason that my setup didn't scale perfectly had to do with disk accesses. Two programs were reading and writing in two separate places on the same hard disk.

But as I said, it's been a while since I used that program to encode anything, and it was in the super-pre-alpha stage, so it may be a problem with my optimizations.

Teda, nie neviem o programe ktory by to robil automatizovane, ani som ho nerobil, ale vravim ze to nebude zlozite a ze tento program bude robit:
1. rozdeli neenkodovany subor na dva casti
2. pusti paralelne enkodovanie oboch casti
3. pospaja vysledne subory (a to sice tak, ze z nich povyhadzuje hlavicky a vezme iba data)
4. vytvori novu hlavicku kde nastavi spravne informacie o dlzke atd.
Tuto novu hlavicku moze vytvorit modifikovanim hlavicky 1. vysledneho mp3 suboru kde zmeni informacie na skutocne po pospajani odpovedajuce.

V bode 2 predpokladam enkodovanie s rovnakymi nastaveniami enkodera.

[mraky]

preco generalizujes programatorov na M$?

Kdybych ti dal priklad z aplikacnich serveru nebo z IDE, tak nevis o cem mluvim

[Caleb]

Praveze lupanec tam nebude, pretoze sa vytvori novy frame a to je tiez dovod, preco bude vysledny subor trocha vacsi.

Muzes nejak dokazat, ze to lze? Pomoci kterych nastroju by si to vytvoril (tj. nastaveni enkoderu Lame aby nevytvarel na zacatku a konci MP3ky mezery) a pomoci ceho by si to spojoval? To ze je neco teoreticky mozne (coz ale imho neni tento pripad) neznamena ze to je prakticky realizovatelne (se softwarovymi nastroji ktere jsou k dispozici). Mam neustale pocit, ze varis z vody - nebo si snad myslis ze vyvojari Multi-threading LAME sou tak hloupi, ze by neprisli na to, ze (podle tebe) staci vstupni soubor rozsekat na kousicky, paralelne enkodovat a pak pospojovat a misto toho resi nejakou DC optimalizovanou verzi co enkoduje stejne sekvencne. Chci dukaz misto slibu

[THX]

Muzes nejak dokazat, ze to lze? Pomoci kterych nastroju by si to vytvoril (tj. nastaveni enkoderu Lame aby nevytvarel na zacatku a konci MP3ky mezery) a pomoci ceho by si to spojoval? To ze je neco teoreticky mozne (coz ale imho neni tento pripad) neznamena ze to je prakticky realizovatelne (se softwarovymi nastroji ktere jsou k dispozici). Mam neustale pocit, ze varis z vody - nebo si snad myslis ze vyvojari Multi-threading LAME sou tak hloupi, ze by neprisli na to, ze (podle tebe) staci vstupni soubor rozsekat na kousicky, paralelne enkodovat a pak pospojovat a misto toho resi nejakou DC optimalizovanou verzi co enkoduje stejne sekvencne. Chci dukaz misto slibu

novy frame tam vznikne, pretoze na zaciatku kazdej jednotlivej casti samozrejme bude novy frame. Ake nastavenia lame pouzit neviem - nepouzivam lame. V podstate si uz ani nepamatam kedy som naposledy enkodoval. Ale predpokladam ze existuje nejake nastavenie lame, ktore do enkodovanej skladby nepridava na zaciatku ani na konci ziadne medzery, fadeouty atd. a ze len enkoduje presne to co dostane nekomprimovane na vstupe.
Mam dojem, ze vyvojari multithreaded lame sa vybrali inou cestou ako delenie suborov a teda tam robia ten multihreading uplne inac (tak, aby mohli spracovat subor sekvencne).
Program ktory by delil skladby a potom ich spajal potrebuje od enkodera v podstate iba vytvorenie frameov. Ak ma lame nejaky option, nech nepridava na zaciatok (ani koniec) id3 tagy, tak by malo stacit appendnut tie dva subory. Potom by to chcelo este k vyslednemu suboru pridat tie id3 tagy...

[PiT]

1)To se pletes, pro linux uz existuje docela hodne progamu na CAD, dokonce uz i zivotaschopne programy na vektorovou i rastrovou grafiku. Navic docela hodne vyrobcu profi aplikaci ohlasili portaci na linux.

Preco potom vsetci, ktorych poznam, pouzivaju ACAD a Cinemu, ked je tak vela CADovych programov pre linux?
O rastrovych programoch by som rad vedel, pretoze to je to jedine, co ma momentalne drzi pri Windoozoch.
Ktore velke firmy konkretne?

2)To neni pravda, napr. hry ale i dalsi aplikace, ktere potrebuji CPU.

Ktore?
Pre bezneho pouzivatela iba multimedia a pakovanie programov.

Multimedia - bolo tu toho dost. So sucasnymi kodekmi nepohnes bez straty kvality. Ako to vymyslia u novych, uvidime.

Pakovanie - tiez to tu bolo - bez straty kvality (velkosti) v sucasnosti nepohnes, uvidime o par mesiacov.

3)Creative suit, programy na zpracovani zvuku atd. Apply maji vice CPU uz pomerne dlouho, je tedy logicke, ze programy, ktere potrebuji vice CPU, je podporuji.

http://forums.macrumors.com/showthread.php?t=245733

"As far I know, neither of these apps are built to exploit multi-processor machines."

Programatori ze na zakaznika utoci nizkou cenou? Ale to preci neni pravda. Utoci se bezvyznamnymi featurami...nebo na nas MS utoci cenou? Tomu se fakt musim smat.

M$ ma na desktopovom trhu bohuzial prakticky monopol...

Staci mi pustit dva programy naraz a uz to vyuzivam. Nemusi byt ani jeden z nich optimalizovany pre DC.

Omyl, dva programy, ktore dokopy zatazuju jeden procesor na viac ako 100%.
Inak nie. A aj to za predpokladu, ze ti dementny windows scheduler nebude ich vykon nahodne prehadzovat z jadra na jadro.

nepravda. mp3 skodujem bez straty kvality 2x efektivnejsie na DC - staci skladbu rozdelit na 2 casti. Je ale pravda ze na DC bude vysledny subor asi o promile vacsi.

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)

DivX/Xvid skodujem bez straty kvality 2x efektivnejsie na DC - staci video rozdelit na 2 casti. Opat bude vysledny subor trocha vacsi.

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.

Winrarom spakujem SO ZISKOM KVALITY v porovnani so SC rychlejsie - viz. fox murderov priklad na program files.

Vo vacsine pripadov je zvacsenie vyslednych suborov minimalne. Otazne je teda, ci budete lpiet na usetreni tych par byteov, alebo vam to pojde 2x rychlejsie.

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

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.

Asi by to chcelo pekne spisat vsetky argumenty proti a vsetky argumenty za. Celkovo mi DC pride omnoho uzitocnejsie ako sse8.

Asi by chcelo.
Asi by to chcelo poriadne otestovat vsetko mozne na nejakom C2D a na tom istom akurat s disablovanym jednym core.

pre DC zoptimalizujes kompilator a ficis. ...

A co sa tyka toho programovania, myslim ze programovat viacvlaknove aplikacie nie je az o tolko tazsie ako jednovlakna.

Programoval si niekedy?

me se zda ze tady panove ac tomu zajiste rozumi vic nez ja, tak proste nahlizi na vec stylem, ze kdyz ja pro linux a programovani nepotrebuju DC tak musi byt nahov*o.

Linux ma prave MC riesene podstatne lepsie ako Windows

Ale pro uz ted pro bezne uzivatele neni! Ve windows ktery vetsina lidi pouziva je prechod na DC dost znat v beznem uzivani i se SC aplikacemi stejne tak dekodovani videa je rychlejsi (o tom ze bych ztracel kvalitu slysim teda prvne) a proto Vase argumenty jsou mozna technicky spravne - ale v praxi a na nejpouzivanejsim OS je to jinak.

Bavili sme sa o kodovani videa, nie dekodovani. Ak dekodovanie pouziva obe jadra, stracas vyhodu multitaskingu.

To ze programatori budou mit vic prace s optimalizaci je smutne ale pokud budou chtit obstat v konkurenci budou muset optimalizovat at chteji nebo ne.

To je to, na co Eagle poukazuje v podlednych postoch. M$ nic nenuti to robit, lebo ma dominantne postavenie. Beznych programatorov nic nenuti to robit, lebo im to nikto nezaplati. A programatori, ktorym to niekto zaplati, to uz davno spravili/robia

[Caleb]

Ale predpokladam ze existuje nejake nastavenie lame, ktore do enkodovanej skladby nepridava na zaciatku ani na konci ziadne medzery

A myslim ze u pocitu to zustane - je to problem samotneho navrhu formatu MP3.

bud lupanec v strede alebo v strede znizena/zvysena kvalita => vysledny subor iny

Presne tak, jeden spojovaci frame by kvalitu asi moc neovlivnil, ale pri prechodu na multicore by techto framu bylo v souboru cim dal tim vice a kvalita by byla o necem jinem.
2THX - nejde o to, ze by idea rozdeleni souboru a enkodovani byla spatna, pouze je konkretne u MP3 formatu nerealizovatelna - imho by se s timto muselo pocitat uz pri navrhu samotneho formatu (jak zde psal Pit) a je dost dobre mozne, ze diky teto vlastnosti by mel ve vysledku horsi pomer velikost/kvalita.

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

[Eagle]

Nemyslim. Napr. take antiviry. Da sa otestovat rychlost detekcie atd.

Ty by sis koupil antivir kvůli rychlosti detekce? Já teda kvůli co nejvyšší pravděpodobnosti odhalení virů a kvůli nejlepší podpoře. Pak mi taky musí sednout jeho ovládání. Rychlost je až někde na konci, protože si scan pustím v době, kdy bude počítač málo vytížen.

Ani procesory si nie su plne substituovatelne, take AMD ma 3dnow, teda niekedy v niektorych programoch moze mat nejaku vyhodu ktoru intel nema a tak su tie CPU neporovnatelne...

Tady tě asi překvapím - end-usera absolutně nezajímá, jaké instrukce procesor má. Jeho dokonce ani nezajímá, jestli je to z transistorů, laserů nebo čehosi. Jemu jde v zásadě jen o jedno - aby pro něj měl odpovídající hodnotu. Ta se povětšinou měří spolehlivostí (lidi chápou PC jako služku, ne něco, čemu budou sloužit oni) a výkonem v jimi oblíbených aplikacích.

co ja viem, napr. grisoft, eset a vobec

Takže podle tebe třeba Grisoft tě může ovlivnit na jeho antivir tím, že bude tvrdit, že poběží o 10 % rychleji na dual-core (víc asi sotva - limitace diskem)? Tak to nevím, co by jim na to zákazníci řekli - viz moje odpověď na první citaci.

lenze tato diskusia nie je o tom, ze ci prave teraz pre teba je vhodne DC, ale o vyzname a pouzitelnosti DC vseobecne

A já tvrdím, že až na specifické úkoly orientované především do oblasti serverů a pracovních stanic (kde si za příslušný software náležitě zaplatíš) a na některé typy multimédií to pro lidi momentálně význam nemá. Možná v budoucnu, ale do té doby klidně ušetřím.

teda - jedno z tych malych jadier bude "sietove").

Tak to je super. A kvůli takovéhle kravině poběží můj oblíbený program pomaleji? Děkuji, nemám zájem.

a ano, dokazali jsme tu, ze programovat pro SMP je slozitejsi.

My jsme tu především dokázali, že to je podstatně dražší! Dneska se všichni na všechno dívají přes peněženku, se podívej na prodeje hardware, co frčí. A prostě málokdo bude ochoten zaplatit dvojnásobek. Podívej se třeba tady na propagátora Petrika - jede na ušmudlaném přetaktovaném Sempronu. Proč? Protože prostě nechtěl dát do počítače víc peněz. Bude je chtít dát do software?

ovsem ja porad rikam, ze mame na vyber. bud zustaneme u soucasnejch cpu a spokojime se s vykonem, kterej mame ted, nebo si koupime DC a budem tlacit na vyvojare SW, ze chceme SW, kterej to podporuje. bohuzel nevidim cestu, jak donutit intel/amd/kohokoli jinyho, aby obchazel fyzikalni zakony.

Tohle není věc, která se nabízí. Vnímáš to lehce zkresleně. Pomineme-li to, že pro výrobce procesorů je podstatně levnější vymýšlet jednoduchá jádra než investovat zisky do R&D a zlepšovat paralelismus / frekvenci (i to se dá), pak máš dvě situace:
1) Jedno jádro (případně málo jader) na vyšší frekvenci.
2) Hodně jader s nízkou frekvencí.
Nic mezi tím neexistuje. Protože aplikace většinou další jádra nedokázou využít (a nebo si za ně sakra dobře zaplatíš!), jsem pro první řešení. Nehodlám obětovat 20 % výkonu ve většině aplikací tomu, aby mi pár aplikací běželo o řádově 40 % rychleji.

U vetsiny aplikaci, ktere potrebuji vysoky vykon CPU, uz podpora pro DC je dnes. Dukazem jsou ruzne profi CAD/CAM a grafika obecne.

Takže sám uznáváš, že "profi CAD/CAM". Kolik že tyhle programy stojí a pro koho že jsou určeny?

Stejne tak dalsi skupina programu, velmi zavislich na CPU - hry - jiz z DC alespon trochu tezi.

Jistě. Za cenu toho, že náklady na vývoj hry budou vyšší, a tedy se to buďto projeví na prodejní ceně nebo bude nutné, aby z trhu někteří hráči zmizeli (pokud se trh nebude rozšiřovat). A už tady IMHO zaznělo, že hry zas tak ideálně paralelizovatelné nejsou a že především jsou většinou limitovány výkonem grafické karty a nikoli výkonem procesoru.

Jinak kamos, co dela profesionalne se zvukem, si koupil ntb s C2D a je z toho uplne na vetvi. Muze tam pry navesit kolik pluginu chce a odezva systemu, u zvuku dost zasadni vec, je porad stejna

Kolik z toho dělá:
1) Novější architektura se spekulací a lepším paralelismem?
2) Velká rychlá L2 cache?
Jinak opět operuješ se slovem "profesionalne". To asi není úplně typické, že?

a to ze je winrar spatne napsanej, neni dukaz spatnosti DC. pokud bude 7zip fungovat lip, budu pouzivat 7zip. zvlast kdyz je zadarmo.

Tak to jsem zvědav, jak ke změně přesvědčíš BFU . To je podobné jak s Microsoftem - udělal výborný support pro školy, a tak si vychovává základnu uživatelů. Přeškolit lidi je mnohem dražší než koupit jejich software.

VSECHNY hry bezi na DC lepe, protoze graficky driver bezi oddelne od herniho enginu, navic nove ovladace DC podporuji. Rozdil je vetsinou 10-20%. Pak tu jsou moderni hry typu GRAW, ktere DC podporuji primo a rozdil je u nich klidne vice nez 50%.

To je sice pravda, ale když ušetřené peníze vrazíš do grafické karty, získáš mnohem víc. Jakmile jsi totiž limitován grafikou (a to jsi v 90 % případů), pak je rozdíl mezi různými CPU téměř zanedbatelný.

Ty aplikace, ktere DC nepodporuji a pritom by to bylo potreba, se zacinaj iprepisovat za ucelem podpory DC, viz WinRAR.

1) Kdo tohle přepisování zaplatí? Ty? Pokud ano, tak si DC taky koupím.
2) Kolik že výkonu navíc WinRAR přinese? Dělaly se tu nějaké testy a z nich vyplynulo, že v průměru tak 10-15 %. Jaké že je snížení frekvence kvůli druhému jádru? Není to takhle náhodou taky tak těch 20 % ?

NetBurst: 3800 MHz SC vs. 3200 MHz DC
A64: 3000 MHz SC vs. 2800 MHz DC

Přičemž DC má v obou případech vyšší spotřebu.

pre DC zoptimalizujes kompilator a ficis

Který kompilátor? Já žádný takový neznám.

Skutocne optimalizacie na SSE a SSE2, take ktore mali razantny prinos vykonu, sa robili rucne.

V některých případech pomáhal na SSE i kompilátor. Pro určité typy struktur (zejména loopy) se to dá automatizovat a výsledky nejsou tak špatné. Optimalizace tohoto charakteru je podstatně jednodušší než pro DC.

A co sa tyka toho programovania, myslim ze programovat viacvlaknove aplikacie nie je az o tolko tazsie ako jednovlakna.

Jeden myslel a vymyslel trakař. Pokud si tím nejsi jistý (nic jsi nenaprogramoval nebo o tom nemáš aspoň zcela jasnou představu), tak to nekomentuj.

Ve windows ktery vetsina lidi pouziva je prechod na DC dost znat

Já jsem si žádného razantního rozdílu nevšimnul. Mnohem víc vidím více paměti a rychlý disk (Raptor). Jediný znatelný efekt z DC je při více zátěžových aplikacích spuštěných současně, přičemž:
1) se to dá na SC vyřešit prioritami
2) ti na to DC z dlouhodobého hlediska nepomůže, neboť multithreadová aplikace obsadí obě jádra a odezva půjde opět do kytek (schválně si zkus spustit dva zátěžové programy naráz, tak to bude vypadat, až budeš mít jeden optimalizovaný).

proto Vase argumenty jsou mozna technicky spravne - ale v praxi a na nejpouzivanejsim OS je to jinak.

Věci jako MP3 standard jsou nezávislé na použitém OS, a proto je lhostejné, kde to spouštíš. Optimalizovat bez ztráty kvality to prostě nejde, i kdyby ses na hlavu stavěl.

pokud budou chtit obstat v konkurenci budou muset optimalizovat at chteji nebo ne.

Oni ti to samozřejmě naúčtují, toho se neboj. Dvojnásobek práce by nikdo za stejné peníze nedělal. A ano, ladění multithreaded programů do fáze spolehlivosti může znamenat klidně i takové zatížení navíc.

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

Další keyframe je vyšší kvalita? :-O Takže nejvyšší kvalita je nekomprimované video o velikosti pár set GB na hodinu? A to i když bude vizuálně stejné jako komprimované bez keyframes?

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.

Provedl jsem testy na víc adresářích / souborech a to i s různým počtem vláken (pomocí command-line přepínače). Výsledný soubor byl při více vláknech vždy (!) větší. BTW, co ten bug ve WinRARu 3.60, který u multithreaded komprese mohl způsobit poškození dat?

Co ak ma problem viacero spravnych rieseni a nie len jedno?

Správné řešení je takové, kde je nejlepší kompresní poměr. A z onoho slova "nejlepší" zjevně plyne, že pravděpodobnost, že takových řešení bude víc, je poměrně malá.

Intel teraz chysta nejaky novy optimalizovany kompiler pre DC.

Tahle vlastnost už je v jejich kompilátoru tak asi dva roky. Přínosy jsou prakticky nula.

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.

Takže nepopíráš, že optimalizace na DC bude drahá a budeš jí muset jakožto koncový uživatel zaplatit? Dále budeš muset zaplatit dražší DC CPU (víc křemíku = vyšší cena). Takže ve výsledku to bude vše třeba 3x tak drahé, přičemž ti to přinese možná 50 % výkonu navíc (když budu optimista).

[tomase]

vsetci sa tu opierate o argumenty, ktore zavazia pri rozhodovani mozno 1% uzivatelov. Ostatnych 99% da aj tak na marketing a svoj subjektivny pocit (pripadne kamarata mi povedal, ze...). Takze tak

[Eagle]

vsetci sa tu opierate o argumenty, ktore zavazia pri rozhodovani mozno 1% uzivatelov. Ostatnych 99% da aj tak na marketing a svoj subjektivny pocit (pripadne kamarata mi povedal, ze...). Takze tak

Bohužel to pro ně ale znamená, že budou platit zbytečně moc. Za věci, které nejspíš nevyužijí.

[tomase]

Bohužel to pro ně ale znamená, že budou platit zbytečně moc. Za věci, které nejspíš nevyužijí.

Je to cena za luxus, komfort. Naco je komu BMW 5, ked ho do prace po meste odvezie aj Felicia a rovnako rychlo?

[-=HaDeS=-]

vsetci sa tu opierate o argumenty, ktore zavazia pri rozhodovani mozno 1% uzivatelov. Ostatnych 99% da aj tak na marketing a svoj subjektivny pocit (pripadne kamarata mi povedal, ze...). Takze tak

"To borrow from a human euphemism, it is not a perfect galaxy."
-Thor, Supreme Commander of the Asgard fleet

U vetsiny aplikaci, ktere potrebuji vysoky vykon CPU, uz podpora pro DC je dnes. Dukazem jsou ruzne profi CAD/CAM a grafika obecne.

prides domov z prace a pustis si pre zabavu Max/Cinemu/Mayu/Combustion ? myslim ze takto sibnutych nas je mizive mnozstvo.

To se pletes, pro linux uz existuje docela hodne progamu na CAD, dokonce uz i zivotaschopne programy na vektorovou i rastrovou grafiku. Navic docela hodne vyrobcu profi aplikaci ohlasili portaci na linux.

budem ti vdacny ked mi najdes nieco a-la max/cinema pre linucha a PiT ti myslim ze verejne podakuje ked jemu najdes pre linucha ekvivalent Photoshopu

[tominek]

PiT ti myslim ze verejne podakuje ked jemu najdes pre linucha ekvivalent Photoshopu

pls, at sem nekdo napise ze "GIMP"

[Rainbow]

pls, at sem nekdo napise ze "GIMP"

GIMP

BTW. Bolo by vhodne skoncit s OT.

[tominek]

dobra omlouvam se za vtipek.

bylo to mysleno jako narazka na to ze existuji kvalitni bitmapove editory pro tucnakoidni system.

NEEXISTUJI

a ze by adobe zacalo sve produkty nejak portovat pod linux o tom taky nevim.

[Fox!MURDER]

dobra omlouvam se za vtipek.

bylo to mysleno jako narazka na to ze existuji kvalitni bitmapove editory pro tucnakoidni system.

NEEXISTUJI

a ze by adobe zacalo sve produkty nejak portovat pod linux o tom taky nevim.

treba se chyti pixel ...

ale uz vazne dost ot ...