Vyznam dual core

[Petrik]

Ne, ja si pustim winamp, firefox, thunderbird, pripadne MV2player, mozna openoffice, putty. Co maji tyto programy spolecne? Nepotrebuji nic silnejsiho, nez 1GHz duron. To je ta skupina programu, ktere sice DC nepodporuji a to pravdepodobne asi proto, ze to proste neni potreba.
Pak si ale taky mozna pustim nejakou hru, a jelikoz hraju FPSka, tak chci mit prumer alespon 80fps, nejlepe ale 100fps. A kdyz si pustim napr. muj velmi oblibeny GRAW, tak zjistim, ze ani muj sempron K8 2800+ pretoceny na 2.76GHz s rychlou pameti neudela ani ve VGA vice nez 50fps. Cim to asi bude, hmm? Jiste - malou frekvenci procesoru....skoda ze 5GHz procesory se neprodavaji...jakou mam jinou alternativu, hm? Malem jsem zapomnel, co treba dulacore? A nebo si treba chci zrypovat nejaky DVDcko. Jelikoz to chci mit kvalitne, udelam to na 2 CD...a kdyz budu alespon trochu sikovny, tak obe ty casti muzu kodovat najednou...kdyz bych mel DC

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

[THX]

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.

ano, ak mam dva antiviry ktore maju rovnaku pravdepodobnost odhalenia virov, tak si kupim ten rychlejsi
Na DC (a s NCQ diskom) si ten scan pustim kedy chcem. Tiez ked mam antivir pusteny na pozadi a stahuje nejake aktualizacie a scanuje ram, tak na DC to pocitim omnoho menej. Uplne najlepsie je ked hram bf2, som v lietadle a pusti sa scan po update, vtedy to zacne tak sekat ze radsej vyskakujem von.

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.

nakoniec da end user aj tak na reklamu, takze nema zmysel sa tu bavit o tom, co a preco si kupi bezny clovek

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.

ja by som bol rad, ze mi zrychlili program

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.

enkoding - tam sa to vyuzije dost vyrazne. Toto je vec, ktoru BFU bude robit asi casto - napalovat si na DVD veci z kamery. Na to potrebujes enkoding.


http://anandtech.com/cpuchipsets/sho...spx?i=2866&p=5
tu je pekne porovnanie - je tam "SC" a DC 2.4g conroe

DivX 6.1
Intel Core 2 Single Core (2.40GHz) 11.2 fps
Intel Core 2 Duo E6600 (2.40GHz) 16.3 fps
Intel Core 2 Quad Q6600 (2.40GHz) 24.0 fps
Windows Media Encoder 9
Intel Core 2 Single Core (2.40GHz) 31.3 fps
Intel Core 2 Duo E6600 (2.40GHz) 50.4 fps
Intel Core 2 Quad Q6600 (2.40GHz) 78.9 fps
Quicktime (H.264) (iba 2 threadove)
Intel Core 2 Single Core (2.40GHz) 16.2 fps
Intel Core 2 Duo E6600 (2.40GHz) 26.5 fps
Intel Core 2 Quad Q6600 (2.40GHz) 25.2 fps
iTunes MP3 (opat len 2 thready)
Intel Core 2 Single Core (2.40GHz) 6.1 MB/s
Intel Core 2 Duo E6600 (2.40GHz) 9.8 MB/s
Intel Core 2 Quad Q6600 (2.40GHz) 9.8 MB/s

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

sorry, ale toto nie je diskusia o tom, ake mas ty oblubene programy ale skor o vyuzitelnosti DC. Moj oblubeny program pobezi lepsie.

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?

dokazali? kde, co? ze som si nic nevsimol. A ze podstatne drazsi? Ja myslim ze programovanie je iba castou vyslednej ceny. Dneska se všichni na všechno dívají přes peněženku, se podívej na zostavy ludi na tomto fore, co frčí. Myslim ze su to celkom dobre kompy a rozhodne nie z najlacnejsich komponentov.
Petrik ma ten komp preto, lebo mu staci. A ked uz sa tu vsade ohanas ekonomickostou, tak ten jeho pretaktovany sempron ma vzhladom na cenu skvelu hodnotu. A to slovo usmudlany si si mohol odpustit.

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.

itanium a EPIC. Explicitly paralel instruction computing. HP a intel do R&D investovali snad 20 miliard dolarov a co z toho vzniklo. Prilis "tucne" jadro. Tazko vyuzitelne. Teraz tam zavadzaju isty "hyperthreading" aby bolo vobec mozne vyuzit tie vsetky jednotky co ten itanium ma. Zlozite jadro asi nebude mat vysoku frekvenciu. Ja myslim ze spravna je "stredna cesta" - teda dostatocne vykonne jadro, ale nie tak zlozite, aby nemohlo dostahovat vysoke frekvencie.

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.

