Vyznam dual core

[Eagle]

proc sakra vsichni chtej paralelizovat jen rozdelenim do dvou stejnejch vlaken ?

Je to nejefektivnější, asymetrická vlákna nemívají stejné vytížení CPU.

[Fox!MURDER]

Je to nejefektivnější, asymetrická vlákna nemívají stejné vytížení CPU.

takze radsi, nez abychom ziskali vyssi vykon mene efektivni cestou, zustaneme u nizsiho vykonu. bezva pristup ...

[Peca-on-line]

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.

[Eagle]

takze radsi, nez abychom ziskali vyssi vykon mene efektivni cestou, zustaneme u nizsiho vykonu. bezva pristup ...

Jak se to vezme. U symetrických threadů je poměr výkon/námaha mnohem lepší než u asymetrických. Tak se jim nediv.

[Fox!MURDER]

Jak se to vezme. U symetrických threadů je poměr výkon/námaha mnohem lepší než u asymetrických. Tak se jim nediv.

jasne. ted uz je to proste jen o tom, jestli chceme vyssi vykon, nebo nechceme vyssi vykon. kdyz ho nechceme, tak zustanme u stavajiciho sw a stavajiciho hw ...

[Eagle]

jasne. ted uz je to proste jen o tom, jestli chceme vyssi vykon, nebo nechceme vyssi vykon. kdyz ho nechceme, tak zustanme u stavajiciho sw a stavajiciho hw ...

Nesouhlasím. Dle mě je to o tom, že chceme vyšší výkon, ale přemýšlíme o tom, jakou cenu jsme za to ochotni zaplatit. Uživatelé nejsou ochotni platit víc, proto programátoři nemají motivaci dělat víc, a proto DC nemá až na specifické úlohy využití.

[Fox!MURDER]

Nesouhlasím. Dle mě je to o tom, že chceme vyšší výkon, ale přemýšlíme o tom, jakou cenu jsme za to ochotni zaplatit. Uživatelé nejsou ochotni platit víc, proto programátoři nemají motivaci dělat víc, a proto DC nemá až na specifické úlohy využití.

takze se vyvoj pocitacu zastavi na mrtvym bode, dokud nekdo neprijde na to jak dal zvysovat SC vykon procesoru ...

[swarm]

To rad slysim, s temi vyvojari. Dalsi otazka je, jakou vysokoskolskou fyziku mas na mysli. Nechci nijak urazet treba CVUT, ale krome jaderky je tamni fyzika ponekud priliz prakticka a melka oproti treba MFF a to predevsim kvuli nedostaku potrebne matematiky.

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.

Jako jasne ze jsou i dobre programy pod windows, to jiste, ale stejne mam vzdycky pocit, ze hlavni neni kvalita, ale aby to hlavne vydelalo ty prachy.uje.

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.

Ve windows mi to pripada jako scifi, tam bych se vubec nedivil, kdyby se autor pri kompilaci musel drbat pravou rukou za levym uchem a odrikavat nejaou modlitbu, aby se mu to spravne zkompilovalo.

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 .

[pYr0]

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

[Peca-on-line]

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

[Petrik]

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

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 .

[richie08]

No, jak myslíš. Já vážně nějak nemám potřebu se s někym přít na foru o HW. Prostě jestli myslíš, že se jedná o lidi bez potřebného know-how, kteří pořádně neumí, co dělají, tak je to čistě tvá věc.
EDIT: Tahle část tématu je z mé strany už uzavřená, vyjádřil jsem se k tomu, jak se to často dělá, nic víc - dál už mi to ani nestojí za námahu. Richie08 se může pochlubit, ve kterých hrách dělal fyziku, když je tolik erudovaný a říká jak to jiní dělají špatně.

