Je to nejefektivnější, asymetrická vlákna nemívají stejné vytížení CPU.
Printable View
No ale pořád je to výrazně lepší než jedno vlákno, navíc při více asymetrickejch vláknech(víc než je jader) ten program líp využije cpu s různým počtem jader. Jaký bude využití jednotlivech jader už je věc OS.
Ja bych to s fyzikou na CVUT nevidel nejak zle. Kdo chce si tu cestu k fyzice treba na FELu najde (viz. "fyzikalni ctvrtky"). Takze bych to zas tak zle nevidel. Navic pro programovani her fyzika konkretne na FELu postacuje a zbytek, co clovek hleda uz se stejne douci sam. Ono si totiz nemysli, ze pri programovani her se neni neustale co ucit. Fyzika do her a klasicka fyzika jsou dve ruzne veci. Ja myslim, ze tohle je vazne trochu blbost resit.
Navic co mam zkusenosti, tak programatori her byvaj zrovna treba ohledne matiky dost bedny. Je problem, ze ty na to stale koukas jako na generic-programatora.
Blbost. Navic vetsina opensource programu je multiplatformni, takze pod windows a linuxem se jedna o ty same programy. Mimo jine rekl bych, ze dost opensource softwaru, co ja jsem mel tu cest, neni zrovna vzorem krasneho kodu. Navic opensource toho snese dost. I to, kde by s vama sef vybehl na dve doby.
Probuh. Kam na tohle chodis?? Jako moje zkusenost je, ze tolik problemu s kompilacema jako jsem mel na linuxu, jsem na zadne jine platforme v zivote neresil. Ale i tak to samozrejme tady nejak religiozne nepodavam, jak jsou linuxovy programatori odpadem remesla ;-).
2Fox&Eagle: Co si predstavujete pod pojmom asymetrické a symetrické vlakna? Objasnite. Ja poznam len ze existuju 2 rozne typy schedulerov -
asynchroný(AMP): Os bezi na iba jednom jadre, zatial co na ostatnych jadrach bezia ostatne aplikacie, thready - menej efektivne na prostriedky, lahsie programovanie
symetricky(SMP): Os bezi na viacerych procesoroch spolu s ostatnymi aplikaciami - viac efektívne využívanie prostriedkov, tazsie programovanie, v sucasnosti vyuzivajuc drtiva vecsina OS vratane vsetkych Windows, vydanych od verzie NT
Jestli to správně chápu, tak tady šlo o něco jinýho, pro ilustraci třea komprimace vidoeklipu:
symetricky - rozdělím klip na x částí a každýmu jádru předhodím jednu
asymetricky - jednomu jádru zadám komprimaci zvuku, druhýmu videa
Sorry za hodne OT:S tim programovanim pod woknama jsem asi ulit, uznavam, ale asi to je tim, ze jsem mel tu cest pracovat ve vyvojovem prostredi embeded Visual C# 4 .Prvni veliky uspech byl, kdyz to pri instalaci neshodilo wokna (muselo se upravit bootovani woken). Dalsi velky uspech byl, kdyz to pri spusteni neshodilo wokna (uprava registru) a konecne, to nejtezsi, aby to pri kompilaci neshodilo wokna (instalace patche a uprava reg). Testovano na 4 kompech, z toho zprovozneno jen na 2, ostatni dva to poste nedali. Pravda je, ze na woknech nebude problem se zavislostma, jelikoz vsechny wokna maj asi vestinou stejny verze knihoven. To je jediny problem v linuxu: clovek musi vetsinou rucne natahat potrebny knihovny, vyjimka je gentoo a jeho portage system. Jinak se rika ze alespon co se systemu a predevsim jadra tyka, ma linux jeden z nejlepsich kodu vubec, lepsi ma mozna nejake BSD a pod. Kdyby to byla nejaka pasarna, tak by to asi nebezelo na 9 z 10ti nejvykonnejsich kompu sveta :)
Ten Tvuj clovek z icq uplne potvrdil to co rikam. O laplaceovkach pravdepodobne nema ani paru a "kodi" si neco cemu si rika fyzika. Opravdu zarny priklad. Myslim, ze jsi se ptal dobre, ale nespravne osoby ;-) Tim ho nechci shazovat, treba umi jine veci, ale fyzika a vicevlaknove programovani to nebude. Simulace v automobilovem prumyslu me zivi takze o tomhle neco malo vim. Kdyby treba vedel ze mat. modely ze Simulinku jdou vyexportovat do C bez toho aniz bych musel neco vedet o solveru... Jenze spoustu lidi proste nevi.
Nekteri lide uz pochopili, ze oddelit fyziku, AI, atd... do jednotlivych vlaken je nejen elegantni, prehledne, ale nakonec mozna i jednodussi nez to vsechno bastlit do jednoho hlavniho vlakna stejne, jako to se to delalo kdysi davno na Sinclairu. Jenze tenkrat jiny HW proste nebyl a mackalo se z nej kazde procento vykonu a schopnosti. Pak prisla Amiga s jejimi koprocesory... Vim, je to slaba paralela na problem multi-core, ale nemuzu si pomoci, ze programatori dnes mrhaji prostredky, ktere maji k dispozici.
PS: Amiga 500 and SilkWorm forever.
Bohužel tomu vše nasvědčuje. Nebo ty vidíš za poslední řekněme čtyři roky nějaký dramatický zvrat? Fyzika se začíná projevovat.
Symetrická - dělají to samé (např. luštění šifry hrubou silou, kdy každý thread zkouší jeden klíč)
Asymetrická - dělají něco jiného (např. ve hře jedno počítá scénu, druhé zvuk)
no ja to vidim tak, ze poptavka po vyssim vykonu tu bude porad. treba ne od tebe, ale od ostatnich lidi ano, takze vyvoj proste pujde smerem pridavani dalsich symetrickych i asymetrickych jader. to ze tobe se multicore nelibi a prijde ti to moc slozity, nezastavi zakazniky od toho, aby chteli vykonnejsi a vykonnejsi pocitace a vyrobce od toho, ze se budou muset snazit, pokud budou chtit neco prodat.
Tak jsem se tesil, ze uz brzo ukazu vyznam Dual core vlastnimi testy, aby se mi ted rozbilo auto, jehoz oprava vysla na 20000,- ( cimz se z meho Formana stalo z meho pohledu neprodejne auto..)
Ach jo, ted budu muset pockat dalsi rok, az tu bude diskuze na tema vyznam quadro core...
Mozna, ze se na to divame ze spatneho uhlu. Fyzika se projevuje a bude se projevovat stale vice. Zadny prulom neni v tomto smeru videt. Hlad po vykonu tady ale stale je. Mozna je tedy na case poohlednout se nekde jinde po kostlivcich, kteri nase problemy zpusobuji.
1) Prokleti 8086. Kdo najde odvahu zbavit se toho balastu a do nekonecna a ledabyle nabalovani novych funkci? Tento proces uz bezi 28 let. Tak jsem se tesil, ze to s potrebou prejit na 64bit procesory skonci... bohuzel AMD zase prislo s bastlem ;-) Jak moc bychom si vykonnostne a redukci poctu tranzistoru pomohli, kdybychom zacali na zelene louce? Procesor bez balastu zpetne kompatibility, od zacatku 64bitovy, s peclive navrzenou homogenni instrukcni sadou od zacatku pocitajici se SIMD, navrzen pro podporu vice jader/procesoru, procesor od zakladu navrzen pro virtualizaci. Je to do jiste miry utopie ale nastesti se najdou i inovativni projekty jako napr. Cell.
2) Programovaci paradigmata. V roce 1967 vznikl objektove orientovany jazyk Simula s garbage collectorem. Pak v 1980 Smalltalk prinesl spoustu novych myslenek, ktere jsou dodnes vetsine programatoru nezname (objektove programovani bez trid resp. kdy trida je objektem, jazyk, kde neni prikaz pro cyklus ani pro podminku pripada mnohym jako z Marsu ale uz si neuvedomi, ze to jsou konstrukce proceduralniho programovani, ktere v objektovem pristupu nemaji co delat). Posledni zmenu, ktera stoji za zminku- vyjimky popravde nevim, kde se vyskytly prvne. V Cfront 1983 uz ale byly. Deklarativni a funkcionalni jazyky stoji zcela stranou pozornosti. Tady bohuzel nemuzu navrhnout reseni. Nevim jak z toho ven a popravde ani kterym smerem. V kazdem pripade to je odvetvi, ve kterem nedoslo uz pres 20 let k zadne zasadni zmene v tak dynamicky se menicim prostredi.
Tohle je podle mě ona největší brzda. Jednoznačně souhlas. Ne že bych x86 viděl jako něco principielně špatného, ale ony všechny rozšíření neustále přidávají složitost, zvětšují velikost instrukcí, snižují efektivitu. Nová architektura od základu navržená jako SIMD, se zaměřením na nejčastěji používané instrukce, s předpřipravenými pomocnými instrukcemi pro brzký odhad větvení a prefetch... to by přineslo výkonu mnohem víc než multicore. Beztak po nějakých cca. osmi jádrech už nemá multicore (vyjma speciálních aplikací) význam, neboť vynucený pokles frekvence způsobí větší snížení výkonu, než co přinese další jádro. Přidávání dalších jader je tedy velice krátkozraké, řešení tak na nejbližších pět let maximálně.
Ten člověk dělal arkádovku. Jestli nezná extra fyziku, tak to bylo v konkrétní hře skoro jedno. Ten rozhovor jsem uváděl k jiné části této diskuze. Btw je fajn, že děláš fyziku pro nějaký simulace. Jak moc jsou ale realtime? jsou schopný krmit vykreslovací engine, co musí jet 100fps?
Chtel jsem tim jen rici, ze clovek ktery nema poneti jak se sestavuji matematicke modely fyzikalnich deju a nikdy nedelal vicevlaknovy kod tezko muze tohle soudit.
Btw simulace dynamiky motoru nebo CFD je radove hodne pomalejsi, naopak zase simulace podvozku, spotreby nebo zrychleni vozidla pres nejaky jizdni cyklus radove rychlejsi. Bezne pouzvame na takoveto simulace laptopy a pokud 25 minutovy jizdni cyklus trva vypocitat zhruba do 10s (zhruba 150x rychlejsi nez realtime) tak si myslim ze tohle zvladne v pohode realtime i stare Pentium. Jenze najdi mi vyvojare games, ktery tohle vi.
Najdi si na netu nějaké přednášky o fyzice z "Game Developer Session" (videa jsou stopro volně ke stažení na netu....google poradí) každoročně pořádaného v Brně. Tam si můžeš srovnat určitou úroveň. Doporučuju ti schválně si pustit i takové, ve kterých se řeší nábor do firem a co po tobě budou chtít. Třeba tě to trochu vyvede z omylu.
Jinak, co se tak dívám třeba na nezávislou herní vývojářskou scénu, tak většina lidí studuje právě přední vysoké školy (lidi z jaderky a elektro na ČVUT, kopa Matfyzáků a obdobné školy v Brně...jejich názvy rád zapomínám). Dělání her je pro programátory pomalu tím nejtěžším zaměřením, jaké si mohou zvolit, a často ne zrovna obdobně ohodnoceným. Stále mám pocit, že na herní programátory se tu nahlíží jako na "programátory databází" s letmou znalostí 3D API ;-).
Jinak srovnáníreálných simulací s herní simulací mi nepřijde úplně vhodné, protože ve hrách jsou opravdu komplexní scény, a tak je potřeba si tu náročnost vynásobit x-krát. Nemyslim si, že by současná fyzika ve hrách byla zapříčiněna tím, že na světě máme samé hloupé herní vývojáře, co do opravdové fyziky moc nevidí. Viz první odstavec
Jasny je ze vyvojari dobrych her nemuzou byt zadni tupci :) marne ale vzpominam, kdy jsem videl ve hre dobrou fyziku, kdyz nepocitam havok ci aegia. Ted k temto dvema: nejak si nedokazu predstavit, jak jinak by slo udelat tak dobrou fyziku bez pouziti nejake formy pokrocile fyzikalni simulace. Taky naroky na CPU naznacuji, ze to uz nebude zadna ochcavka, ale relativne velmi presny fyzikalni modelovani. Zkuste si treba v HL2 nebo FEARu strelit do nejaky poveseny lampy nebo do nejakyho lana, to je fakt husty, co to udela. Kazdopadne si myslim ze cim vice procesoroveho casu tyto enginy dostanou, tim lepe :) takze dokud nebude fyzika na grafikach, vivat DC :)
Dnes vyšel zajímavý článek na The Inquirer. Někdo z redakce hovořil s vývojáři her o možnosti využití quad-core:
Zvýraznil jsem nejdůležitější část. To docela mění zde nastolený směr diskuze - zjevně nebude problém zatížit jedno jádro výpočtem fyziky a kolizí, potíž bude v tom, že chceme-li, aby tato fyzika probíhala realtime (tj. aby například jedno auto neprojelo celé druhým a až pak byla zjištěna kolize), musí být fyzika spočítána hodně rychle, protože se jedná o sekvenční záležitost. A je zřejmě jasné, že když data musíme překopírovat z jednoho CPU do druhého, může DC dokonce i zpomalovat výpočet.Citace:
Původně odeslal The Inquirer, Fuad Abazovic
Možná by to šlo vyřešit tak, že jedno jádro bude počítat kolize a fyziku pro jeden frame dopředu, zatímco další jádra aktuální frame. To ale bude docela potíž z hlediska synchronizace a taky tam bude určité zpoždění reakcí na uživatelům vstup (čili zdaleka to nebude optimální).
Ked ma byt nieco aspon trochu efektivne, tak sa spravidla pouziva C - prikladom su jadra Linux a BSD, Unixove systemove nastroje a servery. Aj C++ ma svoje vyuzitie, len ked sa objekty nasilu pouzivaju tam, kde nemaju zmysel, tak to potom zle dopadne.
Smalltalk je v praxi uplne nepouzitelny - musel som v tom chvilu robit a ked ti Pentium pocita jeden sinus z konstatny 10 sekund...
Cim je jazyk vyssej urovne, tym viac plytva systemovymi prostriedkami (procesorovym casom, pamatou, miestom na disku).
http://home.pacbell.net/ouster/threa...0bad%20idea%22
vlakna jsou zkratka problem a opravdu si myslite, ze se v nich nekdo u games bude nejak zvlast babrat?