Hry prave momentalne SU limitovane vykonom procesora. DX9 ma nezanedbatelny overhead a preto nemoze byt v scenach velke mnozstvo objektov. DX10 ma tento overhead zmensit. So silnejsim CPU si budes moct dovolit napr. lepsiu (detailnejsiu) fyziku, AI atd. Hra, ktora bude vediet vyuzit DC bude mat vyhodu...

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

toz, gfx8800 a petrikov sempron? Nemyslim ze je to dobra kombinacia, ale ano, asi si budes moct pustit 16x AA. Vela ludi ma 17" a 19" LCD. Teda rozlisko mas dane. Ak chces mat nejake rozumne FPS, tak na to potrebujes aj dostatocne vykonny procesor, nie len grafiku.

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 % ?

Nevsimol som si, ze by bol multithreaded winrar drahsi ako starsie verzie. Stoji stale rovnako. Znizenie frekvence koli druhemu jadru? Mozno pre BFU, nie pre overclockera - tam je limitom skor vyrobny proces. DC procaky pretaktujes priblizne skoro rovnako ako SC.

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.

Pre RISC a EPIC su pomerne zlozite kompilery, ale neda sa povedat, ze by bol kompiler univerzalnym liekom a urychloval vsetko ako sa len najlepsie da. Niekedy to chce urobit aj zmenu v samotnom programe. Inac ten kompiler na epic je velmi "premakany", pochadza od firmy ktora ma jedny z najlepsich kompilatorov na svete, a aj tak je problematicke kompilovat tak, aby bol itanium dostatocne vyuzity.

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.

programoval som multithreaded programy, mam o tom predstavu, neprislo mi to az o tolko tazsie a zlozitejsie ako tu popisujes ty.

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.

no tak proste zacnem pouzivat iny format. napr. wma, preco nie. A ze mi pojde enkoding mp3ky 2x rychlejsie, som ochotny ozeliet narast velkosti subora o 1 promile.

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.

tak ako nam to nauctoval napr. winrar?

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?

ano, pokial viem media pouzivaju stratovu kompresiu. A teraz je otazne, ci stoji za to mat niekolko GB nekomprimovane video, alebo skoro rovnake kompimovane. Myslim ze kompresia sa oplati. A teraz je otazne, ci stoji za to mat 2x rychlejsiu kompresiu, alebo trocha lepsiu kvalitu videa. Myslim ze sa DC oplati.

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?

Fox!murder provedl 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 NEbyl při více vláknech vždy (!) větší. BTW, co ten bug ve WinRARu beta, který mohl způsobit poškození dat?

Proste bug. Stava sa. Uz je to opravene.

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

pre mna je spravne riesenie take, ktore je rychlejsie a dostatocne kompimuje. Som ochotny ozeliet narast velkosti kompimovaneho suboru o tisicinu percenta za rychlejsiu kompresiu.

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

Ja myslim ze cena vysledneho programu bude rovnaka (mozno sa zmensi zisk firmy ktora to predava). Alebo - ak si budem mat vybrat z dvoch programov, ktore stoja rovnako a robia to iste, tak si vyberiem ten optimalizovany. Drahsie cpu - o kolko je drahsia vyroba? O 10-30 dolarov? Cena procesora nie je urcena len vyrobnou cenou, ta tvori iba (povedal by som mensiu) cast vyslednej ceny - aj ked zavisi od konkretneho procesora. Cim lacnejsi procak (low end) tym vyssiu cast vyslednej ceny tvori cena vyrobna.

3x drahsie to nebude. Ja som ti dokonca ukazal priklad kedy je DC lacnejsie ako SC. A ze to bude rychlejsie, budem len rad.

a BTW:

Nehodlám obětovat 20 % výkonu ve většině aplikací tomu, aby mi pár aplikací běželo o řádově 40 % rychleji.
NetBurst: 3800 MHz SC vs. 3200 MHz DC
A64: 3000 MHz SC vs. 2800 MHz DC

http://www.czechcomputer.cz/product.jsp?artno=37427
3.6ghz netburst DC

Rozdiel medzi SC a DC teda je:
intel 5,55%
amd 7,14%

a nie 20% ako tvrdis.

[Eagle]

2 THX: Nemám náladu ti na všechno znovu odpovídat, protože by to nikam nevedlo a ty evidentně nedáváš pozor. Vypíchnu ale pár věcí:

Na DC si asi těžko spustíš jakoukoli diskově náročnou úlohu na pozadí. Pokud si myslíš, že ano, tak si to vyzkoušej. Ale pak nám tu nebreč, že jsi vyhodil prachy za DC zbytečně.