EDIT2: Jinak teda teď jsem se zeptal jednoho malého týmu, jak je to u nich s threadama a v podstatě zatim u nich ani nebyl důvod to použít, když u nich stačí i nějaký P4 1.6GHz procesor celkem v klidu. Jejich příští engine pravděpodobně později bude mít podporu více threadů, ale předělávat ten současný by samozřejmě nešlo. Ohledně fyziky se vyjádřil docela svérázně . Tady máte kousek rozhovoru (jenom ten kus z historie, kdy jsem neseděl u jiného počítače v době, co jsem objedval a pokračování o úskalích vydání jsem taky vyhodil, protože by tu nikoho nezajímalo):

....jinak teda ještě z věcí okolo. MT hra samozřejmě neznamená, že se více jader využije naplno, protože se taky může (nezřídka) stát, že právě ty okolní thready nebudou tak náročné jako jeden z nich, a tak ten bude zase bržděn výkonem na jedno jádro a ty ostatní jádra nebudou naplno využité přitom. Taky teda hry až na pár výjimek nějak nebudou extra lpět na dualcore v následujících aspoň dvou-třech letech určitě.

Můj názor jinak je: kupujte Dual-Core jak jen to jde. Za těch několik let, kdy najdou konečně víc využití, budou pro mě levnější. No a třeba se stane, že až konečně najdou využití, tak ty vaše dual-core nakoupené teď už budou výkonem pozadu tak, že si koupíte zase novou generaci.

EDIT3:
richie0: Já jsem to nějak nenapsal jasně, ale obecně platí téměř výhradně, že nějaký fake fyziky pro konkrétní případ použití (čim užší využitím tím víc) je výpočetně rychlejší než jakákoli obecná fyzika. Délku vývoje bych nějak úplně možná ani neřešil, to je zas úplně jiný faktor, ale o ten rozdíl rychlosti může už být kritický.

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.

[Eagle]

takze se vyvoj pocitacu zastavi na mrtvym bode, dokud nekdo neprijde na to jak dal zvysovat SC vykon procesoru ...

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.

2Fox&Eagle: Co si predstavujete pod pojmom asymetrické a symetrické vlakna?

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)

[Fox!MURDER]

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.

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.

[milka]

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

[miho]

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.

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.

[Eagle]

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.

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

[swarm]

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.

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?

[richie08]

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.

[PiT]

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.

Jasne. A prirataj si k tomu spocitanie kolizii polygonov nie par kvadrov namiesto objektov ale kompletnej sceny co vidis a papa aj na 5 nasobne rychlejsom stroji ako dnesny najrychlejsi DC...

[swarm]

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

[Petrik]

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

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

[Eagle]

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:

We spoke with many developers including some big names and we learned that they can’t make much sense out of quad or more core CPUs. They confirm that they can put two cores to good use but not much more. The main problem is that the performance is far from scalable.

You have to spend both time and money to resource the programmer to try to make sense out f the dual core CPU. It takes up to a year to optimise the game for more threads and even if you make the perfect job you can count on twenty to thirty percent performance increase, and this is the best case scenario.

Once you start making the multi threaded game you end up making and having the multithreaded bugs as well.

You can keep one core busy with the physics and collision detection, second core will have to wait for the score to move on with the Artificial intelligence while the third core could possible calculate the graphic data. In this best case scenario you have to realise that the core number two and three would always have to wait for the core number one to finish its job and pass the job to the cores two and three. In this concept there is absolutely no place for quad core as games are non parallel applications. A game developer expert said that you can use the core number four to stream and load the data in the game and this is what the guys at Remedy did at IDF quad core demonstration. But this takes time and money and it is not commonly embraced by developers.

Game developers are in the dawn of dual core programming and now all the sudden AMD and Intel wants them to go quad core. For the time being Quad cores are good for rendering and serves but not for games.

So if you want to play games, you can forget about quad cores, you simply don’t need them and can gain just marginal performance out of them. Give the developers some time and this might change, but we are talking quarters not months.

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.

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

[Rainbow]

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.

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

[DRTiCZ]

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?