Enkóding mnoha multimediálních formátů mi DC nezrychlí vůbec, protože daný kompresní algoritmus neumožňuje paralelizaci nebo jí umožňuje jen se ztrátou kvality. Linkem na Anandtech chceš dokázat co? Že je článek tendenční, protože nehovoří o poklesu kvality u H.264? Nebo že nepoužívá velmi oblíbený XviD, který v poslední stable verzi není multithreaded?

Itanium je momentálně jedna z nejúspěšnějších HPC platforem. A přesně pro tento účel byla vyvíjena.

O WinRARu zde bylo dokázáno, že jeho integrovaný benchmark nerespektuje realitu. Nechápu teda, proč uvádíš screenshot s výsledky, které jsou zcela irelevantní.

Formát budu používat zásadně takový, který chci JÁ, nikoli ten, který chce výrobce CPU, protože se mu to hodí do krámu. Já kvůli něčí neschopnosti nebudu měnit své zvyky. Oni jsou totiž placeni za to, aby umožnili maximální benefit pro mě. Pokud toho nejsou schopni, je potřeba je vyhodit a nahradit někým, kdo to zvládne lépe.

Přítomnost bugů v multithreaded programech je jasně s vyšší pravděpodobností.

DC za žádných okolností nemůže být výrobně levnější než SC. Další jádra znamenají vždy více transistorů, a tedy vyšší náklady.

Srovnání frekvence provedené mnou je na stejné výrobní technologii. Ty mixuješ různé generace, čili tebou provedené porovnání je irelevantní.

[THX]

Na DC si asi těžko spustíš jakoukoli diskově náročnou úlohu na pozadí. Pokud si myslíš, že ano, tak si to vyzkoušej. Ale pak nám tu nebreč, že jsi vyhodil prachy za DC zbytečně.

Preco by som si pocas browsenia nemohol na pozadi pustit antivir

Enkóding mnoha multimediálních formátů mi DC nezrychlí vůbec, protože daný kompresní algoritmus neumožňuje paralelizaci nebo jí umožňuje jen se ztrátou kvality. Linkem na Anandtech chceš dokázat co? Že je článek tendenční, protože nehovoří o poklesu kvality u H.264? Nebo že nepoužívá velmi oblíbený XviD, který v poslední stable verzi není multithreaded?

ja len vravim, ze ten pokles kvality je zanedbatelny, to je vsetko

O WinRARu zde bylo dokázáno, že jeho integrovaný benchmark nerespektuje realitu. Nechápu teda, proč uvádíš screenshot s výsledky, které jsou zcela irelevantní.

len som chcel ukazat, ze winrar dokaze vyuzit dokonca QC, nie len DC

Formát budu používat zásadně takový, který chci JÁ, nikoli ten, který chce výrobce CPU, protože se mu to hodí do krámu. Já kvůli něčí neschopnosti nebudu měnit své zvyky. Oni jsou totiž placeni za to, aby umožnili maximální benefit pro mě. Pokud toho nejsou schopni, je potřeba je vyhodit a nahradit někým, kdo to zvládne lépe.

ukaz mi kde ta kto nuti pouzivat nejaky iny program/kodek atd. Thread by sa asi mal premenovat na "Eagle:moje oblubene programy nevedia vyuzit DC a preto je dc na h*" No a co. Moje oblubene programy DC vyuzit dokazu.

Formát budu používat zásadně takový, který chci JÁ, nikoli ten, který chce programator (protoze se mu napr. lepe programuje), protože se mu to hodí do krámu. Já kvůli něčí neschopnosti nebudu měnit své zvyky. Oni jsou totiž placeni za to, aby umožnili maximální benefit pro mě. Pokud toho nejsou schopni, je potřeba je vyhodit a nahradit někým, kdo to zvládne lépe.

Přítomnost bugů v multithreaded programech je jasně s vyšší pravděpodobností.

niektore veci sa programuju lahsie multithreadovo

DC za žádných okolností nemůže být výrobně levnější než SC. Další jádra znamenají vždy více transistorů, a tedy vyšší náklady.

netvrdim opak, kazdopadne vysledna cena sa nesklada iba z vyrobnych nakladov. Ako som uz ukazal, vysledna cena DC moze byt aj nizsia ako u SC.

Srovnání frekvence provedené mnou je na stejné výrobní technologii. Ty mixuješ různé generace, čili tebou provedené porovnání je irelevantní.

takze to teda znamena ze intel mohol vydat rychlejsi SC p4? Aj keby, tak nevydal, takze si ho nekupis. Teda nemas sancu ziskat rychlejsi SC. Pokial viem, pentia4 9xx su dual die package pentii 6xx - takze porovnavam procesory vyrobene na rovnakej technologii. Navyse, cena top single core modelu moze byt koli vytaznosti vyssia ako top DC modelu, ktory bude mat trocha nizsiu frekvenciu.

[Over]

Valve a optimalizace pro více jader...
odkaz na citaci v CZ http://www.cdr.cz/a/19010
a na originál ve FR http://www.clubic.com/actualite-5532...multicore.html

[Petrik]

[JOKE]Ty jsi ocividne nedaval pozor. Kdybys cetl, co napsal Eagle, tak moc dobre vis, ze to prece nejde......aneb nikdy nerikejte, ze neco nejde, proze se muze stat, ze nekdo,kdo nevi, ze to nejde, pujde a udela to [/JOKE]

Ze by tedy jiz pomerne brzy bylo mozne vyuzit klidne tech 80 jader v tom experimentalnim procesoru od intelu nebo 8+1 jader v cellu? Zni to moc dobre, doufam ze to budou vyvojari do her implementovat co nejdrive. Mimochodem, vsimli jste si v tom odkazu poctu FPS? 22 na SC a 44 na core 2 duo? Budto to je nejak hrozne spatne optimalizovane, nebo to rozdeleni na mnoho vlaken stoji hroznou rezii, anebo to ma nejakou hrozne vychytanou AI, fyziku nebo tak neco Ale i kdyby to bylo podstatne mene efektivni, nez normalni sigle-threaded engine, je to i tak ohromny pokrok, jelikoz na to jde pouzit pravidlo "kde nepomuze hruba sila, pomuze jeste vetsi hruba sila". Proste ze pokud to i na dual-core jede pomalu, na 8-core to uz urcite pojede dobre Navic je to urcite nejaka alfa verze, ktera jeste urcite pujde zoptimalizovat. Kazdopadne myslim, ze se mame na co tesit

Specialne pro multi-threaded skeptiky: jasne, ze to neni idelani a ze to prinese spoustu problemu, ale je to lepsi nez zustat na veky veku u relativne pomalych SC. A i kdyby nastala nejaka revoluce a nekdo by vyvinul velice vykonny SC, porad jich pujde pouzit vice a ziskat dalsi vykon

Valve a optimalizace pro více jader...
odkaz na citaci v CZ http://www.cdr.cz/a/19010
a na originál ve FR http://www.clubic.com/actualite-5532...multicore.html

[swarm]

Preco by som si pocas browsenia nemohol na pozadi pustit antivir

Tak během browsení si ho můžeš pustit i na single-core a nebudeš nijak víc omezován. Aspoň můj antivir mi teda nevytěžuje procesor na maximum při scanu. Problém je akorát ve vytěžování disku.

niektore veci sa programuju lahsie multithreadovo

Ale je jich podstatně mín.

Formát budu používat zásadně takový, který chci JÁ, nikoli ten, který chce programator (protoze se mu napr. lepe programuje), protože se mu to hodí do krámu. Já kvůli něčí neschopnosti nebudu měnit své zvyky. Oni jsou totiž placeni za to, aby umožnili maximální benefit pro mě. Pokud toho nejsou schopni, je potřeba je vyhodit a nahradit někým, kdo to zvládne lépe.

Takhle to moc nefunguje. Když se to programátorům, líp programuje, tak to pravděpodobně budou mít dřív hotové. Takže je to spíš o penězích - cena času programátorů, cena řešení,... to s tim vyhazováním programátorů mě vždycky rozesměje.

[Eagle]

blablabla

Ty neumíš číst? Přímo na CDR ti to v diskuzi vysvětlil WoodyIS. Dovolím si citaci:

"Nic ve zlem, ale docela jsem se pobavil u vety: "Přistupují k tomu celkem logicky tak, že pustí o jedno méně podřízených vláken, než je počet jader a k tomu jedno hlavní vlákno, které se stará mimo jiné i o synchronizaci". Problem totiz neni v tom, kolik vlaken vytvorit, ale co do nich dat tak, aby intenzivne pracovala na svych datech a byla navzajem nezavisla, aby na sebe navzajem nemusela cekat. Protoze je to jedna cast me prace, tak sem se tesil, jak nam to Gabe prozradi a ono nic "

[THX]

Tak během browsení si ho můžeš pustit i na single-core a nebudeš nijak víc omezován. Aspoň můj antivir mi teda nevytěžuje procesor na maximum při scanu. Problém je akorát ve vytěžování disku.

no ale co ak mam online kompresiu? Na ntfs celkom bezna vec.

Ale je jich podstatně mín.

ano, je ich dost malo, ale predsa existuju - a to tiez vravi nieco o tom, ze DC nie je na h* a ze multithreading je vzdy zly, ale hlavne ide o to ze sa to nie vzdy robi tazsie multithreadovo

Takhle to moc nefunguje. Když se to programátorům, líp programuje, tak to pravděpodobně budou mít dřív hotové. Takže je to spíš o penězích - cena času programátorů, cena řešení,... to s tim vyhazováním programátorů mě vždycky rozesměje.

Ja som len chcel ukazat pohlad "z druhej strany". Tak ako eagle chce po tvorcoch CPU co najlepsi procesor, mozem ja pozadovat po programatoroch optimalizovany program...

[THX]

Ty neumíš číst? Přímo na CDR ti to v diskuzi vysvětlil WoodyIS. Dovolím si citaci:

"Nic ve zlem, ale docela jsem se pobavil u vety: "Přistupují k tomu celkem logicky tak, že pustí o jedno méně podřízených vláken, než je počet jader a k tomu jedno hlavní vlákno, které se stará mimo jiné i o synchronizaci". Problem totiz neni v tom, kolik vlaken vytvorit, ale co do nich dat tak, aby intenzivne pracovala na svych datech a byla navzajem nezavisla, aby na sebe navzajem nemusela cekat. Protoze je to jedna cast me prace, tak sem se tesil, jak nam to Gabe prozradi a ono nic "

"We gravitated towards creating a custom work management system that's designed specifically for gaming problems - its job is to keep the cores 100% utilised. We make it so that there are N-1 threads for N cores, with the other thread being the master synchronisation thread. The system allows the main thread to throw off work to as many cores as there might be available to run on, and it also allows itself to be subjugated to other threads if needs be."

The engine uses lock-free algorithms to solve one of the major problems of threading - access to data. Many of us have come across a similar problem before - if you're trying to edit a database or a web page whilst someone else is already doing a similar thing, you end up with one person overwriting the other person's data. The problem is the same when it comes to multiple threads accessing one data set in-game.

"We realised that, 95% of the time, you're trying to read from a data set, and only 5% of the time are you actually trying to write to it, to modify it. So, we just allowed all the threads to read any time they want, and only write when the data was locked to that thread."


viac -> http://www.bit-tech.net/gaming/2006/...e_Engin/1.html

[swarm]

no ale co ak mam online kompresiu? Na ntfs celkom bezna vec.

No, když tohle někdo používá, tak už mu o výkon asi moc nejde.

[Eagle]

blablabla

A co to jako dokazuje tahle tvoje citace? To mi netvrď, že jsi programoval multithreadově, když mi na mojí poznámku odpovídáš tímhle.

[THX]

No, když tohle někdo používá, tak už mu o výkon asi moc nejde.

Ak si das cistenie disku, tak tam je vec compress old files - co pokladam za velmi dobru vec. Subory ktore sa dlho nepouzivali sa skomprimuju. Ked si potom ale pustis antivir, ktory kontroluje vsetky subory, tak kontroluje aj tieto spakovane...

A co to jako dokazuje tahle tvoje citace? To mi netvrď, že jsi programoval multithreadově, když mi na mojí poznámku odpovídáš tímhle.

nectes poradne - odpoveda to prave na to, ako to urobili

"
The engine uses lock-free algorithms to solve one of the major problems of threading - access to data. Many of us have come across a similar problem before - if you're trying to edit a database or a web page whilst someone else is already doing a similar thing, you end up with one person overwriting the other person's data. The problem is the same when it comes to multiple threads accessing one data set in-game.

"We realised that, 95% of the time, you're trying to read from a data set, and only 5% of the time are you actually trying to write to it, to modify it. So, we just allowed all the threads to read any time they want, and only write when the data was locked to that thread."

a jo - programoval som multithreadovo

btw. co petrik akoze neumi cist? on sa v svojom poste nieco pytal? aby hladal v diskusii nejake vysvetlenie?

blablabla

A co to jako dokazuje tahle tvoje citace?

naco quotujes, ked to potom prepisujes?

[Eagle]

nectes poradne - odpoveda to prave na to, ako to urobili

Muhehe. Ty jsi nikdy nemohl nic programovat multithreadově (zda jsi vůbec kdy programoval), protože tahle citace je úplně o ničem. Když máš nějaká data v RAM (typicky dynamická) a máš víc threadů s pointery na ně, tak musíš zajistit sychronizaci, aby ti některý z threadů nenačetl stará data dřív, než jsou přepsána aktuálními jiným threadem (to je mimochodem jeden z největších problémů i u více než jednoho CPU z pohledu hardware - synchronizace zpožděných zápisů do RAM). Tím, že uvolníš uzdu a umožníš čtení v libovolný okamžik, způsobíš to, že některé thready budou používat stará data, a tedy dojde k porušení integrity dat! Je samozřejmě možné, že Valve udělalo něco takového pro věci, kde je limitem lidské oko / vstup z periferií, a tedy tato prasárna nebude na první pohled poznat, jenže to není správná metoda multithreadingu, ale krok udělaný z nouze a s nepříznivými důsledky.

A ten největší problém multithreadingu je vytvořit víc než jedno vlákno, které budou mít pořád co dělat. Fakt si myslím, že jsi nikdy nic multithreadově neprogramoval, protože jinak bys tyhle elementární věci znal.

naco quotujes, ked to potom prepisujes?

Víš, ono je tam takové tlačítko, které ostatní odkáže na tvůj post.

[Petrik]

Eagle, nechci ti do toho kecat, ale co to ma co spolecnyho s tim, ze jim to dost pravdepodobne funguje? Ze nejaky WoodyIS nevi, jak to udelat, me uprimne moc nezajima. Spise me zajima, ze nekdo ve Valve to zrejme vi a ze mu to uz pravdepodobne funguje. Treba to je jen nejaka marketingova bublina, ale jestli jim to funguje a bude jim to uspesne fungovat i na mnoha jadrech, tak to je rozhodne pozitivni vec, ne? Krome toho to taky bude znamenat, ze jsi nemel pravdu, coz me uprimne ani moc netrapi. Me jen fascinuje, jak se zuby nechty snazis dokazat, ze neco, co uz nekomu velmi pravdepodobne funguje, nemuze fungovat. To, ze ty nevis, jak neco udelat, jeste neznamena, ze to nevi nikdo na svete. Premyslej o tom. Krome toho docela nechapu, proc se tak hrozne moc snazis delat anti-MC (multi core) kampan. Ty snad vazne chces, abychom zustali na veky veku u jednoho jadra a neslu nikam dal.

Ty neumíš číst? Přímo na CDR ti to v diskuzi vysvětlil WoodyIS. Dovolím si citaci:

"Nic ve zlem, ale docela jsem se pobavil u vety: "Přistupují k tomu celkem logicky tak, že pustí o jedno méně podřízených vláken, než je počet jader a k tomu jedno hlavní vlákno, které se stará mimo jiné i o synchronizaci". Problem totiz neni v tom, kolik vlaken vytvorit, ale co do nich dat tak, aby intenzivne pracovala na svych datech a byla navzajem nezavisla, aby na sebe navzajem nemusela cekat. Protoze je to jedna cast me prace, tak sem se tesil, jak nam to Gabe prozradi a ono nic "

A jinak cist neumis spise ty, eagle:
The engine uses lock-free algorithms to solve one of the major problems of threading - access to data. Many of us have come across a similar problem before - if you're trying to edit a database or a web page whilst someone else is already doing a similar thing, you end up with one person overwriting the other person's data. The problem is the same when it comes to multiple threads accessing one data set in-game.

Aby nedoslo k nedorozumeni, tak ti to prelozim. Oni tvrdi, ze jejich engine vyresil ten problem synchronizace tak, ze zadna synchronizace zrejmne neni Neptej se me jak, ale zrejmne nejakym novym zpusobem pristupu k datum. To mi pripomina reiser4 (linux FS), ktery funguje "atomarne". Operace budto probehnou uplne, nebo vubec. Zajimave na tom je to, ze neni potreba duplikovat data. Proste u obou zrejmne nejaky extra vychytany algoritmus. Takze opet jedna rada: v IT oboru nepouzivej slova jako "nikdy" nebo jako v tomto pripade "musis". Oni proste nejakou tvoji sychronizaci zajistit zrejmne nemusi. tecka

Muhehe. Ty jsi nikdy nemohl nic programovat multithreadově (zda jsi vůbec kdy programoval), protože tahle citace je úplně o ničem. Když máš nějaká data v RAM (typicky dynamická) a máš víc threadů s pointery na ně, tak musíš zajistit sychronizaci, aby ti některý z threadů nenačetl stará data dřív, než jsou přepsána aktuálními jiným threadem (to je mimochodem jeden z největších problémů i u více než jednoho CPU z pohledu hardware - synchronizace zpožděných zápisů do RAM). Tím, že uvolníš uzdu a umožníš čtení v libovolný okamžik, způsobíš to, že některé thready budou používat stará data, a tedy dojde k porušení integrity dat! Je samozřejmě možné, že Valve udělalo něco takového pro věci, kde je limitem lidské oko / vstup z periferií, a tedy tato prasárna nebude na první pohled poznat, jenže to není správná metoda multithreadingu, ale krok udělaný z nouze a s nepříznivými důsledky.

A ten největší problém multithreadingu je vytvořit víc než jedno vlákno, které budou mít pořád co dělat. Fakt si myslím, že jsi nikdy nic multithreadově neprogramoval, protože jinak bys tyhle elementární věci znal.

[PiT]

Petrik:

Uvidime, az vide EP2

[Eagle]

Eagle, nechci ti do toho kecat, ale co to ma co spolecnyho s tim, ze jim to dost pravdepodobne funguje?

To, že někdo sníží výstupní kvalitu a udělá prasárnu, kterou by si v normální situaci nemohl dovolit, neboť by tím program zhavaroval, ty považuješ za fungování? Nemáš vůbec žádné zkušenosti s programováním a celou dobu tady šíříš jen svoje ničím nepodložené teorie a bujné představy. Citace uvedená v textu je o ničem, protože takto to nemůže fungovat, aniž by v tom byl nějaký háček typu destrukce integrity dat. A pokud si myslíš, že může, tak uveď konkrétní postup, jak to udělat. Už jednou se ti to nepovedlo, tak máš druhou šanci.

Mimochodem, říkal jsem ti, že se s tebou nebudu bavit. Jednak se neumíš chovat a zadruhé nepřinášíš do diskuze žádné zajímavé informace, pouze distribuuješ svoje představy založené na jakýchsi tvrzeních z webu, aniž by ses zamyslel, nakolik jsou pravdivá. Od lidí, se kterými se bavím, předpokládám určitou inteligenci. Když jí druhá strana neoplývá, pak je taková diskuze pro mě ztrátou času. Čili pokud chceš, abychom tu nadále nad tématem DC diskutovali, uváděj nějaké konkrétní programátorské postupy, jak si multithreadování představuješ. Obecné plky mě neberou.

Krome toho docela nechapu, proc se tak hrozne moc snazis delat anti-MC (multi core) kampan.

Nedělám anti-MC kampaň, jen říkám pravdu. Ono to bolí, viď? Tvoje ideály a teorie se pod tíhou faktů rozpadají.

[THX]

"We realised that, 95% of the time, you're trying to read from a data set, and only 5% of the time are you actually trying to write to it, to modify it. So, we just allowed all the threads to read any time they want, and only write when the data was locked to that thread."

Zamykanie teda pouzivaju, ale zistili ze nastane iba v 5% pripadov, preto povolili citanie bez zamku. Co je na tom nepochopitelne?

[Petrik]

Tyhle blaboly nebudu komentovat. Jen ti doporucim, aby sis precetl cely clanek, ze ktereho tu bylo citovano: http://www.bit-tech.net/gaming/2006/...e_Engin/1.html
Kdyz neveris takovymu loserovi, jako jsem pro tebe ja, treba mozna, mozna uveris vyvojarum ve Valve, ikdyz mi je jasny, ze proti tobe to jsou vylozeny zabari. A jak znam hry od valve, jsem na 100% presvedceny, ze ten jejich multi-threaded engine bude vylozene "prasarna se snizenou vystupni kvalitou" Tos me vazne pobavil

To, že někdo sníží výstupní kvalitu a udělá prasárnu, kterou by si v normální situaci nemohl dovolit, neboť by tím program zhavaroval, ty považuješ za fungování? Nemáš vůbec žádné zkušenosti s programováním a celou dobu tady šíříš jen svoje ničím nepodložené teorie a bujné představy. Citace uvedená v textu je o ničem, protože takto to nemůže fungovat, aniž by v tom byl nějaký háček typu destrukce integrity dat. A pokud si myslíš, že může, tak uveď konkrétní postup, jak to udělat. Už jednou se ti to nepovedlo, tak máš druhou šanci.

Mimochodem, říkal jsem ti, že se s tebou nebudu bavit. Jednak se neumíš chovat a zadruhé nepřinášíš do diskuze žádné zajímavé informace, pouze distribuuješ svoje představy založené na jakýchsi tvrzeních z webu, aniž by ses zamyslel, nakolik jsou pravdivá. Od lidí, se kterými se bavím, předpokládám určitou inteligenci. Když jí druhá strana neoplývá, pak je taková diskuze pro mě ztrátou času. Čili pokud chceš, abychom tu nadále nad tématem DC diskutovali, uváděj nějaké konkrétní programátorské postupy, jak si multithreadování představuješ. Obecné plky mě neberou.

Nedělám anti-MC kampaň, jen říkám pravdu. Ono to bolí, viď? Tvoje ideály a teorie se pod tíhou faktů rozpadají.

Ted pro vsechny: Dost me tam zaujal zaver:
But the chance of physics cards taking off is pretty minimal if we draw inferences from the views of Newell on hardware. He talks enthusiastically of the "Post-GPU world" - rather like the one envisaged by AMD and ATI with their Fusion project. In this world, we see a number of homogenous CPU cores all tasked with different projects - including graphics rendering. This allows for more flexibility when it comes to splitting up workloads, and means that engine-functions such as AI and physics can become a more integral part of the gaming experience because of the scalability such an architecture adds. "All of a sudden," raves Gabe, "If your AI isn't running fast enough, you can lower your graphics resolution. That's some awesome flexibility."

Ono to je docela logicke. Graficke karty se zacinaji stale vice podobat beznym procesorum a naopak nektere procesory, napr. cell, se zacinaji napadne podobat GPUckam. Ten 80-ti jadrovy terra chip od intelu je zrejmne tim, co mel autor citovaneho prispevku na mysli. Vysoce univerzalni, masivne paralelni a velmi vykonny CPU+GPU.

[Eagle]

Zamykanie teda pouzivaju, ale zistili ze nastane iba v 5% pripadov, preto povolili citanie bez zamku. Co je na tom nepochopitelne?

"Zjistili, že autonehoda nastává jen v 0,1 % případů jízdy autem. Proto povolili automobily bez deformačních zón a bez bezpečnostních pásů."

Už chápeš ten nesmysl textu?

blaboly

Domnívám se, že jsem ti jasně řekl, co si o tobě myslím a co je podmínka další diskuze s tebou. Opět jsi projevil svůj deficit inteligence, tak si asi budeš muset hovořit sám se sebou. Ostatní mají aspoň nějakou kulturu projevu.

[Fox!MURDER]

"Zjistili, že autonehoda nastává jen v 0,1 % případů jízdy autem. Proto povolili automobily bez deformačních zón a bez bezpečnostních pásů."

Už chápeš ten nesmysl textu?

me to docela smysl dava. stejne se to pouziva napr. v databazovejch aplikacich. ono je to mozna jen trosku nesikovne napsany...

[Eagle]

me to docela smysl dava. stejne se to pouziva napr. v databazovejch aplikacich. ono je to mozna jen trosku nesikovne napsany...

Jenže v databázích s tím budeš mít úplně stejný problém. Pokud dva uživatelé otevřou ten samý záznam, následně ho modifikují a uloží, vznikne ti konflikt, popř. druhý ukládající přepíše práci prvního. A jak bys tohle chtěl u hry ošetřit?

[Fox!MURDER]

Jenže v databázích s tím budeš mít úplně stejný problém. Pokud dva uživatelé otevřou ten samý záznam, následně ho modifikují a uloží, vznikne ti konflikt, popř. druhý ukládající přepíše práci prvního. A jak bys tohle chtěl u hry ošetřit?

So, we just allowed all the threads to read any time they want, and only write when the data was locked to that thread.

tzn. neodstranujou zamky uplne. odstranujou zamky pro cteni.

stejne to dela napr. MySQL, ktery pouziva read-only zamky. dalsi, ale dosti komplikovana a nevim jak efektivni cesta by mohlo bejt pouziti transakci ...
mozna to, kdyby se nejakym zpusobem implementovalo v HW, by mohlo udelat docela divy ...

[Eagle]

tzn. neodstranujou zamky uplne. odstranujou zamky pro cteni.

To je sice hezký, ale co to mění na stavu věcí? Pokud jeden thread má přečíst data, změnit je, zapsat a následně druhý je přečíst, změnit a zapsat, tak tím, že druhému umožníš je přečíst v době, kdy první thread nedokončil svojí práci, způsobíš načtení starých dat, a tedy porušení integrity.

[Fox!MURDER]

To je sice hezký, ale co to mění na stavu věcí? Pokud jeden thread má přečíst data, změnit je, zapsat a následně druhý je přečíst, změnit a zapsat, tak tím, že druhému umožníš je přečíst v době, kdy první thread nedokončil svojí práci, způsobíš načtení starých dat, a tedy porušení integrity.

otazka je, jaky to jsou data. a otazka je, jak casto konkretne ve hre delas to, ze prectes data a znova ty samy data zapisujes zmeneny. dovedu si predstavit scenare, kde se to tak deje a scenare, kde tohle vubec neni potreba. a i kdyz to ted treba neumim presvedcive vyvratit, tak spis budu verit cloveku, kterej ma za sebou projekty ala Half-Life a Source engine, nez cloveku, kterej jediny jak tu prezentuje svoje zkusenosti s threadovym programovanim je ve forme 'a threadove jsi nekdy programoval?' ... sorry ...